From mohamed.boucadair@orange.com Mon Sep 2 22:42:16 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 7EC0A11E8172 for ; Mon, 2 Sep 2013 22:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.013, 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 nCe6EZWeU+Co for ; Mon, 2 Sep 2013 22:42:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 22EC121F922A for ; Mon, 2 Sep 2013 22:42:11 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 80E863B4300 for ; Tue, 3 Sep 2013 07:42:10 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6B33227C046 for ; Tue, 3 Sep 2013 07:42:10 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 3 Sep 2013 07:42:10 +0200 From: To: "nsc@ietf.org" Date: Tue, 3 Sep 2013 07:42:06 +0200 Thread-Topic: I-D Action: draft-boucadair-chaining-design-analysis-00.txt Thread-Index: Ac6nu3JlF6+TbJ5jRh2rG3VDVgccuwArJSeA Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0336009@PUEXCB1B.nanterre.francetelecom.fr> References: <20130902090331.18283.85698.idtracker@ietfa.amsl.com> In-Reply-To: <20130902090331.18283.85698.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.3.33315 Subject: [nsc] TR: I-D Action: draft-boucadair-chaining-design-analysis-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, 03 Sep 2013 05:42:16 -0000 Dear all, We submitted this new analysis draft. Comments are welcome. Cheers, Med -----Message d'origine----- De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= De la part de internet-drafts@ietf.org Envoy=E9=A0: lundi 2 septembre 2013 11:04 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-chaining-design-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining: Design Considerations, Analys= is & Recommendations Author(s) : Mohamed Boucadair Ron Parker Filename : draft-boucadair-chaining-design-analysis-00.txt Pages : 21 Date : 2013-09-02 Abstract: The objectives of this document are to analyze the various design options, and provide a set of recommendations to be followed during the design phase of the Service Function Chaining solution(s). Note: o The analysis does not claim to be exhaustive. The list includes a preliminary set of potential solutions; other proposals can be added to the analysis if required. o The analysis is still ongoing. The analysis text will be updated to integrate received comments and inputs. o Sketched recommendations are not frozen. These recommendations are provided as proposals to kick-off the discussion and to challenge them. o The analysis does not cover any application-specific solution (e.g., HTTP header) because of the potential issues inherent to (TLS) encrypted traffic. o The analysis will be updated to take into account the full set of SFC requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-chaining-design-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-chaining-design-analysis-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From andre.beliveau@ericsson.com Tue Sep 3 07:55: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 F0DEB21E8143 for ; Tue, 3 Sep 2013 07:55:08 -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 ZGYRQGw63tqh for ; Tue, 3 Sep 2013 07:55:02 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id D8DCA21E8160 for ; Tue, 3 Sep 2013 07:55:01 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-c1-5225f83c8356 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id CD.24.03458.C38F5225; Tue, 3 Sep 2013 16:54:53 +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; Tue, 3 Sep 2013 10:54:49 -0400 From: Andre Beliveau To: "nsc@ietf.org" Thread-Topic: comments on draft-quinn-nsc-problem-statement-03.txt Thread-Index: Ac6otV7Hhp0jwDQLQ/e+3UBDUxRsyQ== Date: Tue, 3 Sep 2013 14:54:49 +0000 Message-ID: <3049626EAC5C3E43866CD2692A7E19AC1C21A2EE@eusaamb103.ericsson.se> 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: multipart/alternative; boundary="_000_3049626EAC5C3E43866CD2692A7E19AC1C21A2EEeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyuXRPgq7tD9Ugg65ONovj+/azOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49q/40wFi1wrpj9tZm5g3GDTxcjJISFgIvHq6Cc2CFtM4sK9 9WC2kMBRRokpKxS7GLmA7GWMEkc7DjCBJNgEjCTeX5nE2MXIwSEioCix800KiCksYCvxq00Z pEJEwEli784JjBC2nkTrj0dgI1kEVCQaD29jAbF5BXwldnx4yw5iMwrISmyY+A0sziwgLnHr yXwmiHMEJJbsOc8MYYtKvHz8jxXCVpZY8mQ/VH2+xNQVu6BmCkqcnPmEZQKj0Cwko2YhKZuF pAwiridxY+oUNghbW2LZwtfMELauxIx/h1iQxRcwsq9i5CgtTi3LTTcy3MQIDPpjEmyOOxgX fLI8xCjNwaIkzrtB70ygkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbmHZkX4vdVXT01letV 7I7oIrebXC7Vi9ZdCZdyvF4rlHnGze3Qkuh7B+OYbvYUywWJrJ1+9Jjj/+dSjYZiCpcWCu/c 7eavaqWhZyvyrcnddqL1Y9XTW+e9jbv1YkPwxSbVnx5T+Gz/5ZXOszlXf5VbcvWHvzf+a9nF m09+XK1/uS6C7YgDzy0lluKMREMt5qLiRAB5M01FSAIAAA== Subject: [nsc] comments on draft-quinn-nsc-problem-statement-03.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, 03 Sep 2013 14:55:09 -0000 --_000_3049626EAC5C3E43866CD2692A7E19AC1C21A2EEeusaamb103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Thank you for pursuing the definition of the problem statement, I am glad = to see that it covers both the technical issues and the operational issues.= I have concentrated my comments on the problem statement part, chapter 2 = as it has gone through a couple of iterations already and is more complete. As section 3 and 4 are more related to the framework, is there an intention= to write a separate document for the framework or to rename the document t= o problem statement and framework as indicated on the BoF page? Here is a few specific comments on the problem area section. 5. Service Chain construction: The last statement "Such a control / manage= ment plane could be centrally controlled and managed , or be distributed be= tween a subset of end-systems" seem to refer more to a solution rather than= a problem. I would simply remove this last sentence. 6. Application of Service Policy: I would definitely add the definition of= Service Policy into the Definition of Terms section. Here is a possible de= finition: "A set of rules to administer, manage and control network resourc= es so that policy specific actions can be taken by Service Functions" 8. Elastic Service Delivery: We should also add the additional complexity = which Cloud/DC bring by the fact that instances can be added quickly and in= different locations within but also across DC's. Adjusting networks with = the same elasticity is hard to realize today. 10. Limited End-to-End Service Visibility: Beyond troubleshooting, there a= re a number of similar O&M issues which should also be addressed. Namely, = how Service Chains can be validated or how Service Chaining statistics can = be collected and correlated. It is very complex to verify that the chain h= as been setup properly, that correct flows are directed to the ingress of t= he chain and that packets directed to a chain actually flows through all Se= rvice Functions properly. Regards, Andr=E9 B=E9liveau, Ing. Expert, Software and System Architecture Ericsson Research, Packet Technologies Mobile: +1 (514) 502 9592 mailto:andre.beliveau@ericsson.com --_000_3049626EAC5C3E43866CD2692A7E19AC1C21A2EEeusaamb103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Thank you for pursuing the defi= nition of the problem statement,  I am glad to see that it covers both= the technical issues and the operational issues.  I have concentrated= my comments on the problem statement part, chapter 2 as it has gone through a couple of iterations already and is more comple= te.  

 

As section 3 and 4 are more rel= ated to the framework, is there an intention to write a separate document f= or the framework or to rename the document to problem statement and framewo= rk as indicated on the BoF page?

 

Here is a few specific comments= on the problem area section.

 

5. Service Chain construction:&= nbsp; The last statement “Such a control / management plane could be = centrally controlled and managed , or be distributed between a subset of en= d-systems” seem to refer more to a solution rather than a problem.  I would simply remove this last sentence.=

 

6. Application of Service Polic= y:  I would definitely add the definition of Service Policy into the D= efinition of Terms section. Here is a possible definition: “A set of = rules to administer, manage and control network resources so that policy specific actions can be taken by Service Function= s”

 

8. Elastic Service Delivery:&nb= sp; We should also add the additional complexity which Cloud/DC bring by th= e fact that instances can be added quickly and in different locations withi= n but also across DC’s.  Adjusting networks with the same elasticity is hard to realize today.

 

10. Limited End-to-End Service = Visibility:  Beyond troubleshooting, there are a number of similar O&a= mp;M issues which should also be addressed.  Namely, how Service Chain= s can be validated or how Service Chaining statistics can be collected and correlated.  It is very complex to verify that t= he chain has been setup properly, that correct flows are directed to the in= gress of the chain and that packets directed to a chain actually flows thro= ugh all Service Functions properly.

 

Regards,

 

Andr=E9 B=E9liveau, Ing= .

Expert, Software and Syste= m Architecture

Ericsson Research, Packet = Technologies

Mobile: +1 (514) 502 9= 592  mailto:andre.beliveau@ericsson.com

--_000_3049626EAC5C3E43866CD2692A7E19AC1C21A2EEeusaamb103erics_-- From jguichar@cisco.com Tue Sep 3 09:01: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 B0D0B21F99EC for ; Tue, 3 Sep 2013 09:01:28 -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 Hagva+FaqZGy for ; Tue, 3 Sep 2013 09:01:16 -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 5FC8811E8219 for ; Tue, 3 Sep 2013 09:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10838; q=dns/txt; s=iport; t=1378224051; x=1379433651; h=from:to:subject:date:message-id:mime-version; bh=G+z6yrVyaQ6DjqwnGhlN0QWaMUI6QLl9DqcG+uTEA5I=; b=b5B+j2Zea7+EKCGfp2VhoRuVy9bowZCcoKfM8RPHy6PJTCw1iwcd1Xt8 0ySqp2LOv5e+B3CmEShQdOCqv9KtUk9z6Ta1m1J9mSmJISL4u5mUVD+yS y67HJRzhX7fwRkh4qqfQBqXhehL7MP+ecyzR5X3SxhvvSdshuGlL58vI3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAJ0GJlKtJXHA/2dsb2JhbABbgkNEgQbAdYEsFm0HgiYBBHIZARoQVhcQBBuHephzoCOOQ4ECg1WBAAOUG5VAgyCBaUE X-IronPort-AV: E=Sophos;i="4.89,1014,1367971200"; d="scan'208,217";a="252012769" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 03 Sep 2013 16:00:47 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r83G0lYD017636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 3 Sep 2013 16:00:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 11:00:47 -0500 From: "Jim Guichard (jguichar)" To: "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQw== Date: Tue, 3 Sep 2013 16:00:46 +0000 Message-ID: <68B171751455884590F8E38E96416F363F672511@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.82.236.156] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F672511xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: [nsc] NSC Working Group Charter Proposal 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, 03 Sep 2013 16:01:29 -0000 --_000_68B171751455884590F8E38E96416F363F672511xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_68B171751455884590F8E38E96416F363F672511xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Greetings,

As we look forward to the formation of a working group that will focus= on network service chaining, I would like to propose a discussion on this = alias to try and reach consensus on an initial charter as requested by the = routing area AD's. The following is a first draft of the charter and I invite you to actively participate a= nd provide inputs into this process.

Proposed NSC WG Charter

Existing service insertion and deployment techniques have not evolved = to meet modern network architectures and do not reflect multi-tenancy, virt= ualization, elasticity, rich classification, and other network requirements= . Networks, servers, storage, and applications, have all undergone significant change in recent years: virtu= alization, network overlays, and orchestration are increasingly the norm. A= ll of these have profound effects on network and services design.

Today, deploying new services, or making changes to existing services,= often requires network topology changes. Adding and removing service funct= ions is a complex, risky task, that is tied to operationalizing topological= changes leading to mostly-static service definitions. New service insertion and deployment techniques must = enable the concept of service functions as shared resources, and enable the= linkage of these resources using service chains that represent the abstrac= ted view of the required service functions, and define the order in which they should be applied. When a se= rvice chain is instantiated in a network, specific instances of service fun= ctions are selected, and a service topology is created and used for forward= ing packets through the service chain.

A basic service chain might simply utilize an existing overlay technol= ogy to force traffic through the necessary service functions. However, addi= tional information enables a richer service chain for more advanced composi= te services. For example, shared information (e.g., the result of classification) can be used to offload se= rvice function processing or inform other service functions about informati= on that would otherwise be hard to glean. 

The Network Service Chaining (NSC) working group focuses on new approa= ches to service insertion and deployment, providing a framework for the con= struction of services built using service chains. The WG focuses on the nec= essary protocols for the creation of service chains, and the passing of metadata from the network to service= functions, and between service functions. When possible, the WG will exten= d existing protocols to provide service chaining functionality, and any pro= tocol extensions will be reviewed by both the Network Service Chaining WG and by the WG responsible for the = protocol being extended.  

Specifically, the Network Service Chaining WG is chartered to deliver = the following work items: 

1) Problem Statement: this document will provide a summary of the prob= lem space to be addressed by the Network Service Chaining WG including term= inology and sample use cases.  Additionally, the WG will normalize on = nomenclature and definitions for Network Service Chaining.

2) System Architecture: this set of documents will provide a descripti= on of the architecture building blocks and their relationships including in= terconnection, placement of capabilities, and security models, as well as r= equirements on the control mechanisms and data plane encapsulation.

3) Service Chaining Data Plane: this document will describe on the wir= e data plane encapsulation in support of (2).  A single encapsulation = will be selected in order to enable interoperability of data plane componen= ts.

4) Manageability: this document will address service chaining operatio= n, monitoring and troubleshooting including relevant service chaining model= s such as MIBs or YANG modules, along with relevant OAM capabilities and ho= w they are realized.

Proposed Milestones:

Dec 2013 Request publication of an Informational document defining the= Network Service Chaining problem statement to the IESG

Mar 2014 Request publication of informational documents defining the s= ystem architecture including protocol requirements and framework to the IES= G

May 2014 Request publication of a Standards Track document specifying = the data-plane (including metadata) for Service Chaining to IESG

May 2014 Request publication of an informational document specifying S= ervice Chaining Control Plane requirements to IESG

Dec 2014 Request publication of informational documents defining Servi= ce Chaining manageability requirements including MIBs, OAM, and information= models to IESG 


--_000_68B171751455884590F8E38E96416F363F672511xmbrcdx01ciscoc_-- From paulq@cisco.com Tue Sep 3 09:35: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 3235E11E80F4 for ; Tue, 3 Sep 2013 09:35:40 -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 Bixorusqncve for ; Tue, 3 Sep 2013 09:35:35 -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 2B75C11E81B7 for ; Tue, 3 Sep 2013 09:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13726; q=dns/txt; s=iport; t=1378226135; x=1379435735; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R+Jx2GJE2/73sqjOQCLQrXdkKtmxPpabduou3YxD9ts=; b=QbPGbLSR1vtLyxXDpdsmxhE2uzGWeCCfP/A1NAX+WYyjeL2D5WPMvnOs FQiZxSCmwVMlxw1nk0K38DxwAcnJwgc+xSDPKYtwP9z2i0u9zHxYS8dp+ nxtEr0AY1Oo7EXX6hknIyOut9LlA+dC24LVBU8ST/Kp2VCGQYydvxxh5m I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIGAM8OJlKtJV2b/2dsb2JhbABbgkNENVGGCKhbiVaIPIEuFnSCJQEBBHkQAgEIIh0HMhQRAQEEDgUIE4dnDLkOjjeBDjEHgx2BAAOZJJA3gTuBZYFoAh4GHA X-IronPort-AV: E=Sophos;i="4.89,1015,1367971200"; d="scan'208,217";a="252028077" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 03 Sep 2013 16:35:34 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r83GZYOu011094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Sep 2013 16:35:34 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.101]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 11:35:34 -0500 From: "Paul Quinn (paulq)" To: Andre Beliveau Thread-Topic: [nsc] comments on draft-quinn-nsc-problem-statement-03.txt Thread-Index: Ac6otV7Hhp0jwDQLQ/e+3UBDUxRsyQAOCYWA Date: Tue, 3 Sep 2013 16:35:34 +0000 Message-ID: References: <3049626EAC5C3E43866CD2692A7E19AC1C21A2EE@eusaamb103.ericsson.se> In-Reply-To: <3049626EAC5C3E43866CD2692A7E19AC1C21A2EE@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.172.246] Content-Type: multipart/alternative; boundary="_000_B4CF12F64861194990FEA0AE39F9B1620EA54613xmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] comments on draft-quinn-nsc-problem-statement-03.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, 03 Sep 2013 16:35:40 -0000 --_000_B4CF12F64861194990FEA0AE39F9B1620EA54613xmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andre, On Sep 3, 2013, at 7:54 AM, Andre Beliveau > wrote: Hi, Thank you for pursuing the definition of the problem statement, I am glad = to see that it covers both the technical issues and the operational issues.= I have concentrated my comments on the problem statement part, chapter 2 = as it has gone through a couple of iterations already and is more complete. Thanks a lot for taking the time to review it! As section 3 and 4 are more related to the framework, is there an intention= to write a separate document for the framework or to rename the document t= o problem statement and framework as indicated on the BoF page? There is a proposed framework document (http://datatracker.ietf.org/doc/dra= ft-boucadair-service-chaining-framework) as well that is in the process of = being reviewed. We are working to align terminology. Having said that, I = think that section 3/4 belong in the problem statement: section 3 describes= , at a high level, the problems solved, and section 4 will provide an overv= iew of how chaining is used. We expect detailed, per vertical, use case dr= afts as well. Here is a few specific comments on the problem area section. 5. Service Chain construction: The last statement =93Such a control / mana= gement plane could be centrally controlled and managed , or be distributed = between a subset of end-systems=94 seem to refer more to a solution rather = than a problem. I would simply remove this last sentence. That sentence was added to ensure that readers understand that we are addre= ssing the requirement for both centralized and distributed control planes. 6. Application of Service Policy: I would definitely add the definition of= Service Policy into the Definition of Terms section. Here is a possible de= finition: =93A set of rules to administer, manage and control network resou= rces so that policy specific actions can be taken by Service Functions=94 Thanks, I'll add a definition for -04. 8. Elastic Service Delivery: We should also add the additional complexity = which Cloud/DC bring by the fact that instances can be added quickly and in= different locations within but also across DC=92s. Adjusting networks wit= h the same elasticity is hard to realize today. Makes sense, do you have suggested text? 10. Limited End-to-End Service Visibility: Beyond troubleshooting, there a= re a number of similar O&M issues which should also be addressed. Namely, = how Service Chains can be validated or how Service Chaining statistics can = be collected and correlated. It is very complex to verify that the chain h= as been setup properly, that correct flows are directed to the ingress of t= he chain and that packets directed to a chain actually flows through all Se= rvice Functions properly. All good points, do you have text in mind? If not, I can broaden the scope= in the next revision. --_000_B4CF12F64861194990FEA0AE39F9B1620EA54613xmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Andre,



On Sep 3, 2013, at 7:54 AM, Andre Beliveau <andre.beliveau@ericsson.com> wrote:

Hi,
 
Thank you for pursuing the definition of the problem s= tatement,  I am glad to see that it covers both the technical issues a= nd the operational issues.  I have concentrated my comments on the pro= blem statement part, chapter 2 as it has gone through a couple of iterations already and is more complete.  =

Th= anks a lot for taking the time to review it!

 
As section 3 and 4 are more related to the framework, = is there an intention to write a separate document for the framework or to = rename the document to problem statement and framework as indicated on the = BoF page?
 

Th= ere is a proposed framework document (http://datatracker= .ietf.org/doc/draft-boucadair-service-chaining-framework) as well that is in the process of being reviewed.  We are working to ali= gn terminology.  Having said that, I think that section 3/4 belong in = the problem statement: section 3 describes, at a high level, the problems s= olved, and section 4 will provide an overview of how chaining is used.  We expect detailed, per vertical, use case = drafts as well.


Here is a few specific comments on the problem area se= ction.
 
5. Service Chain construction:  The last statemen= t =93Such a control / management plane could be centrally controlled and ma= naged , or be distributed between a subset of end-systems=94 seem to refer = more to a solution rather than a problem.  I would simply remove this last sentence.
 

Th= at sentence was added to ensure that readers understand that we are address= ing the requirement for both centralized and distributed control planes.&nb= sp;

6. Application of Service Policy:  I would defini= tely add the definition of Service Policy into the Definition of Terms sect= ion. Here is a possible definition: =93A set of rules to administer, manage= and control network resources so that policy specific actions can be taken by Service Functions=94


Th= anks, I'll add a definition for -04.

 
8. Elastic Service Delivery:  We should also add = the additional complexity which Cloud/DC bring by the fact that instances c= an be added quickly and in different locations within but also across DC=92= s.  Adjusting networks with the same elasticity is hard to realize today.

Ma= kes sense, do you have suggested text?


 
10. Limited End-to-End Service Visibility:  Beyon= d troubleshooting, there are a number of similar O&M issues which shoul= d also be addressed.  Namely, how Service Chains can be validated or h= ow Service Chaining statistics can be collected and correlated.  It is very complex to verify that the chain has been= setup properly, that correct flows are directed to the ingress of the chai= n and that packets directed to a chain actually flows through all Service F= unctions properly.

Al= l good points, do you have text in mind?  If not, I can broaden the sc= ope in the next revision.



--_000_B4CF12F64861194990FEA0AE39F9B1620EA54613xmbrcdx14ciscoc_-- From jmoisand@juniper.net Tue Sep 3 12:50: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 207B321E80D3 for ; Tue, 3 Sep 2013 12:50:18 -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=[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 hQgui1QtZlwl for ; Tue, 3 Sep 2013 12:50:11 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9A73921E80D2 for ; Tue, 3 Sep 2013 12:50:11 -0700 (PDT) Received: from mail179-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE002.bigfish.com (10.236.130.65) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 19:50:11 +0000 Received: from mail179-co9 (localhost [127.0.0.1]) by mail179-co9-R.bigfish.com (Postfix) with ESMTP id F0A003001A4; Tue, 3 Sep 2013 19:50:10 +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(zz9371Ic85fh1453Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail179-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(52034003)(189002)(199002)(377454003)(18717965001)(74662001)(74502001)(561944002)(76796001)(76786001)(76576001)(54356001)(53806001)(77982001)(59766001)(47446002)(31966008)(33646001)(81816001)(56816003)(77096001)(80022001)(74876001)(65816001)(66066001)(74706001)(69226001)(15202345003)(50986001)(74366001)(81542001)(74316001)(4396001)(47976001)(47736001)(49866001)(19580395003)(51856001)(83072001)(46102001)(16236675002)(81686001)(79102001)(63696002)(19300405004)(56776001)(54316002)(76482001)(80976001)(15975445006)(81342001)(19580405001)(83322001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB250; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail179-co9 (localhost.localdomain [127.0.0.1]) by mail179-co9 (MessageSwitch) id 1378237799781292_6058; Tue, 3 Sep 2013 19:49:59 +0000 (UTC) Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.244]) by mail179-co9.bigfish.com (Postfix) with ESMTP id 01FA122004C; Tue, 3 Sep 2013 19:49:59 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 19:49:57 +0000 Received: from BN1PR05MB250.namprd05.prod.outlook.com (10.255.206.24) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 3 Sep 2013 19:49:55 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BN1PR05MB250.namprd05.prod.outlook.com (10.255.206.24) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 19:49:53 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.242]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.242]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 19:49:53 +0000 From: Jerome Moisand To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7sVQAbpmkm3U2WDNDdzlnoGZm0abnA Date: Tue, 3 Sep 2013 19:49:52 +0000 Message-ID: <36acd5c054c143898bbeaa7ed9e88e07@BN1PR05MB251.namprd05.prod.outlook.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F672511@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.232.2] x-forefront-prvs: 09583628E0 Content-Type: multipart/alternative; boundary="_000_36acd5c054c143898bbeaa7ed9e88e07BN1PR05MB251namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 03 Sep 2013 19:50:18 -0000 --_000_36acd5c054c143898bbeaa7ed9e88e07BN1PR05MB251namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim and al. This sounds like a nice start. >From my first pass, something seems missing: there is a reference to a Serv= ice Chaining Control Plane at the very end, in the list of milestones, but = nothing in the text alludes to it. And this is clearly NOT the same thing a= s Manageability. I do agree we need to think hard to such control plane mat= ters, and this should be made more explicit in the charter. As to the milestones, something about documenting use cases would seem in o= rder. As you probably know, both BBF SIMR and ETSI NFV have such ongoing ac= tivities, albeit very new, and this should be leveraged, no point re-invent= ing the wheel. I can be used as point of contact on the BBF side, by the wa= y. Anyhoo, I would just suggest to add a milestone about collecting use cas= es, either directly or via other standard bodies and industry forums. Tx Jerome From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, September 03, 2013 12:01 PM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_36acd5c054c143898bbeaa7ed9e88e07BN1PR05MB251namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim and al.=

 <= /p>

This sounds like a nice s= tart.

 <= /p>

From my first pass, somet= hing seems missing: there is a reference to a Service Chaining Control Plan= e at the very end, in the list of milestones, but nothing in the text alludes to it. And this is clearly NOT the same thing as Manag= eability. I do agree we need to think hard to such control plane matters, a= nd this should be made more explicit in the charter.

 <= /p>

As to the milestones, som= ething about documenting use cases would seem in order. As you probably kno= w, both BBF SIMR and ETSI NFV have such ongoing activities, albeit very new, and this should be leveraged, no point re-inventing the w= heel. I can be used as point of contact on the BBF side, by the way. Anyhoo= , I would just suggest to add a milestone about collecting use cases, eithe= r directly or via other standard bodies and industry forums.

 <= /p>

Tx

Jerome<= /p>

 <= /p>

 <= /p>

From: Jim Guic= hard (jguichar) [mailto:jguichar@cisco.com]
Sent: Tuesday, September 03, 2013 12:01 PM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal<= /p>

 

Greetings,

 

As we look forward to the f= ormation of a working group that will focus on network service chaining, I = would like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area= AD's. The following is a first draft of the charter and I invite you to ac= tively participate and provide inputs into this process.<= /p>

 

Proposed NSC WG Charter<= /span>

 

Existing service insertion = and deployment techniques have not evolved to meet modern network architect= ures and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, st= orage, and applications, have all undergone significant change in recent ye= ars: virtualization, network overlays, and orchestration are increasingly t= he norm. All of these have profound effects on network and services design.

 

Today, deploying new servic= es, or making changes to existing services, often requires network topology= changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o mostly-static service definitions. New service insertion and deployment t= echniques must enable the concept of service functions as shared resources,= and enable the linkage of these resources using service chains that represent the abstracted view of the r= equired service functions, and define the order in which they should be app= lied. When a service chain is instantiated in a network, specific instances= of service functions are selected, and a service topology is created and used for forwarding packets through = the service chain.

 

A basic service chain might= simply utilize an existing overlay technology to force traffic through the= necessary service functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chainin= g (NSC) working group focuses on new approaches to service insertion and de= ployment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary proto= cols for the creation of service chains, and the passing of metadata from t= he network to service functions, and between service functions. When possib= le, the WG will extend existing protocols to provide service chaining functionality, and any protocol exte= nsions will be reviewed by both the Network Service Chaining WG and by the = WG responsible for the protocol being extended.  

 

Specifically, the Network S= ervice Chaining WG is chartered to deliver the following work items: <= o:p>

 

1) Problem Statement: this = document will provide a summary of the problem space to be addressed by the= Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.

 

2) System Architecture: thi= s set of documents will provide a description of the architecture building = blocks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pl= ane: this document will describe on the wire data plane encapsulation in su= pport of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docu= ment will address service chaining operation, monitoring and troubleshootin= g including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are rea= lized.

 

Proposed Milestones:

 

Dec 2013 Request publicatio= n of an Informational document defining the Network Service Chaining proble= m statement to the IESG

 

Mar 2014 Request publicatio= n of informational documents defining the system architecture including pro= tocol requirements and framework to the IESG

 

May 2014 Request publicatio= n of a Standards Track document specifying the data-plane (including metada= ta) for Service Chaining to IESG

 

May 2014 Request publicatio= n of an informational document specifying Service Chaining Control Plane re= quirements to IESG

 

Dec 2014 Request publicatio= n of informational documents defining Service Chaining manageability requir= ements including MIBs, OAM, and information models to IESG =

 

 

--_000_36acd5c054c143898bbeaa7ed9e88e07BN1PR05MB251namprd05pro_-- From jguichar@cisco.com Tue Sep 3 13:20: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 A80D711E815C for ; Tue, 3 Sep 2013 13:20: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=[AWL=0.000, 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 QHBebR9djj7a for ; Tue, 3 Sep 2013 13:20:33 -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 790AA11E8136 for ; Tue, 3 Sep 2013 13:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5112; q=dns/txt; s=iport; t=1378239633; x=1379449233; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=94Yekwm+Wp+bDRkRRdR6bEF0XR/rOr/dr/mNciAw4rE=; b=iGyjqo9psm6RgvLSvHZt5TqDA879O7PMrgwuOZGqpOe/4/ggRXiKPLj6 YRvLtxrBD33CzB6kydNvFVRA8p/0p55d8MnTMtDYE5nved5nXVcOp97sG rF3PhumIod4WjgNPWieiyJABNmOfP/yq6VqfNUc3WlycF1bYhKrFu9T4Z A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAFJDJlKtJXHB/2dsb2JhbABbgwc1UcEfgS4WdIImAQQ6NAYFEgEIIhRCJQEBBAENBQgMB4dnDLlPji2BGDEHgx2BAAOUG4UJkDeDIIFxOQ X-IronPort-AV: E=Sophos;i="4.89,1016,1367971200"; d="scan'208";a="255136079" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 03 Sep 2013 20:20:33 +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 r83KKWMb013117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Sep 2013 20:20:32 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 15:20:32 -0500 From: "Jim Guichard (jguichar)" To: "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: NSC BoF Outcomes Thread-Index: Ac6YFyk/aYEs8EPbQVuX5dlVLbZ5nAQ1EMqA Date: Tue, 3 Sep 2013 20:20:32 +0000 Message-ID: <68B171751455884590F8E38E96416F363F672CBC@xmb-rcd-x01.cisco.com> In-Reply-To: <03bd01ce9817$346a3b10$9d3eb130$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.221.175] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Stewart Bryant \(stbryant\)" , Thomas Narten Subject: Re: [nsc] NSC BoF Outcomes 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, 03 Sep 2013 20:20:38 -0000 Hi Adrian, Thank you for this summary and for the kind words although I think "dazed" would be more appropriate than cool ;-) Please forgive my belated response but there have been numerous ongoing activities that I would like to share with the list as follows. Please see inline. On 8/13/13 7:20 AM, "Adrian Farrel" wrote: >Hi NSC list, > >Sorry for the delay in this email - I took a short break after Berlin. > >Thanks for the focus and effort that went into the NSC BoF in Berlin. >Thanks in >particular to Thomas and Jim for their work herding the ducks and >delivering the >BoF that the IESG asked for. Special mention for Jim in being so cool >turning up >to chair the BoF after a complete travel nightmare. > >I believe that the BoF delivered what the IESG had hoped to see. That is, >it >allowed a number of network operators from a broad spectrum of network >types to >describe the problem space that they are interested in. > >It was clear to me that there is strong interest among network operators >in >investigating the concept of service chaining, and among equipment >vendors and >solution providers in addressing the requirements. This is very promising >for >the potential of forming critical mass around working in this area. Jim> there is certainly strong interest for this work and the list of folks willing to participate/contribute grows daily. > >However, it was less clear to me that there is agreement about the layer >in >which service chaining has to be solved. I felt that some people were >talking >about service chaining in the application layer, some about service >chaining >based on flows, and some about per-packet services. The solutions are, I >think, >likely to be very different for the different problems, and it would be >wrong to >try to bunch them all together. Jim> although there was certainly initial confusion I believe this is becoming less and less so as we socialize the basic idea of service chaining; indeed, as we move forward we will reflect a more common understanding within the problem statement. > >Since it is clear that a lot of people want to work on this, the next >step must >be to get a little more focus. This could be a small amount of work, and >we may >find that consensus comes quickly and easily. But it may also mean that >some of >the use cases need to be discarded - that doesn't mean that they are not >valid, >only that they don't fit into the focused effort that may become a working >group. > >I suggest that the next steps (in no particular order) are as follows: >- Everyone should revise their drafts. Add clarity and focus. Merge with >other >drafts if appropriate. Jim> several of the existing drafts have been revised (several times) since the BoF in Berlin and new content/authors added. Several new drafts have been posted. Further revisions to these drafts is ongoing with many contributors to this process. >- Look for missing work. Is there a need for a simple and clear >over-arching >document? Terminology? Figures? Work cooperatively to fill the gaps. Jim> A number of new and/or updated drafts have been posted including a framework (draft-boucadair-service-chaining-framework), high-level requirements (draft-boucadair-chaining-requirements), and problem statement (draft-quinn-nsc-problem-statement). We expect these drafts to evolve as more review comments are received and the drafts further socialized within the IETF community. >- Use the mailing list to narrow down and reach agreement on what you >want to >work on. >- Start a thread on a potential WG charter. Maybe a couple of you (the BoF >chairs?) could agree to hold the pen and make a first draft? Try to get >the text >lean and tight. Try to get consensus. Jim> I have initiated a discussion thread today with a proposed WG charter for consideration by the mailing list. >- Start to plan for a WG-forming BoF. Look carefully at the dates for the >next >IETF (IETF-88, Vancouver) and decide whether the deadline is too tight. >Recall >that going off half-cocked does no-one any favors. See whether you can get >everything ready in time. Jim> a WG-forming BoF request has been posted to http://trac.tools.ietf.org/bof/trac/ >- Apply to the IAB for a BoF shepherd. This is an IAB member who will >give you >dedicated time and advice to help focus the technical effort and prepare >for a >successful WG-forming BoF. Jim> Joel Halpern has very kindly accepted to act as the BoF shepherd. Thank you Joel !! > >We do not, at this stage, need to worry about where within the IETF >structure >this work will sit. Let's continue to pursue the effort within the >Routing Area, >and defer discussion about where it will live until we have a better >handle on >the description of the problem. > >Don't forget that you can review the BoF via the Meetecho archive, the >usual >audio archive, and the online materials. > >Please come back to me with any questions. > >Thanks, >Adrian > From robmgl@cisco.com Tue Sep 3 14:00: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 7847921E80C3 for ; Tue, 3 Sep 2013 14:00:38 -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=[AWL=-0.000, 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 UZhHgQGixfMO for ; Tue, 3 Sep 2013 14:00:32 -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 64FA421E80AC for ; Tue, 3 Sep 2013 14:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36551; q=dns/txt; s=iport; t=1378242032; x=1379451632; h=from:to:subject:date:message-id:mime-version; bh=j8etoKl+CyXjzaWLKkkJ7jADGANEMYQ+FtfSELWaqKI=; b=PzB9r4XBVp9jYL/sP/pbbOyD6ZoVhulWt8GSRCCSmDeC6kxUm3dFzDzD yq+6zWz0qtZaIfmpl0k8m2+NeOXjgILeFi6yv5dd0VmL9E4XT0UtR7K1D vOnP8rZBUP0x7UDTUkYw6GEUmxSV34QCQ0pDfFnCZCNlaIh4mpCJv4/V8 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAMBMJlKtJXG//2dsb2JhbABbgkNENYN4vX8XgRcWdIIkAQEBBCNPGQEIEQEDAQELFgcDAgQwFAMGCQEEARIIh3qoDZE5jkOBAhYhgmo0gQADhUuOUJVAgyCBaQ X-IronPort-AV: E=Sophos;i="4.89,1016,1367971200"; d="scan'208,217";a="255120109" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 03 Sep 2013 21:00:27 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r83L0Ru6002186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Sep 2013 21:00:27 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 16:00:26 -0500 From: "Roberta Maglione (robmgl)" To: "jmoisand@juniper.net" , "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: Ac6o6J1arXOZ2m/vBEG19boxgCQmQw== Date: Tue, 3 Sep 2013 21:00:26 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D3B27FD@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D3B27FDxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 03 Sep 2013 21:00:38 -0000 --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D3B27FDxmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gSmVyb21lLA0KQSBjb3VwbGUgb2YgY29tbWVudHMgb24gdGhpcyBwb2ludDoNCj5BcyB0 byB0aGUgbWlsZXN0b25lcywgc29tZXRoaW5nIGFib3V0IGRvY3VtZW50aW5nIHVzZSBjYXNlcyB3 b3VsZCBzZWVtIGluIG9yZGVyLiBBcyB5b3UgcHJvYmFibHkga25vdywgYm90aCBCQkYgU0lNUiA+ YW5kIEVUU0kgTkZWIGhhdmUgc3VjaCBvbmdvaW5nIGFjdGl2aXRpZXMsDQoNCk15IHJlYWRpbmcg b2YgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgaXMgdGhhdCB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQgaXMg Z29pbmcgdG8gaW5jbHVkZSBhbHNvIHRoZSB1c2UgY2FzZXM6DQoNCjEpIFByb2JsZW0gU3RhdGVt ZW50OiB0aGlzIGRvY3VtZW50IHdpbGwgcHJvdmlkZSBhIHN1bW1hcnkgb2YgdGhlIHByb2JsZW0g c3BhY2UgdG8gYmUgYWRkcmVzc2VkIGJ5IHRoZSBOZXR3b3JrIFNlcnZpY2UgQ2hhaW5pbmcgV0cg aW5jbHVkaW5nIHRlcm1pbm9sb2d5IGFuZCBzYW1wbGUgdXNlIGNhc2VzDQoNClJlZ2FyZGluZyBs ZXZlcmFnaW5nIEJCRiB3b3JrOiBJIGZ1bGx5IGFncmVlIHdpdGggeW91IHdlIHNob3VsZCBub3Qg cmVwbGljYXRlIHRoZSBzYW1lIHdvcmsgaW4gZGlmZmVyZW50IFNET3MuIEhvd2V2ZXIsIGJhc2Vk IG9uIG15IHByZXZpb3VzIGV4cGVyaWVuY2UgaW4gQkJGLCBJIHRoaW5rIGl0IG1heSBiZSBkaWZm aWN1bHQgdG8gcmVmZXIgaW4gaW50ZXJuZXQgZHJhZnRzIHRvIEJCRiAgd29yayBpbiBwcm9ncmVz cyBkb2N1bWVudHMgYmVjYXVzZSB0aGVzZSBkb2N1bWVudHMgYXJlIG5vdCBwdWJsaWMgIHVudGls IHRoZXkgYXJlIHB1Ymxpc2hlZCwgc28gb25seSBCQkYgbWVtYmVycyBoYXZlIGFjY2VzcyB0byB0 aGVtLiBJdCBjb3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBhIGxpYWlzb24gZnJvbSBCQkYgdG8gbnNj IFdHIHRoYXQgc3VtbWFyaXplcyB0aGUgdXNlcyBjYXNlcyBhbHJlYWR5IGFncmVlZCBpbiBCQkYu DQoNCkJlc3QgUmVnYXJkcw0KUm9iZXJ0YQ0KRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEplcm9tZSBNb2lzYW5kDQpT ZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDMsIDIwMTMgMzo1MCBQTQ0KVG86IEppbSBHdWljaGFy ZCAoamd1aWNoYXIpOyBuc2NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbnNjXSBOU0MgV29ya2lu ZyBHcm91cCBDaGFydGVyIFByb3Bvc2FsDQoNCkhpIEppbSBhbmQgYWwuDQoNClRoaXMgc291bmRz IGxpa2UgYSBuaWNlIHN0YXJ0Lg0KDQpGcm9tIG15IGZpcnN0IHBhc3MsIHNvbWV0aGluZyBzZWVt cyBtaXNzaW5nOiB0aGVyZSBpcyBhIHJlZmVyZW5jZSB0byBhIFNlcnZpY2UgQ2hhaW5pbmcgQ29u dHJvbCBQbGFuZSBhdCB0aGUgdmVyeSBlbmQsIGluIHRoZSBsaXN0IG9mIG1pbGVzdG9uZXMsIGJ1 dCBub3RoaW5nIGluIHRoZSB0ZXh0IGFsbHVkZXMgdG8gaXQuIEFuZCB0aGlzIGlzIGNsZWFybHkg Tk9UIHRoZSBzYW1lIHRoaW5nIGFzIE1hbmFnZWFiaWxpdHkuIEkgZG8gYWdyZWUgd2UgbmVlZCB0 byB0aGluayBoYXJkIHRvIHN1Y2ggY29udHJvbCBwbGFuZSBtYXR0ZXJzLCBhbmQgdGhpcyBzaG91 bGQgYmUgbWFkZSBtb3JlIGV4cGxpY2l0IGluIHRoZSBjaGFydGVyLg0KDQpBcyB0byB0aGUgbWls ZXN0b25lcywgc29tZXRoaW5nIGFib3V0IGRvY3VtZW50aW5nIHVzZSBjYXNlcyB3b3VsZCBzZWVt IGluIG9yZGVyLiBBcyB5b3UgcHJvYmFibHkga25vdywgYm90aCBCQkYgU0lNUiBhbmQgRVRTSSBO RlYgaGF2ZSBzdWNoIG9uZ29pbmcgYWN0aXZpdGllcywgYWxiZWl0IHZlcnkgbmV3LCBhbmQgdGhp cyBzaG91bGQgYmUgbGV2ZXJhZ2VkLCBubyBwb2ludCByZS1pbnZlbnRpbmcgdGhlIHdoZWVsLiBJ IGNhbiBiZSB1c2VkIGFzIHBvaW50IG9mIGNvbnRhY3Qgb24gdGhlIEJCRiBzaWRlLCBieSB0aGUg d2F5LiBBbnlob28sIEkgd291bGQganVzdCBzdWdnZXN0IHRvIGFkZCBhIG1pbGVzdG9uZSBhYm91 dCBjb2xsZWN0aW5nIHVzZSBjYXNlcywgZWl0aGVyIGRpcmVjdGx5IG9yIHZpYSBvdGhlciBzdGFu ZGFyZCBib2RpZXMgYW5kIGluZHVzdHJ5IGZvcnVtcy4NCg0KVHgNCkplcm9tZQ0KDQoNCkZyb206 IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0KU2Vu dDogVHVlc2RheSwgU2VwdGVtYmVyIDAzLCAyMDEzIDEyOjAxIFBNDQpUbzogbnNjQGlldGYub3Jn PG1haWx0bzpuc2NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbnNjXSBOU0MgV29ya2luZyBHcm91cCBD aGFydGVyIFByb3Bvc2FsDQoNCkdyZWV0aW5ncywNCg0KQXMgd2UgbG9vayBmb3J3YXJkIHRvIHRo ZSBmb3JtYXRpb24gb2YgYSB3b3JraW5nIGdyb3VwIHRoYXQgd2lsbCBmb2N1cyBvbiBuZXR3b3Jr IHNlcnZpY2UgY2hhaW5pbmcsIEkgd291bGQgbGlrZSB0byBwcm9wb3NlIGEgZGlzY3Vzc2lvbiBv biB0aGlzIGFsaWFzIHRvIHRyeSBhbmQgcmVhY2ggY29uc2Vuc3VzIG9uIGFuIGluaXRpYWwgY2hh cnRlciBhcyByZXF1ZXN0ZWQgYnkgdGhlIHJvdXRpbmcgYXJlYSBBRCdzLiBUaGUgZm9sbG93aW5n IGlzIGEgZmlyc3QgZHJhZnQgb2YgdGhlIGNoYXJ0ZXIgYW5kIEkgaW52aXRlIHlvdSB0byBhY3Rp dmVseSBwYXJ0aWNpcGF0ZSBhbmQgcHJvdmlkZSBpbnB1dHMgaW50byB0aGlzIHByb2Nlc3MuDQoN ClByb3Bvc2VkIE5TQyBXRyBDaGFydGVyDQoNCkV4aXN0aW5nIHNlcnZpY2UgaW5zZXJ0aW9uIGFu ZCBkZXBsb3ltZW50IHRlY2huaXF1ZXMgaGF2ZSBub3QgZXZvbHZlZCB0byBtZWV0IG1vZGVybiBu ZXR3b3JrIGFyY2hpdGVjdHVyZXMgYW5kIGRvIG5vdCByZWZsZWN0IG11bHRpLXRlbmFuY3ksIHZp cnR1YWxpemF0aW9uLCBlbGFzdGljaXR5LCByaWNoIGNsYXNzaWZpY2F0aW9uLCBhbmQgb3RoZXIg bmV0d29yayByZXF1aXJlbWVudHMuIE5ldHdvcmtzLCBzZXJ2ZXJzLCBzdG9yYWdlLCBhbmQgYXBw bGljYXRpb25zLCBoYXZlIGFsbCB1bmRlcmdvbmUgc2lnbmlmaWNhbnQgY2hhbmdlIGluIHJlY2Vu dCB5ZWFyczogdmlydHVhbGl6YXRpb24sIG5ldHdvcmsgb3ZlcmxheXMsIGFuZCBvcmNoZXN0cmF0 aW9uIGFyZSBpbmNyZWFzaW5nbHkgdGhlIG5vcm0uIEFsbCBvZiB0aGVzZSBoYXZlIHByb2ZvdW5k IGVmZmVjdHMgb24gbmV0d29yayBhbmQgc2VydmljZXMgZGVzaWduLg0KDQpUb2RheSwgZGVwbG95 aW5nIG5ldyBzZXJ2aWNlcywgb3IgbWFraW5nIGNoYW5nZXMgdG8gZXhpc3Rpbmcgc2VydmljZXMs IG9mdGVuIHJlcXVpcmVzIG5ldHdvcmsgdG9wb2xvZ3kgY2hhbmdlcy4gQWRkaW5nIGFuZCByZW1v dmluZyBzZXJ2aWNlIGZ1bmN0aW9ucyBpcyBhIGNvbXBsZXgsIHJpc2t5IHRhc2ssIHRoYXQgaXMg dGllZCB0byBvcGVyYXRpb25hbGl6aW5nIHRvcG9sb2dpY2FsIGNoYW5nZXMgbGVhZGluZyB0byBt b3N0bHktc3RhdGljIHNlcnZpY2UgZGVmaW5pdGlvbnMuIE5ldyBzZXJ2aWNlIGluc2VydGlvbiBh bmQgZGVwbG95bWVudCB0ZWNobmlxdWVzIG11c3QgZW5hYmxlIHRoZSBjb25jZXB0IG9mIHNlcnZp Y2UgZnVuY3Rpb25zIGFzIHNoYXJlZCByZXNvdXJjZXMsIGFuZCBlbmFibGUgdGhlIGxpbmthZ2Ug b2YgdGhlc2UgcmVzb3VyY2VzIHVzaW5nIHNlcnZpY2UgY2hhaW5zIHRoYXQgcmVwcmVzZW50IHRo ZSBhYnN0cmFjdGVkIHZpZXcgb2YgdGhlIHJlcXVpcmVkIHNlcnZpY2UgZnVuY3Rpb25zLCBhbmQg ZGVmaW5lIHRoZSBvcmRlciBpbiB3aGljaCB0aGV5IHNob3VsZCBiZSBhcHBsaWVkLiBXaGVuIGEg c2VydmljZSBjaGFpbiBpcyBpbnN0YW50aWF0ZWQgaW4gYSBuZXR3b3JrLCBzcGVjaWZpYyBpbnN0 YW5jZXMgb2Ygc2VydmljZSBmdW5jdGlvbnMgYXJlIHNlbGVjdGVkLCBhbmQgYSBzZXJ2aWNlIHRv cG9sb2d5IGlzIGNyZWF0ZWQgYW5kIHVzZWQgZm9yIGZvcndhcmRpbmcgcGFja2V0cyB0aHJvdWdo IHRoZSBzZXJ2aWNlIGNoYWluLg0KDQpBIGJhc2ljIHNlcnZpY2UgY2hhaW4gbWlnaHQgc2ltcGx5 IHV0aWxpemUgYW4gZXhpc3Rpbmcgb3ZlcmxheSB0ZWNobm9sb2d5IHRvIGZvcmNlIHRyYWZmaWMg dGhyb3VnaCB0aGUgbmVjZXNzYXJ5IHNlcnZpY2UgZnVuY3Rpb25zLiBIb3dldmVyLCBhZGRpdGlv bmFsIGluZm9ybWF0aW9uIGVuYWJsZXMgYSByaWNoZXIgc2VydmljZSBjaGFpbiBmb3IgbW9yZSBh ZHZhbmNlZCBjb21wb3NpdGUgc2VydmljZXMuIEZvciBleGFtcGxlLCBzaGFyZWQgaW5mb3JtYXRp b24gKGUuZy4sIHRoZSByZXN1bHQgb2YgY2xhc3NpZmljYXRpb24pIGNhbiBiZSB1c2VkIHRvIG9m ZmxvYWQgc2VydmljZSBmdW5jdGlvbiBwcm9jZXNzaW5nIG9yIGluZm9ybSBvdGhlciBzZXJ2aWNl IGZ1bmN0aW9ucyBhYm91dCBpbmZvcm1hdGlvbiB0aGF0IHdvdWxkIG90aGVyd2lzZSBiZSBoYXJk IHRvIGdsZWFuLg0KDQpUaGUgTmV0d29yayBTZXJ2aWNlIENoYWluaW5nIChOU0MpIHdvcmtpbmcg Z3JvdXAgZm9jdXNlcyBvbiBuZXcgYXBwcm9hY2hlcyB0byBzZXJ2aWNlIGluc2VydGlvbiBhbmQg ZGVwbG95bWVudCwgcHJvdmlkaW5nIGEgZnJhbWV3b3JrIGZvciB0aGUgY29uc3RydWN0aW9uIG9m IHNlcnZpY2VzIGJ1aWx0IHVzaW5nIHNlcnZpY2UgY2hhaW5zLiBUaGUgV0cgZm9jdXNlcyBvbiB0 aGUgbmVjZXNzYXJ5IHByb3RvY29scyBmb3IgdGhlIGNyZWF0aW9uIG9mIHNlcnZpY2UgY2hhaW5z LCBhbmQgdGhlIHBhc3Npbmcgb2YgbWV0YWRhdGEgZnJvbSB0aGUgbmV0d29yayB0byBzZXJ2aWNl IGZ1bmN0aW9ucywgYW5kIGJldHdlZW4gc2VydmljZSBmdW5jdGlvbnMuIFdoZW4gcG9zc2libGUs IHRoZSBXRyB3aWxsIGV4dGVuZCBleGlzdGluZyBwcm90b2NvbHMgdG8gcHJvdmlkZSBzZXJ2aWNl IGNoYWluaW5nIGZ1bmN0aW9uYWxpdHksIGFuZCBhbnkgcHJvdG9jb2wgZXh0ZW5zaW9ucyB3aWxs IGJlIHJldmlld2VkIGJ5IGJvdGggdGhlIE5ldHdvcmsgU2VydmljZSBDaGFpbmluZyBXRyBhbmQg YnkgdGhlIFdHIHJlc3BvbnNpYmxlIGZvciB0aGUgcHJvdG9jb2wgYmVpbmcgZXh0ZW5kZWQuDQoN ClNwZWNpZmljYWxseSwgdGhlIE5ldHdvcmsgU2VydmljZSBDaGFpbmluZyBXRyBpcyBjaGFydGVy ZWQgdG8gZGVsaXZlciB0aGUgZm9sbG93aW5nIHdvcmsgaXRlbXM6DQoNCjEpIFByb2JsZW0gU3Rh dGVtZW50OiB0aGlzIGRvY3VtZW50IHdpbGwgcHJvdmlkZSBhIHN1bW1hcnkgb2YgdGhlIHByb2Js ZW0gc3BhY2UgdG8gYmUgYWRkcmVzc2VkIGJ5IHRoZSBOZXR3b3JrIFNlcnZpY2UgQ2hhaW5pbmcg V0cgaW5jbHVkaW5nIHRlcm1pbm9sb2d5IGFuZCBzYW1wbGUgdXNlIGNhc2VzLiAgQWRkaXRpb25h bGx5LCB0aGUgV0cgd2lsbCBub3JtYWxpemUgb24gbm9tZW5jbGF0dXJlIGFuZCBkZWZpbml0aW9u cyBmb3IgTmV0d29yayBTZXJ2aWNlIENoYWluaW5nLg0KDQoyKSBTeXN0ZW0gQXJjaGl0ZWN0dXJl OiB0aGlzIHNldCBvZiBkb2N1bWVudHMgd2lsbCBwcm92aWRlIGEgZGVzY3JpcHRpb24gb2YgdGhl IGFyY2hpdGVjdHVyZSBidWlsZGluZyBibG9ja3MgYW5kIHRoZWlyIHJlbGF0aW9uc2hpcHMgaW5j bHVkaW5nIGludGVyY29ubmVjdGlvbiwgcGxhY2VtZW50IG9mIGNhcGFiaWxpdGllcywgYW5kIHNl Y3VyaXR5IG1vZGVscywgYXMgd2VsbCBhcyByZXF1aXJlbWVudHMgb24gdGhlIGNvbnRyb2wgbWVj aGFuaXNtcyBhbmQgZGF0YSBwbGFuZSBlbmNhcHN1bGF0aW9uLg0KDQozKSBTZXJ2aWNlIENoYWlu aW5nIERhdGEgUGxhbmU6IHRoaXMgZG9jdW1lbnQgd2lsbCBkZXNjcmliZSBvbiB0aGUgd2lyZSBk YXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24gaW4gc3VwcG9ydCBvZiAoMikuICBBIHNpbmdsZSBlbmNh cHN1bGF0aW9uIHdpbGwgYmUgc2VsZWN0ZWQgaW4gb3JkZXIgdG8gZW5hYmxlIGludGVyb3BlcmFi aWxpdHkgb2YgZGF0YSBwbGFuZSBjb21wb25lbnRzLg0KDQo0KSBNYW5hZ2VhYmlsaXR5OiB0aGlz IGRvY3VtZW50IHdpbGwgYWRkcmVzcyBzZXJ2aWNlIGNoYWluaW5nIG9wZXJhdGlvbiwgbW9uaXRv cmluZyBhbmQgdHJvdWJsZXNob290aW5nIGluY2x1ZGluZyByZWxldmFudCBzZXJ2aWNlIGNoYWlu aW5nIG1vZGVscyBzdWNoIGFzIE1JQnMgb3IgWUFORyBtb2R1bGVzLCBhbG9uZyB3aXRoIHJlbGV2 YW50IE9BTSBjYXBhYmlsaXRpZXMgYW5kIGhvdyB0aGV5IGFyZSByZWFsaXplZC4NCg0KUHJvcG9z ZWQgTWlsZXN0b25lczoNCg0KRGVjIDIwMTMgUmVxdWVzdCBwdWJsaWNhdGlvbiBvZiBhbiBJbmZv cm1hdGlvbmFsIGRvY3VtZW50IGRlZmluaW5nIHRoZSBOZXR3b3JrIFNlcnZpY2UgQ2hhaW5pbmcg cHJvYmxlbSBzdGF0ZW1lbnQgdG8gdGhlIElFU0cNCg0KTWFyIDIwMTQgUmVxdWVzdCBwdWJsaWNh dGlvbiBvZiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50cyBkZWZpbmluZyB0aGUgc3lzdGVtIGFyY2hp dGVjdHVyZSBpbmNsdWRpbmcgcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdvcmsgdG8g dGhlIElFU0cNCg0KTWF5IDIwMTQgUmVxdWVzdCBwdWJsaWNhdGlvbiBvZiBhIFN0YW5kYXJkcyBU cmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIHRoZSBkYXRhLXBsYW5lIChpbmNsdWRpbmcgbWV0YWRh dGEpIGZvciBTZXJ2aWNlIENoYWluaW5nIHRvIElFU0cNCg0KTWF5IDIwMTQgUmVxdWVzdCBwdWJs aWNhdGlvbiBvZiBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IHNwZWNpZnlpbmcgU2VydmljZSBD aGFpbmluZyBDb250cm9sIFBsYW5lIHJlcXVpcmVtZW50cyB0byBJRVNHDQoNCkRlYyAyMDE0IFJl cXVlc3QgcHVibGljYXRpb24gb2YgaW5mb3JtYXRpb25hbCBkb2N1bWVudHMgZGVmaW5pbmcgU2Vy dmljZSBDaGFpbmluZyBtYW5hZ2VhYmlsaXR5IHJlcXVpcmVtZW50cyBpbmNsdWRpbmcgTUlCcywg T0FNLCBhbmQgaW5mb3JtYXRpb24gbW9kZWxzIHRvIElFU0cNCg0KDQo= --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D3B27FDxmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4KPCEtLQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsCgl7bWFyZ2luOjBpbjsKCW1hcmdpbi1ib3R0b206LjAw MDFwdDsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYifQotLT4KPC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xv cjojMUY0OTdEIj5IZWxsbyBKZXJvbWUsPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPkEgY291cGxlIG9m IGNvbW1lbnRzIG9uIHRoaXMgcG9pbnQ6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPiZndDtBcyB0byB0 aGUgbWlsZXN0b25lcywgc29tZXRoaW5nIGFib3V0IGRvY3VtZW50aW5nIHVzZSBjYXNlcyB3b3Vs ZCBzZWVtIGluIG9yZGVyLiBBcyB5b3UgcHJvYmFibHkga25vdywgYm90aCBCQkYgU0lNUiAmZ3Q7 YW5kIEVUU0kgTkZWIGhhdmUgc3VjaCBvbmdvaW5nIGFjdGl2aXRpZXMsPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+TXkgcmVhZGluZyBvZiB0aGUgcHJvcG9zZWQg Y2hhcnRlciBpcyB0aGF0IHRoZSBQcm9ibGVtIFN0YXRlbWVudCBpcyBnb2luZyB0byBpbmNsdWRl IGFsc28gdGhlIHVzZSBjYXNlczo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNv bG9yOmJsYWNrIj4xKSBQcm9ibGVtIFN0YXRlbWVudDogdGhpcyBkb2N1bWVudCB3aWxsIHByb3Zp ZGUgYSBzdW1tYXJ5IG9mIHRoZSBwcm9ibGVtIHNwYWNlIHRvIGJlIGFkZHJlc3NlZCBieSB0aGUg TmV0d29yayBTZXJ2aWNlIENoYWluaW5nIFdHIGluY2x1ZGluZyB0ZXJtaW5vbG9neSBhbmQNCiBz YW1wbGUgdXNlIGNhc2VzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9y OiMxRjQ5N0QiPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3 RCI+UmVnYXJkaW5nIGxldmVyYWdpbmcgQkJGIHdvcms6IEkgZnVsbHkgYWdyZWUgd2l0aCB5b3Ug d2Ugc2hvdWxkIG5vdCByZXBsaWNhdGUgdGhlIHNhbWUgd29yayBpbiBkaWZmZXJlbnQgU0RPcy4g SG93ZXZlciwgYmFzZWQgb24gbXkgcHJldmlvdXMgZXhwZXJpZW5jZSBpbg0KIEJCRiwgSSB0aGlu ayBpdCBtYXkgYmUgZGlmZmljdWx0IHRvIHJlZmVyIGluIGludGVybmV0IGRyYWZ0cyB0byBCQkYg Jm5ic3A7d29yayBpbiBwcm9ncmVzcyBkb2N1bWVudHMgYmVjYXVzZSB0aGVzZSBkb2N1bWVudHMg YXJlIG5vdCBwdWJsaWMgJm5ic3A7dW50aWwgdGhleSBhcmUgcHVibGlzaGVkLCBzbyBvbmx5IEJC RiBtZW1iZXJzIGhhdmUgYWNjZXNzIHRvIHRoZW0uIEl0IGNvdWxkIGJlIHVzZWZ1bCB0byBoYXZl IGEgbGlhaXNvbiBmcm9tIEJCRiB0byBuc2MNCiBXRyB0aGF0IHN1bW1hcml6ZXMgdGhlIHVzZXMg Y2FzZXMgYWxyZWFkeSBhZ3JlZWQgaW4gQkJGLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsgY29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPlJv YmVydGE8L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7IHBhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PC9hPjxzcGFuIHN0eWxlPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNj LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkplcm9tZSA8c3BhbiBjbGFz cz0iU3BlbGxFIj5Nb2lzYW5kPC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBTZXB0 ZW1iZXIgMDMsIDIwMTMgMzo1MCBQTTxicj4NCjxiPlRvOjwvYj4gSmltIDxzcGFuIGNsYXNzPSJT cGVsbEUiPkd1aWNoYXJkPC9zcGFuPiAoPHNwYW4gY2xhc3M9IlNwZWxsRSI+amd1aWNoYXI8L3Nw YW4+KTsgbnNjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbPHNwYW4gY2xhc3M9 IlNwZWxsRSI+bnNjPC9zcGFuPl0gTlNDIFdvcmtpbmcgR3JvdXAgQ2hhcnRlciBQcm9wb3NhbDwv c3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSIiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj5I aSBKaW0gYW5kIGFsLjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj5UaGlzIHNv dW5kcyBsaWtlIGEgbmljZSBzdGFydC4NCjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0 OTdEIj5Gcm9tIG15IGZpcnN0IHBhc3MsIHNvbWV0aGluZyBzZWVtcyBtaXNzaW5nOiB0aGVyZSBp cyBhIHJlZmVyZW5jZSB0byBhIFNlcnZpY2UgQ2hhaW5pbmcgQ29udHJvbCBQbGFuZSBhdCB0aGUg dmVyeSBlbmQsIGluIHRoZSBsaXN0IG9mIG1pbGVzdG9uZXMsDQogYnV0IG5vdGhpbmcgaW4gdGhl IHRleHQgYWxsdWRlcyB0byBpdC4gQW5kIHRoaXMgaXMgY2xlYXJseSBOT1QgdGhlIHNhbWUgdGhp bmcgYXMgTWFuYWdlYWJpbGl0eS4gSSBkbyBhZ3JlZSB3ZSBuZWVkIHRvIHRoaW5rIGhhcmQgdG8g c3VjaCBjb250cm9sIHBsYW5lIG1hdHRlcnMsIGFuZCB0aGlzIHNob3VsZCBiZSBtYWRlIG1vcmUg ZXhwbGljaXQgaW4gdGhlIGNoYXJ0ZXIuPC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5 N0QiPkFzIHRvIHRoZSBtaWxlc3RvbmVzLCBzb21ldGhpbmcgYWJvdXQgZG9jdW1lbnRpbmcgdXNl IGNhc2VzIHdvdWxkIHNlZW0gaW4gb3JkZXIuIEFzIHlvdSBwcm9iYWJseSBrbm93LCBib3RoIEJC RiBTSU1SIGFuZCBFVFNJIE5GViBoYXZlIHN1Y2gNCiBvbmdvaW5nIGFjdGl2aXRpZXMsIGFsYmVp dCB2ZXJ5IG5ldywgYW5kIHRoaXMgc2hvdWxkIGJlIGxldmVyYWdlZCwgbm8gcG9pbnQgcmUtaW52 ZW50aW5nIHRoZSB3aGVlbC4gSSBjYW4gYmUgdXNlZCBhcyBwb2ludCBvZiBjb250YWN0IG9uIHRo ZSBCQkYgc2lkZSwgYnkgdGhlIHdheS4NCjxzcGFuIGNsYXNzPSJTcGVsbEUiPkFueWhvbzwvc3Bh bj4sIEkgd291bGQganVzdCBzdWdnZXN0IHRvIGFkZCBhIG1pbGVzdG9uZSBhYm91dCBjb2xsZWN0 aW5nIHVzZSBjYXNlcywgZWl0aGVyIGRpcmVjdGx5IG9yIHZpYSBvdGhlciBzdGFuZGFyZCBib2Rp ZXMgYW5kIGluZHVzdHJ5IGZvcnVtcy48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IiI+PHNwYW4gY2xhc3M9IlNwZWxsRSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+VHg8L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj48L3NwYW4+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPkplcm9tZTwvc3Bhbj48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7OyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTsgYm9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0OyBw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIi PjxzcGFuIHN0eWxlPSIiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBKaW0NCjxzcGFuIGNsYXNzPSJTcGVsbEUiPkd1aWNoYXJkPC9zcGFuPiAoPHNwYW4gY2xhc3M9 IlNwZWxsRSI+amd1aWNoYXI8L3NwYW4+KSBbPC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 amd1aWNoYXJAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPm1haWx0bzpqZ3VpY2hhckBjaXNjby5jb208L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSIiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgU2VwdGVtYmVyIDAzLCAyMDEzIDEyOjAx IFBNPGJyPg0KPGI+VG86PC9iPiA8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuc2NAaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bnNjQGll dGYub3JnPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iIj48L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFs8 c3BhbiBjbGFzcz0iU3BlbGxFIj5uc2M8L3NwYW4+XSBOU0MgV29ya2luZyBHcm91cCBDaGFydGVy IFByb3Bvc2FsPC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsgY29sb3I6YmxhY2siPkdyZWV0aW5ncyw8L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj5BcyB3ZSBsb29rIGZvcndhcmQg dG8gdGhlIGZvcm1hdGlvbiBvZiBhIHdvcmtpbmcgZ3JvdXAgdGhhdCB3aWxsIGZvY3VzIG9uIG5l dHdvcmsgc2VydmljZSBjaGFpbmluZywgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgYSBkaXNjdXNz aW9uIG9uIHRoaXMNCiBhbGlhcyB0byB0cnkgYW5kIHJlYWNoIGNvbnNlbnN1cyBvbiBhbiBpbml0 aWFsIGNoYXJ0ZXIgYXMgcmVxdWVzdGVkIGJ5IHRoZSByb3V0aW5nIGFyZWEgQUQncy4gVGhlIGZv bGxvd2luZyBpcyBhIGZpcnN0IGRyYWZ0IG9mIHRoZSBjaGFydGVyIGFuZCBJIGludml0ZSB5b3Ug dG8gYWN0aXZlbHkgcGFydGljaXBhdGUgYW5kIHByb3ZpZGUgaW5wdXRzIGludG8gdGhpcyBwcm9j ZXNzLjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iIj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7OyBjb2xvcjpibGFjayI+UHJvcG9zZWQgTlNDIFdHIENoYXJ0ZXI8L3NwYW4+PC91Pjwv c3Bhbj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpi bGFjayI+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsgY29sb3I6YmxhY2siPkV4aXN0aW5nIHNlcnZpY2UgaW5zZXJ0aW9uIGFuZCBkZXBsb3lt ZW50IHRlY2huaXF1ZXMgaGF2ZSBub3QgZXZvbHZlZCB0byBtZWV0IG1vZGVybiBuZXR3b3JrIGFy Y2hpdGVjdHVyZXMgYW5kIGRvIG5vdCByZWZsZWN0IG11bHRpLXRlbmFuY3ksDQogdmlydHVhbGl6 YXRpb24sIGVsYXN0aWNpdHksIHJpY2ggY2xhc3NpZmljYXRpb24sIGFuZCBvdGhlciBuZXR3b3Jr IHJlcXVpcmVtZW50cy4gTmV0d29ya3MsIHNlcnZlcnMsIHN0b3JhZ2UsIGFuZCBhcHBsaWNhdGlv bnMsIGhhdmUgYWxsIHVuZGVyZ29uZSBzaWduaWZpY2FudCBjaGFuZ2UgaW4gcmVjZW50IHllYXJz OiB2aXJ0dWFsaXphdGlvbiwgbmV0d29yayBvdmVybGF5cywgYW5kIG9yY2hlc3RyYXRpb24gYXJl IGluY3JlYXNpbmdseSB0aGUgbm9ybS4NCiBBbGwgb2YgdGhlc2UgaGF2ZSBwcm9mb3VuZCBlZmZl Y3RzIG9uIG5ldHdvcmsgYW5kIHNlcnZpY2VzIGRlc2lnbi48L3NwYW4+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj5Ub2RheSwgZGVwbG95aW5n IG5ldyBzZXJ2aWNlcywgb3IgbWFraW5nIGNoYW5nZXMgdG8gZXhpc3Rpbmcgc2VydmljZXMsIG9m dGVuIHJlcXVpcmVzIG5ldHdvcmsgdG9wb2xvZ3kgY2hhbmdlcy4gQWRkaW5nIGFuZCByZW1vdmlu ZyBzZXJ2aWNlIGZ1bmN0aW9ucw0KIGlzIGEgY29tcGxleCwgcmlza3kgdGFzaywgdGhhdCBpcyB0 aWVkIHRvIG9wZXJhdGlvbmFsaXppbmcgdG9wb2xvZ2ljYWwgY2hhbmdlcyBsZWFkaW5nIHRvIG1v c3RseS1zdGF0aWMgc2VydmljZSBkZWZpbml0aW9ucy4gTmV3IHNlcnZpY2UgaW5zZXJ0aW9uIGFu ZCBkZXBsb3ltZW50IHRlY2huaXF1ZXMgbXVzdCBlbmFibGUgdGhlIGNvbmNlcHQgb2Ygc2Vydmlj ZSBmdW5jdGlvbnMgYXMgc2hhcmVkIHJlc291cmNlcywgYW5kIGVuYWJsZSB0aGUgbGlua2FnZQ0K IG9mIHRoZXNlIHJlc291cmNlcyB1c2luZyBzZXJ2aWNlIGNoYWlucyB0aGF0IHJlcHJlc2VudCB0 aGUgYWJzdHJhY3RlZCB2aWV3IG9mIHRoZSByZXF1aXJlZCBzZXJ2aWNlIGZ1bmN0aW9ucywgYW5k IGRlZmluZSB0aGUgb3JkZXIgaW4gd2hpY2ggdGhleSBzaG91bGQgYmUgYXBwbGllZC4gV2hlbiBh IHNlcnZpY2UgY2hhaW4gaXMgaW5zdGFudGlhdGVkIGluIGEgbmV0d29yaywgc3BlY2lmaWMgaW5z dGFuY2VzIG9mIHNlcnZpY2UgZnVuY3Rpb25zIGFyZQ0KIHNlbGVjdGVkLCBhbmQgYSBzZXJ2aWNl IHRvcG9sb2d5IGlzIGNyZWF0ZWQgYW5kIHVzZWQgZm9yIGZvcndhcmRpbmcgcGFja2V0cyB0aHJv dWdoIHRoZSBzZXJ2aWNlIGNoYWluLjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPkEgYmFzaWMgc2VydmljZSBjaGFpbiBtaWdodCBz aW1wbHkgdXRpbGl6ZSBhbiBleGlzdGluZyBvdmVybGF5IHRlY2hub2xvZ3kgdG8gZm9yY2UgdHJh ZmZpYyB0aHJvdWdoIHRoZSBuZWNlc3Nhcnkgc2VydmljZSBmdW5jdGlvbnMuIEhvd2V2ZXIsDQog YWRkaXRpb25hbCBpbmZvcm1hdGlvbiBlbmFibGVzIGEgcmljaGVyIHNlcnZpY2UgY2hhaW4gZm9y IG1vcmUgYWR2YW5jZWQgY29tcG9zaXRlIHNlcnZpY2VzLiBGb3IgZXhhbXBsZSwgc2hhcmVkIGlu Zm9ybWF0aW9uIChlLmcuLCB0aGUgcmVzdWx0IG9mIGNsYXNzaWZpY2F0aW9uKSBjYW4gYmUgdXNl ZCB0byBvZmZsb2FkIHNlcnZpY2UgZnVuY3Rpb24gcHJvY2Vzc2luZyBvciBpbmZvcm0gb3RoZXIg c2VydmljZSBmdW5jdGlvbnMgYWJvdXQgaW5mb3JtYXRpb24NCiB0aGF0IHdvdWxkIG90aGVyd2lz ZSBiZSBoYXJkIHRvIGdsZWFuLiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPlRoZSBOZXR3b3JrIFNlcnZpY2UgQ2hhaW5p bmcgKE5TQykgd29ya2luZyBncm91cCBmb2N1c2VzIG9uIG5ldyBhcHByb2FjaGVzIHRvIHNlcnZp Y2UgaW5zZXJ0aW9uIGFuZCBkZXBsb3ltZW50LCBwcm92aWRpbmcgYSBmcmFtZXdvcmsgZm9yIHRo ZQ0KIGNvbnN0cnVjdGlvbiBvZiBzZXJ2aWNlcyBidWlsdCB1c2luZyBzZXJ2aWNlIGNoYWlucy4g VGhlIFdHIGZvY3VzZXMgb24gdGhlIG5lY2Vzc2FyeSBwcm90b2NvbHMgZm9yIHRoZSBjcmVhdGlv biBvZiBzZXJ2aWNlIGNoYWlucywgYW5kIHRoZSBwYXNzaW5nIG9mIG1ldGFkYXRhIGZyb20gdGhl IG5ldHdvcmsgdG8gc2VydmljZSBmdW5jdGlvbnMsIGFuZCBiZXR3ZWVuIHNlcnZpY2UgZnVuY3Rp b25zLiBXaGVuIHBvc3NpYmxlLCB0aGUgV0cgd2lsbA0KIGV4dGVuZCBleGlzdGluZyBwcm90b2Nv bHMgdG8gcHJvdmlkZSBzZXJ2aWNlIGNoYWluaW5nIGZ1bmN0aW9uYWxpdHksIGFuZCBhbnkgcHJv dG9jb2wgZXh0ZW5zaW9ucyB3aWxsIGJlIHJldmlld2VkIGJ5IGJvdGggdGhlIE5ldHdvcmsgU2Vy dmljZSBDaGFpbmluZyBXRyBhbmQgYnkgdGhlIFdHIHJlc3BvbnNpYmxlIGZvciB0aGUgcHJvdG9j b2wgYmVpbmcgZXh0ZW5kZWQuICZuYnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPlNwZWNpZmljYWxseSwgdGhlIE5ldHdvcmsg U2VydmljZSBDaGFpbmluZyBXRyBpcyBjaGFydGVyZWQgdG8gZGVsaXZlciB0aGUgZm9sbG93aW5n IHdvcmsgaXRlbXM6Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+MSkgUHJvYmxlbSBTdGF0ZW1lbnQ6IHRoaXMgZG9jdW1l bnQgd2lsbCBwcm92aWRlIGEgc3VtbWFyeSBvZiB0aGUgcHJvYmxlbSBzcGFjZSB0byBiZSBhZGRy ZXNzZWQgYnkgdGhlIE5ldHdvcmsgU2VydmljZSBDaGFpbmluZyBXRyBpbmNsdWRpbmcNCiB0ZXJt aW5vbG9neSBhbmQgc2FtcGxlIHVzZSBjYXNlcy4gJm5ic3A7QWRkaXRpb25hbGx5LCB0aGUgV0cg d2lsbCBub3JtYWxpemUgb24gbm9tZW5jbGF0dXJlIGFuZCBkZWZpbml0aW9ucyBmb3IgTmV0d29y ayBTZXJ2aWNlIENoYWluaW5nLjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPjIpIFN5c3RlbSBBcmNoaXRlY3R1cmU6IHRoaXMgc2V0 IG9mIGRvY3VtZW50cyB3aWxsIHByb3ZpZGUgYSBkZXNjcmlwdGlvbiBvZiB0aGUgYXJjaGl0ZWN0 dXJlIGJ1aWxkaW5nIGJsb2NrcyBhbmQgdGhlaXIgcmVsYXRpb25zaGlwcyBpbmNsdWRpbmcNCiBp bnRlcmNvbm5lY3Rpb24sIHBsYWNlbWVudCBvZiBjYXBhYmlsaXRpZXMsIGFuZCBzZWN1cml0eSBt b2RlbHMsIGFzIHdlbGwgYXMgcmVxdWlyZW1lbnRzIG9uIHRoZSBjb250cm9sIG1lY2hhbmlzbXMg YW5kIGRhdGEgcGxhbmUgZW5jYXBzdWxhdGlvbi48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4zKSBTZXJ2aWNlIENoYWluaW5nIERh dGEgUGxhbmU6IHRoaXMgZG9jdW1lbnQgd2lsbCBkZXNjcmliZSBvbiB0aGUgd2lyZSBkYXRhIHBs YW5lIGVuY2Fwc3VsYXRpb24gaW4gc3VwcG9ydCBvZiAoMikuICZuYnNwO0Egc2luZ2xlIGVuY2Fw c3VsYXRpb24gd2lsbA0KIGJlIHNlbGVjdGVkIGluIG9yZGVyIHRvIGVuYWJsZSBpbnRlcm9wZXJh YmlsaXR5IG9mIGRhdGEgcGxhbmUgY29tcG9uZW50cy48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj40KSBNYW5hZ2VhYmlsaXR5OiB0 aGlzIGRvY3VtZW50IHdpbGwgYWRkcmVzcyBzZXJ2aWNlIGNoYWluaW5nIG9wZXJhdGlvbiwgbW9u aXRvcmluZyBhbmQgdHJvdWJsZXNob290aW5nIGluY2x1ZGluZyByZWxldmFudCBzZXJ2aWNlIGNo YWluaW5nIG1vZGVscw0KIHN1Y2ggYXMgTUlCcyBvciBZQU5HIG1vZHVsZXMsIGFsb25nIHdpdGgg cmVsZXZhbnQgT0FNIGNhcGFiaWxpdGllcyBhbmQgaG93IHRoZXkgYXJlIHJlYWxpemVkLjwvc3Bh bj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2si PlByb3Bvc2VkIE1pbGVzdG9uZXM6PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+RGVjIDIwMTMgUmVxdWVzdCBwdWJsaWNhdGlvbiBv ZiBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IGRlZmluaW5nIHRoZSBOZXR3b3JrIFNlcnZpY2Ug Q2hhaW5pbmcgcHJvYmxlbSBzdGF0ZW1lbnQgdG8gdGhlIElFU0c8L3NwYW4+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj5NYXIgMjAxNCBSZXF1 ZXN0IHB1YmxpY2F0aW9uIG9mIGluZm9ybWF0aW9uYWwgZG9jdW1lbnRzIGRlZmluaW5nIHRoZSBz eXN0ZW0gYXJjaGl0ZWN0dXJlIGluY2x1ZGluZyBwcm90b2NvbCByZXF1aXJlbWVudHMgYW5kIGZy YW1ld29yayB0byB0aGUNCiBJRVNHPC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+TWF5IDIwMTQgUmVxdWVzdCBwdWJsaWNhdGlvbiBv ZiBhIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIHRoZSBkYXRhLXBsYW5lIChp bmNsdWRpbmcgbWV0YWRhdGEpIGZvciBTZXJ2aWNlIENoYWluaW5nIHRvIElFU0c8L3NwYW4+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj5NYXkg MjAxNCBSZXF1ZXN0IHB1YmxpY2F0aW9uIG9mIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgc3Bl Y2lmeWluZyBTZXJ2aWNlIENoYWluaW5nIENvbnRyb2wgUGxhbmUgcmVxdWlyZW1lbnRzIHRvIElF U0c8L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9y OmJsYWNrIj5EZWMgMjAxNCBSZXF1ZXN0IHB1YmxpY2F0aW9uIG9mIGluZm9ybWF0aW9uYWwgZG9j dW1lbnRzIGRlZmluaW5nIFNlcnZpY2UgQ2hhaW5pbmcgbWFuYWdlYWJpbGl0eSByZXF1aXJlbWVu dHMgaW5jbHVkaW5nIE1JQnMsIE9BTSwgYW5kIGluZm9ybWF0aW9uDQogbW9kZWxzIHRvIElFU0cm bmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9IiI+PC9z cGFuPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D3B27FDxmbrcdx01ciscoc_-- From linda.dunbar@huawei.com Tue Sep 3 14:57: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 4784111E8143 for ; Tue, 3 Sep 2013 14:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.748 X-Spam-Level: X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[AWL=0.251, 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 sEVWOHCkbFDe for ; Tue, 3 Sep 2013 14:56:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 05EB821F86BE for ; Tue, 3 Sep 2013 14:56:35 -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.5-GA FastPath queued) with ESMTP id AWW33380; Tue, 03 Sep 2013 21:56:31 +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.146.0; Tue, 3 Sep 2013 22:54:44 +0100 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.146.0; Tue, 3 Sep 2013 22:54:56 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Tue, 3 Sep 2013 14:54:52 -0700 From: Linda Dunbar To: "Jim Guichard (jguichar)" , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: NSC BoF Outcomes Thread-Index: AQHOqOMaexl2TK45oEebqJb9MjX0ypm0iPEw Date: Tue, 3 Sep 2013 21:54:52 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9C8F1@dfweml509-mbx.china.huawei.com> References: <03bd01ce9817$346a3b10$9d3eb130$@olddog.co.uk> <68B171751455884590F8E38E96416F363F672CBC@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F672CBC@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.192.11.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 03 Sep 2013 21:57:00 -0000 My comments are inserted below marked by [Linda]: > -----Original Message----- >=20 > > > >However, it was less clear to me that there is agreement about the > layer > >in > >which service chaining has to be solved. I felt that some people were > >talking > >about service chaining in the application layer, some about service > >chaining > >based on flows, and some about per-packet services. The solutions are, > I > >think, > >likely to be very different for the different problems, and it would > be > >wrong to > >try to bunch them all together. >=20 > Jim> although there was certainly initial confusion I believe this is > becoming less and less so as we socialize the basic idea of service > chaining; indeed, as we move forward we will reflect a more common > understanding within the problem statement. It is still not clear which layer service functions are chained together. T= he draft-quinn-nsc-problem-statement-03 discussed chaining of service funct= ions that can be a network or application based packet treatment,..., to en= able a service offered by a network operators.=20 Today, there are many services offered by operators, e.g. L2VPN, L3VPN, P2P= paths, etc. So you can interpret NSC as chaining L2/L3 service functions (= like proxy forwarding, or fragmentation, etc.);=20 You can also interpret NSC as chaining L4 (and above) service functions; o= r chaining of mixed L4-L7 service functions (i.e. with some service nodes c= onsuming packets and reinitiate new packets). =20 Is NSC including all chaining of all those services?=20 Layer 2/3 service function chaining might require different schemes than La= yer 4-7 service chaining. Therefore, it is more effective to define them se= parately to make the discussion more focused. Linda Dunbar >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From jmoisand@juniper.net Tue Sep 3 15:10:34 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 32DC621E80AD for ; Tue, 3 Sep 2013 15:10:34 -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 b0RO0L4qb2If for ; Tue, 3 Sep 2013 15:10:27 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id CD3AB11E8143 for ; Tue, 3 Sep 2013 15:10:21 -0700 (PDT) Received: from mail217-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 22:10:11 +0000 Received: from mail217-tx2 (localhost [127.0.0.1]) by mail217-tx2-R.bigfish.com (Postfix) with ESMTP id DC5596801DF; Tue, 3 Sep 2013 22:10:11 +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: -20 X-BigFish: VPS-20(zz9371Ic89bh1453Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h8275dhz2fh2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail217-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(52034003)(199002)(189002)(81686001)(81342001)(65816001)(80022001)(69226001)(81816001)(66066001)(33646001)(51856001)(63696002)(46102001)(4396001)(76786001)(76796001)(76576001)(50986001)(47976001)(81542001)(79102001)(47736001)(49866001)(74366001)(74706001)(74316001)(561944002)(74876001)(80976001)(31966008)(74502001)(47446002)(74662001)(76482001)(56776001)(54316002)(77982001)(59766001)(83072001)(77096001)(56816003)(19580395003)(53806001)(19580405001)(83322001)(54356001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB252; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail217-tx2 (localhost.localdomain [127.0.0.1]) by mail217-tx2 (MessageSwitch) id 1378246209436551_26912; Tue, 3 Sep 2013 22:10:09 +0000 (UTC) Received: from TX2EHSMHS011.bigfish.com (unknown [10.9.14.244]) by mail217-tx2.bigfish.com (Postfix) with ESMTP id 5D83A500041; Tue, 3 Sep 2013 22:10:09 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS011.bigfish.com (10.9.99.111) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 22:10:08 +0000 Received: from BN1PR05MB252.namprd05.prod.outlook.com (10.255.206.12) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 3 Sep 2013 22:10:06 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BN1PR05MB252.namprd05.prod.outlook.com (10.255.206.12) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 22:10:05 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.242]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.242]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 22:10:05 +0000 From: Jerome Moisand To: "Roberta Maglione (robmgl)" , "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: Ac6o6J1aVQAbpmkm3U2WDNDdzlnoGQACKbYg Date: Tue, 3 Sep 2013 22:10:05 +0000 Message-ID: <94a335d4108844199675b6a673b6e1ba@BN1PR05MB251.namprd05.prod.outlook.com> References: <57C3345230A4F94C9B2F5CFA05D7F2BD1D3B27FD@xmb-rcd-x01.cisco.com> In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1D3B27FD@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.232.2] x-forefront-prvs: 09583628E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 03 Sep 2013 22:10:34 -0000 SGkgUm9iZXJ0YSwNCg0KU21hbGwgd29ybGTigKYgOy0pDQoNClVzZSBjYXNlczogc2VlbXMgdG8g bWUgd2Ugc2hvdWxkIHNlcGFyYXRlIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBmcm9tIHRoZSB1c2Ug Y2FzZXMsIHRoZSBmb3JtZXIgY291bGQgYmUgc3BlbGxlZCBvdXQgYXQgYSBoaWdoIGxldmVsIGFu ZCBob3BlZnVsbHkgYWdyZWVkIHVwb24sIHdoaWxlIGdhdGhlcmluZyAoYW5kIGJlZWZpbmcgdXAp IGEgZ29vZCBjb2xsZWN0aW9uIG9mIHVzZSBjYXNlcyB3aWxsIHByb2JhYmx5IHRha2UgbG9uZ2Vy LiBUaGlzIGlzIHdoeSBJIHN1Z2dlc3RlZCBhIHNlcGFyYXRlIG1pbGVzdG9uZSwgc29ycnkgSSB3 YXNu4oCZdCBjbGVhci4NCg0KQkJGOiB5ZXMsIGFncmVlZCB3aXRoIHlvdSBhYm91dCB0aGUgY2hh bGxlbmdlcyBvZiB1c2luZyByZWZlcmVuY2VzIGFuZCB0aGUgbmVlZCBmb3IgYSBsaWFpc29uLiBC dXQgZ2l2ZW4gdGhhdCBtYW55IG9mIHVzIGtub3cgZWFjaCBvdGhlciBmcm9tIHBhc3QgZXhwZXJp ZW5jZXMsIHdlIHNob3VsZCBiZSBhYmxlIHRvIG1ha2UgaXQgbGVzcyBmb3JtYWwgYW5kIG1vcmUg ZGlyZWN0bHkgY29sbGFib3JhdGl2ZS4gSeKAmWxsIHRlc3QgdGhlIHdhdGVycyBpbiB0aGlzIHJl c3BlY3QgYXQgdGhlIG5leHQgQkJGIChpbiBhIGNvdXBsZSBvZiB3ZWVrcykuIEnigJltIGNvLWVk aXRvciBvZiB0aGUgQkJGIFNJTVIgc3R1ZHkgZG9jdW1lbnQgb24gc2VydmljZSBjaGFpbmluZywg YnkgdGhlIHdheSwgaWYgdGhpcyBkaWRu4oCZdCBjcm9zcyB5b3VyIHJhZGFyLiBHb2FsIGlzIGVz c2VudGlhbGx5Li4uIHRvIGdhdGhlciAoYnJvYWRiYW5kLWNlbnRyaWMpIHVzZSBjYXNlcyENCg0K Q2hlZXJzLA0KSmVyb21lDQoNCg0KRnJvbTogUm9iZXJ0YSBNYWdsaW9uZSAocm9ibWdsKSBbbWFp bHRvOnJvYm1nbEBjaXNjby5jb21dIA0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDAzLCAyMDEz IDU6MDAgUE0NClRvOiBKZXJvbWUgTW9pc2FuZDsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IG5z Y0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIg UHJvcG9zYWwNCg0KSGVsbG8gSmVyb21lLA0KQSBjb3VwbGUgb2YgY29tbWVudHMgb24gdGhpcyBw b2ludDoNCj5BcyB0byB0aGUgbWlsZXN0b25lcywgc29tZXRoaW5nIGFib3V0IGRvY3VtZW50aW5n IHVzZSBjYXNlcyB3b3VsZCBzZWVtIGluIG9yZGVyLiBBcyB5b3UgcHJvYmFibHkga25vdywgYm90 aCBCQkYgU0lNUiA+YW5kIEVUU0kgTkZWIGhhdmUgc3VjaCBvbmdvaW5nIGFjdGl2aXRpZXMsDQrC oA0KTXkgcmVhZGluZyBvZiB0aGUgcHJvcG9zZWQgY2hhcnRlciBpcyB0aGF0IHRoZSBQcm9ibGVt IFN0YXRlbWVudCBpcyBnb2luZyB0byBpbmNsdWRlIGFsc28gdGhlIHVzZSBjYXNlczoNCsKgDQox KSBQcm9ibGVtIFN0YXRlbWVudDogdGhpcyBkb2N1bWVudCB3aWxsIHByb3ZpZGUgYSBzdW1tYXJ5 IG9mIHRoZSBwcm9ibGVtIHNwYWNlIHRvIGJlIGFkZHJlc3NlZCBieSB0aGUgTmV0d29yayBTZXJ2 aWNlIENoYWluaW5nIFdHIGluY2x1ZGluZyB0ZXJtaW5vbG9neSBhbmQgc2FtcGxlIHVzZSBjYXNl cw0KwqANClJlZ2FyZGluZyBsZXZlcmFnaW5nIEJCRiB3b3JrOiBJIGZ1bGx5IGFncmVlIHdpdGgg eW91IHdlIHNob3VsZCBub3QgcmVwbGljYXRlIHRoZSBzYW1lIHdvcmsgaW4gZGlmZmVyZW50IFNE T3MuIEhvd2V2ZXIsIGJhc2VkIG9uIG15IHByZXZpb3VzIGV4cGVyaWVuY2UgaW4gQkJGLCBJIHRo aW5rIGl0IG1heSBiZSBkaWZmaWN1bHQgdG8gcmVmZXIgaW4gaW50ZXJuZXQgZHJhZnRzIHRvIEJC RiDCoHdvcmsgaW4gcHJvZ3Jlc3MgZG9jdW1lbnRzIGJlY2F1c2UgdGhlc2UgZG9jdW1lbnRzIGFy ZSBub3QgcHVibGljIMKgdW50aWwgdGhleSBhcmUgcHVibGlzaGVkLCBzbyBvbmx5IEJCRiBtZW1i ZXJzIGhhdmUgYWNjZXNzIHRvIHRoZW0uIEl0IGNvdWxkIGJlIHVzZWZ1bCB0byBoYXZlIGEgbGlh aXNvbiBmcm9tIEJCRiB0byBuc2MgV0cgdGhhdCBzdW1tYXJpemVzIHRoZSB1c2VzIGNhc2VzIGFs cmVhZHkgYWdyZWVkIGluIEJCRi4NCsKgDQpCZXN0IFJlZ2FyZHMNClJvYmVydGENCkZyb206IG5z Yy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBKZXJvbWUgTW9pc2FuZA0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDAzLCAyMDEzIDM6 NTAgUE0NClRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgbnNjQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW25zY10gTlNDIFdvcmtpbmcgR3JvdXAgQ2hhcnRlciBQcm9wb3NhbA0KwqANCkhpIEpp bSBhbmQgYWwuDQrCoA0KVGhpcyBzb3VuZHMgbGlrZSBhIG5pY2Ugc3RhcnQuIA0KwqANCkZyb20g bXkgZmlyc3QgcGFzcywgc29tZXRoaW5nIHNlZW1zIG1pc3Npbmc6IHRoZXJlIGlzIGEgcmVmZXJl bmNlIHRvIGEgU2VydmljZSBDaGFpbmluZyBDb250cm9sIFBsYW5lIGF0IHRoZSB2ZXJ5IGVuZCwg aW4gdGhlIGxpc3Qgb2YgbWlsZXN0b25lcywgYnV0IG5vdGhpbmcgaW4gdGhlIHRleHQgYWxsdWRl cyB0byBpdC4gQW5kIHRoaXMgaXMgY2xlYXJseSBOT1QgdGhlIHNhbWUgdGhpbmcgYXMgTWFuYWdl YWJpbGl0eS4gSSBkbyBhZ3JlZSB3ZSBuZWVkIHRvIHRoaW5rIGhhcmQgdG8gc3VjaCBjb250cm9s IHBsYW5lIG1hdHRlcnMsIGFuZCB0aGlzIHNob3VsZCBiZSBtYWRlIG1vcmUgZXhwbGljaXQgaW4g dGhlIGNoYXJ0ZXIuDQrCoA0KQXMgdG8gdGhlIG1pbGVzdG9uZXMsIHNvbWV0aGluZyBhYm91dCBk b2N1bWVudGluZyB1c2UgY2FzZXMgd291bGQgc2VlbSBpbiBvcmRlci4gQXMgeW91IHByb2JhYmx5 IGtub3csIGJvdGggQkJGIFNJTVIgYW5kIEVUU0kgTkZWIGhhdmUgc3VjaCBvbmdvaW5nIGFjdGl2 aXRpZXMsIGFsYmVpdCB2ZXJ5IG5ldywgYW5kIHRoaXMgc2hvdWxkIGJlIGxldmVyYWdlZCwgbm8g cG9pbnQgcmUtaW52ZW50aW5nIHRoZSB3aGVlbC4gSSBjYW4gYmUgdXNlZCBhcyBwb2ludCBvZiBj b250YWN0IG9uIHRoZSBCQkYgc2lkZSwgYnkgdGhlIHdheS4gQW55aG9vLCBJIHdvdWxkIGp1c3Qg c3VnZ2VzdCB0byBhZGQgYSBtaWxlc3RvbmUgYWJvdXQgY29sbGVjdGluZyB1c2UgY2FzZXMsIGVp dGhlciBkaXJlY3RseSBvciB2aWEgb3RoZXIgc3RhbmRhcmQgYm9kaWVzIGFuZCBpbmR1c3RyeSBm b3J1bXMuDQrCoA0KVHgNCkplcm9tZQ0KwqANCsKgDQpGcm9tOiBKaW0gR3VpY2hhcmQgKGpndWlj aGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1i ZXIgMDMsIDIwMTMgMTI6MDEgUE0NClRvOiBuc2NAaWV0Zi5vcmcNClN1YmplY3Q6IFtuc2NdIE5T QyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCsKgDQpHcmVldGluZ3MsDQrCoA0KQXMg d2UgbG9vayBmb3J3YXJkIHRvIHRoZSBmb3JtYXRpb24gb2YgYSB3b3JraW5nIGdyb3VwIHRoYXQg d2lsbCBmb2N1cyBvbiBuZXR3b3JrIHNlcnZpY2UgY2hhaW5pbmcsIEkgd291bGQgbGlrZSB0byBw cm9wb3NlIGEgZGlzY3Vzc2lvbiBvbiB0aGlzIGFsaWFzIHRvIHRyeSBhbmQgcmVhY2ggY29uc2Vu c3VzIG9uIGFuIGluaXRpYWwgY2hhcnRlciBhcyByZXF1ZXN0ZWQgYnkgdGhlIHJvdXRpbmcgYXJl YSBBRCdzLiBUaGUgZm9sbG93aW5nIGlzIGEgZmlyc3QgZHJhZnQgb2YgdGhlIGNoYXJ0ZXIgYW5k IEkgaW52aXRlIHlvdSB0byBhY3RpdmVseSBwYXJ0aWNpcGF0ZSBhbmQgcHJvdmlkZSBpbnB1dHMg aW50byB0aGlzIHByb2Nlc3MuDQrCoA0KUHJvcG9zZWQgTlNDIFdHIENoYXJ0ZXINCsKgDQpFeGlz dGluZyBzZXJ2aWNlIGluc2VydGlvbiBhbmQgZGVwbG95bWVudCB0ZWNobmlxdWVzIGhhdmUgbm90 IGV2b2x2ZWQgdG8gbWVldCBtb2Rlcm4gbmV0d29yayBhcmNoaXRlY3R1cmVzIGFuZCBkbyBub3Qg cmVmbGVjdCBtdWx0aS10ZW5hbmN5LCB2aXJ0dWFsaXphdGlvbiwgZWxhc3RpY2l0eSwgcmljaCBj bGFzc2lmaWNhdGlvbiwgYW5kIG90aGVyIG5ldHdvcmsgcmVxdWlyZW1lbnRzLiBOZXR3b3Jrcywg c2VydmVycywgc3RvcmFnZSwgYW5kIGFwcGxpY2F0aW9ucywgaGF2ZSBhbGwgdW5kZXJnb25lIHNp Z25pZmljYW50IGNoYW5nZSBpbiByZWNlbnQgeWVhcnM6IHZpcnR1YWxpemF0aW9uLCBuZXR3b3Jr IG92ZXJsYXlzLCBhbmQgb3JjaGVzdHJhdGlvbiBhcmUgaW5jcmVhc2luZ2x5IHRoZSBub3JtLiBB bGwgb2YgdGhlc2UgaGF2ZSBwcm9mb3VuZCBlZmZlY3RzIG9uIG5ldHdvcmsgYW5kIHNlcnZpY2Vz IGRlc2lnbi4NCsKgDQpUb2RheSwgZGVwbG95aW5nIG5ldyBzZXJ2aWNlcywgb3IgbWFraW5nIGNo YW5nZXMgdG8gZXhpc3Rpbmcgc2VydmljZXMsIG9mdGVuIHJlcXVpcmVzIG5ldHdvcmsgdG9wb2xv Z3kgY2hhbmdlcy4gQWRkaW5nIGFuZCByZW1vdmluZyBzZXJ2aWNlIGZ1bmN0aW9ucyBpcyBhIGNv bXBsZXgsIHJpc2t5IHRhc2ssIHRoYXQgaXMgdGllZCB0byBvcGVyYXRpb25hbGl6aW5nIHRvcG9s b2dpY2FsIGNoYW5nZXMgbGVhZGluZyB0byBtb3N0bHktc3RhdGljIHNlcnZpY2UgZGVmaW5pdGlv bnMuIE5ldyBzZXJ2aWNlIGluc2VydGlvbiBhbmQgZGVwbG95bWVudCB0ZWNobmlxdWVzIG11c3Qg ZW5hYmxlIHRoZSBjb25jZXB0IG9mIHNlcnZpY2UgZnVuY3Rpb25zIGFzIHNoYXJlZCByZXNvdXJj ZXMsIGFuZCBlbmFibGUgdGhlIGxpbmthZ2Ugb2YgdGhlc2UgcmVzb3VyY2VzIHVzaW5nIHNlcnZp Y2UgY2hhaW5zIHRoYXQgcmVwcmVzZW50IHRoZSBhYnN0cmFjdGVkIHZpZXcgb2YgdGhlIHJlcXVp cmVkIHNlcnZpY2UgZnVuY3Rpb25zLCBhbmQgZGVmaW5lIHRoZSBvcmRlciBpbiB3aGljaCB0aGV5 IHNob3VsZCBiZSBhcHBsaWVkLiBXaGVuIGEgc2VydmljZSBjaGFpbiBpcyBpbnN0YW50aWF0ZWQg aW4gYSBuZXR3b3JrLCBzcGVjaWZpYyBpbnN0YW5jZXMgb2Ygc2VydmljZSBmdW5jdGlvbnMgYXJl IHNlbGVjdGVkLCBhbmQgYSBzZXJ2aWNlIHRvcG9sb2d5IGlzIGNyZWF0ZWQgYW5kIHVzZWQgZm9y IGZvcndhcmRpbmcgcGFja2V0cyB0aHJvdWdoIHRoZSBzZXJ2aWNlIGNoYWluLg0KwqANCkEgYmFz aWMgc2VydmljZSBjaGFpbiBtaWdodCBzaW1wbHkgdXRpbGl6ZSBhbiBleGlzdGluZyBvdmVybGF5 IHRlY2hub2xvZ3kgdG8gZm9yY2UgdHJhZmZpYyB0aHJvdWdoIHRoZSBuZWNlc3Nhcnkgc2Vydmlj ZSBmdW5jdGlvbnMuIEhvd2V2ZXIsIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gZW5hYmxlcyBhIHJp Y2hlciBzZXJ2aWNlIGNoYWluIGZvciBtb3JlIGFkdmFuY2VkIGNvbXBvc2l0ZSBzZXJ2aWNlcy4g Rm9yIGV4YW1wbGUsIHNoYXJlZCBpbmZvcm1hdGlvbiAoZS5nLiwgdGhlIHJlc3VsdCBvZiBjbGFz c2lmaWNhdGlvbikgY2FuIGJlIHVzZWQgdG8gb2ZmbG9hZCBzZXJ2aWNlIGZ1bmN0aW9uIHByb2Nl c3Npbmcgb3IgaW5mb3JtIG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zIGFib3V0IGluZm9ybWF0aW9u IHRoYXQgd291bGQgb3RoZXJ3aXNlIGJlIGhhcmQgdG8gZ2xlYW4uwqANCsKgDQpUaGUgTmV0d29y ayBTZXJ2aWNlIENoYWluaW5nIChOU0MpIHdvcmtpbmcgZ3JvdXAgZm9jdXNlcyBvbiBuZXcgYXBw cm9hY2hlcyB0byBzZXJ2aWNlIGluc2VydGlvbiBhbmQgZGVwbG95bWVudCwgcHJvdmlkaW5nIGEg ZnJhbWV3b3JrIGZvciB0aGUgY29uc3RydWN0aW9uIG9mIHNlcnZpY2VzIGJ1aWx0IHVzaW5nIHNl cnZpY2UgY2hhaW5zLiBUaGUgV0cgZm9jdXNlcyBvbiB0aGUgbmVjZXNzYXJ5IHByb3RvY29scyBm b3IgdGhlIGNyZWF0aW9uIG9mIHNlcnZpY2UgY2hhaW5zLCBhbmQgdGhlIHBhc3Npbmcgb2YgbWV0 YWRhdGEgZnJvbSB0aGUgbmV0d29yayB0byBzZXJ2aWNlIGZ1bmN0aW9ucywgYW5kIGJldHdlZW4g c2VydmljZSBmdW5jdGlvbnMuIFdoZW4gcG9zc2libGUsIHRoZSBXRyB3aWxsIGV4dGVuZCBleGlz dGluZyBwcm90b2NvbHMgdG8gcHJvdmlkZSBzZXJ2aWNlIGNoYWluaW5nIGZ1bmN0aW9uYWxpdHks IGFuZCBhbnkgcHJvdG9jb2wgZXh0ZW5zaW9ucyB3aWxsIGJlIHJldmlld2VkIGJ5IGJvdGggdGhl IE5ldHdvcmsgU2VydmljZSBDaGFpbmluZyBXRyBhbmQgYnkgdGhlIFdHIHJlc3BvbnNpYmxlIGZv ciB0aGUgcHJvdG9jb2wgYmVpbmcgZXh0ZW5kZWQuIMKgDQrCoA0KU3BlY2lmaWNhbGx5LCB0aGUg TmV0d29yayBTZXJ2aWNlIENoYWluaW5nIFdHIGlzIGNoYXJ0ZXJlZCB0byBkZWxpdmVyIHRoZSBm b2xsb3dpbmcgd29yayBpdGVtczrCoA0KwqANCjEpIFByb2JsZW0gU3RhdGVtZW50OiB0aGlzIGRv Y3VtZW50IHdpbGwgcHJvdmlkZSBhIHN1bW1hcnkgb2YgdGhlIHByb2JsZW0gc3BhY2UgdG8gYmUg YWRkcmVzc2VkIGJ5IHRoZSBOZXR3b3JrIFNlcnZpY2UgQ2hhaW5pbmcgV0cgaW5jbHVkaW5nIHRl cm1pbm9sb2d5IGFuZCBzYW1wbGUgdXNlIGNhc2VzLiDCoEFkZGl0aW9uYWxseSwgdGhlIFdHIHdp bGwgbm9ybWFsaXplIG9uIG5vbWVuY2xhdHVyZSBhbmQgZGVmaW5pdGlvbnMgZm9yIE5ldHdvcmsg U2VydmljZSBDaGFpbmluZy4NCsKgDQoyKSBTeXN0ZW0gQXJjaGl0ZWN0dXJlOiB0aGlzIHNldCBv ZiBkb2N1bWVudHMgd2lsbCBwcm92aWRlIGEgZGVzY3JpcHRpb24gb2YgdGhlIGFyY2hpdGVjdHVy ZSBidWlsZGluZyBibG9ja3MgYW5kIHRoZWlyIHJlbGF0aW9uc2hpcHMgaW5jbHVkaW5nIGludGVy Y29ubmVjdGlvbiwgcGxhY2VtZW50IG9mIGNhcGFiaWxpdGllcywgYW5kIHNlY3VyaXR5IG1vZGVs cywgYXMgd2VsbCBhcyByZXF1aXJlbWVudHMgb24gdGhlIGNvbnRyb2wgbWVjaGFuaXNtcyBhbmQg ZGF0YSBwbGFuZSBlbmNhcHN1bGF0aW9uLg0KwqANCjMpIFNlcnZpY2UgQ2hhaW5pbmcgRGF0YSBQ bGFuZTogdGhpcyBkb2N1bWVudCB3aWxsIGRlc2NyaWJlIG9uIHRoZSB3aXJlIGRhdGEgcGxhbmUg ZW5jYXBzdWxhdGlvbiBpbiBzdXBwb3J0IG9mICgyKS4gwqBBIHNpbmdsZSBlbmNhcHN1bGF0aW9u IHdpbGwgYmUgc2VsZWN0ZWQgaW4gb3JkZXIgdG8gZW5hYmxlIGludGVyb3BlcmFiaWxpdHkgb2Yg ZGF0YSBwbGFuZSBjb21wb25lbnRzLg0KwqANCjQpIE1hbmFnZWFiaWxpdHk6IHRoaXMgZG9jdW1l bnQgd2lsbCBhZGRyZXNzIHNlcnZpY2UgY2hhaW5pbmcgb3BlcmF0aW9uLCBtb25pdG9yaW5nIGFu ZCB0cm91Ymxlc2hvb3RpbmcgaW5jbHVkaW5nIHJlbGV2YW50IHNlcnZpY2UgY2hhaW5pbmcgbW9k ZWxzIHN1Y2ggYXMgTUlCcyBvciBZQU5HIG1vZHVsZXMsIGFsb25nIHdpdGggcmVsZXZhbnQgT0FN IGNhcGFiaWxpdGllcyBhbmQgaG93IHRoZXkgYXJlIHJlYWxpemVkLg0KwqANClByb3Bvc2VkIE1p bGVzdG9uZXM6DQrCoA0KRGVjIDIwMTMgUmVxdWVzdCBwdWJsaWNhdGlvbiBvZiBhbiBJbmZvcm1h dGlvbmFsIGRvY3VtZW50IGRlZmluaW5nIHRoZSBOZXR3b3JrIFNlcnZpY2UgQ2hhaW5pbmcgcHJv YmxlbSBzdGF0ZW1lbnQgdG8gdGhlIElFU0cNCsKgDQpNYXIgMjAxNCBSZXF1ZXN0IHB1YmxpY2F0 aW9uIG9mIGluZm9ybWF0aW9uYWwgZG9jdW1lbnRzIGRlZmluaW5nIHRoZSBzeXN0ZW0gYXJjaGl0 ZWN0dXJlIGluY2x1ZGluZyBwcm90b2NvbCByZXF1aXJlbWVudHMgYW5kIGZyYW1ld29yayB0byB0 aGUgSUVTRw0KwqANCk1heSAyMDE0IFJlcXVlc3QgcHVibGljYXRpb24gb2YgYSBTdGFuZGFyZHMg VHJhY2sgZG9jdW1lbnQgc3BlY2lmeWluZyB0aGUgZGF0YS1wbGFuZSAoaW5jbHVkaW5nIG1ldGFk YXRhKSBmb3IgU2VydmljZSBDaGFpbmluZyB0byBJRVNHDQrCoA0KTWF5IDIwMTQgUmVxdWVzdCBw dWJsaWNhdGlvbiBvZiBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IHNwZWNpZnlpbmcgU2Vydmlj ZSBDaGFpbmluZyBDb250cm9sIFBsYW5lIHJlcXVpcmVtZW50cyB0byBJRVNHDQrCoA0KRGVjIDIw MTQgUmVxdWVzdCBwdWJsaWNhdGlvbiBvZiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50cyBkZWZpbmlu ZyBTZXJ2aWNlIENoYWluaW5nIG1hbmFnZWFiaWxpdHkgcmVxdWlyZW1lbnRzIGluY2x1ZGluZyBN SUJzLCBPQU0sIGFuZCBpbmZvcm1hdGlvbiBtb2RlbHMgdG8gSUVTR8KgDQrCoA0KwqANCg== From tnadeau@lucidvision.com Tue Sep 3 15:18: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 A075821E8094 for ; Tue, 3 Sep 2013 15:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 NpG7NXTeFY4H for ; Tue, 3 Sep 2013 15:18:45 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7C47421F96ED for ; Tue, 3 Sep 2013 15:18:44 -0700 (PDT) Received: from [172.28.132.200] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 5563C2558A4C; Tue, 3 Sep 2013 18:18:41 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_DDD40C98-6714-43D4-B677-22159ECFBBFD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9C8F1@dfweml509-mbx.china.huawei.com> Date: Tue, 3 Sep 2013 18:18:38 -0400 Message-Id: <85C48C97-5F2D-4159-997E-A572E996D886@lucidvision.com> References: <03bd01ce9817$346a3b10$9d3eb130$@olddog.co.uk> <68B171751455884590F8E38E96416F363F672CBC@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C8F1@dfweml509-mbx.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1508) Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Stewart Bryant \(stbryant\)" , Thomas Narten , "adrian@olddog.co.uk" Subject: Re: [nsc] NSC BoF Outcomes 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, 03 Sep 2013 22:18:49 -0000 --Apple-Mail=_DDD40C98-6714-43D4-B677-22159ECFBBFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar = wrote: > My comments are inserted below marked by [Linda]: >=20 >> -----Original Message----- >>=20 >>>=20 >>> However, it was less clear to me that there is agreement about the >> layer >>> in >>> which service chaining has to be solved. I felt that some people = were >>> talking >>> about service chaining in the application layer, some about service >>> chaining >>> based on flows, and some about per-packet services. The solutions = are, >> I >>> think, >>> likely to be very different for the different problems, and it would >> be >>> wrong to >>> try to bunch them all together. >>=20 >> Jim> although there was certainly initial confusion I believe this is >> becoming less and less so as we socialize the basic idea of service >> chaining; indeed, as we move forward we will reflect a more common >> understanding within the problem statement. >=20 > It is still not clear which layer service functions are chained = together. The draft-quinn-nsc-problem-statement-03 discussed chaining of = service functions that can be a network or application based packet = treatment,..., to enable a service offered by a network operators.=20 Why do you think that matters? > Today, there are many services offered by operators, e.g. L2VPN, = L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 = service functions (like proxy forwarding, or fragmentation, etc.);=20 > You can also interpret NSC as chaining L4 (and above) service = functions; or chaining of mixed L4-L7 service functions (i.e. with some = service nodes consuming packets and reinitiate new packets). =20 You can, and people actually do implement this today.=20 > Is NSC including all chaining of all those services?=20 >=20 > Layer 2/3 service function chaining might require different schemes = than Layer 4-7 service chaining. Therefore, it is more effective to = define them separately to make the discussion more focused. I do not think so. I'd prefer to not make this only as = complicated as it needs to be, and no more. There are implementations of = Layer 2 and 3 chaining that are all done with the same = encap/provisioning systems.=20 --Tom >=20 > Linda Dunbar >=20 >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 --Apple-Mail=_DDD40C98-6714-43D4-B677-22159ECFBBFD 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 iQIcBAEBCgAGBQJSJmA/AAoJEPcO+I7eiUJZYCIQAKkVJd731AiuWrSwnyjPoF5H G3rBzNYCJ9mNVkIGzt82G2FLB+hLzhrxjkuJOToZJCNq2T7LCISCjLyI7IbiOXQu 3yZxz3EGhknN9+z5VTpn1tjI90z4t0lf1+7fSYUxWRdt4UD48lhnl80P0oCn+4V0 USSxTUfmQzjHFhpAUbMbeZVcRrYURDFWrV7OhLNpCpBip5U+hNLIeUfvww5bhrhq Nh5+wEM5jIrmtJP3owQD1HoHYYIzd++1K2OV7kSwsMNWShsNwHqGjcvRr6LuPc9g gNP2etsbhxXjQQCjiXmllO+d0XqLnBnZtgnzqS0b117oUrFCKQP+EjPe+BM09HjC FcRac2vj6dq8BEm8NAbdFALpYzOGyI3Qn5RjvVFrr8obhqElBKmEGpv4es4iOrMk fgEOPvu0QRT4Grk/9ekBMem+xARbCCVZwNrUTkm8Rrh8SuAGbObLxvfF0Ks7CTCi JAFRc0IwKafTpjiY01byxpqccwJsr5m4EsHdEXPM8ZqdtgDTLYfFZJ22GDINoh2O st5FWRjr79IChNSn9wn6rr4K+yutoVMGWuM6dBVOz38mZE0ALxKHuj1muTo7UVWT rFokf7mhlbwz2RI2IAoChsFFboczVLw8rdKBpVnDZ6TUv0BQ0i+8E+6Pq1SF/UOl HYA24usi2RmtZ0Uz6zBs =MN+t -----END PGP SIGNATURE----- --Apple-Mail=_DDD40C98-6714-43D4-B677-22159ECFBBFD-- From jguichar@cisco.com Tue Sep 3 15:19: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 0C2E221E8095 for ; Tue, 3 Sep 2013 15:19:03 -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=[AWL=0.000, 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 VD0GK1S-v4ju for ; Tue, 3 Sep 2013 15:18:49 -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 9FF8A21E8090 for ; Tue, 3 Sep 2013 15:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8731; q=dns/txt; s=iport; t=1378246729; x=1379456329; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Cu+cZXOhwa9TvGTolgbcKVlwPnBWfw/+zL+ft/A3AMo=; b=E+lTn6KfBfYXPx6TbRXLjG/8FvzFcBeuKlTVhop8+z1IwGpgp6C5zZot XE8gMQL7rk7RGoMs2Wr8Hyrj+AXdJNiasBjcSdWbWNgOQTkAmAbsHNzQR UO5KjlgtBE0wets3Q7iAMbi/sdEnivEU/WbWgXViKGogKOSxvZe8ZgG4/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAAZfJlKtJXHA/2dsb2JhbABbgweBBsEzgS4WdIIkAQEBBHIZAQgOAwEDAQELHTkUAwYIAQEEARIIh3q5VI5DgQACOIMdgQADlBuVQIMggWlB X-IronPort-AV: E=Sophos;i="4.89,1016,1367971200"; d="scan'208";a="254963357" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 03 Sep 2013 22:18:48 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r83MIm0J025537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Sep 2013 22:18:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 17:18:48 -0500 From: "Jim Guichard (jguichar)" To: Jerome Moisand , "Roberta Maglione (robmgl)" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: Ac6o6J1arXOZ2m/vBEG19boxgCQmQwAM6NaA//+/XAA= Date: Tue, 3 Sep 2013 22:18:46 +0000 Message-ID: <68B171751455884590F8E38E96416F363F67304A@xmb-rcd-x01.cisco.com> In-Reply-To: <94a335d4108844199675b6a673b6e1ba@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.82.221.175] Content-Type: text/plain; charset="Windows-1252" Content-ID: <41AFDC92B089534FB02F7F4C280CEC36@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 03 Sep 2013 22:19:03 -0000 Hi Jerome, On the use cases front we only intend to have high-level examples in the problem statement. More detailed use cases, for example mobility, should be separate I-D's as you pointed out and I would fully expect to see a number of them as we move forward with this work. Not sure that we can add this as a milestone though (?) On 9/3/13 6:10 PM, "Jerome Moisand" wrote: >Hi Roberta, > >Small world=8A ;-) > >Use cases: seems to me we should separate the problem statement from the >use cases, the former could be spelled out at a high level and hopefully >agreed upon, while gathering (and beefing up) a good collection of use >cases will probably take longer. This is why I suggested a separate >milestone, sorry I wasn=B9t clear. > >BBF: yes, agreed with you about the challenges of using references and >the need for a liaison. But given that many of us know each other from >past experiences, we should be able to make it less formal and more >directly collaborative. I=B9ll test the waters in this respect at the next >BBF (in a couple of weeks). I=B9m co-editor of the BBF SIMR study document >on service chaining, by the way, if this didn=B9t cross your radar. Goal i= s >essentially... to gather (broadband-centric) use cases! > >Cheers, >Jerome > > >From: Roberta Maglione (robmgl) [mailto:robmgl@cisco.com] >Sent: Tuesday, September 03, 2013 5:00 PM >To: Jerome Moisand; Jim Guichard (jguichar); nsc@ietf.org >Subject: RE: [nsc] NSC Working Group Charter Proposal > >Hello Jerome, >A couple of comments on this point: >>As to the milestones, something about documenting use cases would seem >>in order. As you probably know, both BBF SIMR >and ETSI NFV have such >>ongoing activities, >=20 >My reading of the proposed charter is that the Problem Statement is going >to include also the use cases: >=20 >1) Problem Statement: this document will provide a summary of the problem >space to be addressed by the Network Service Chaining WG including >terminology and sample use cases >=20 >Regarding leveraging BBF work: I fully agree with you we should not >replicate the same work in different SDOs. However, based on my previous >experience in BBF, I think it may be difficult to refer in internet >drafts to BBF work in progress documents because these documents are not >public until they are published, so only BBF members have access to >them. It could be useful to have a liaison from BBF to nsc WG that >summarizes the uses cases already agreed in BBF. >=20 >Best Regards >Roberta >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Jerome Moisand >Sent: Tuesday, September 03, 2013 3:50 PM >To: Jim Guichard (jguichar); nsc@ietf.org >Subject: Re: [nsc] NSC Working Group Charter Proposal >=20 >Hi Jim and al. >=20 >This sounds like a nice start. >=20 >From my first pass, something seems missing: there is a reference to a >Service Chaining Control Plane at the very end, in the list of >milestones, but nothing in the text alludes to it. And this is clearly >NOT the same thing as Manageability. I do agree we need to think hard to >such control plane matters, and this should be made more explicit in the >charter. >=20 >As to the milestones, something about documenting use cases would seem in >order. As you probably know, both BBF SIMR and ETSI NFV have such ongoing >activities, albeit very new, and this should be leveraged, no point >re-inventing the wheel. I can be used as point of contact on the BBF >side, by the way. Anyhoo, I would just suggest to add a milestone about >collecting use cases, either directly or via other standard bodies and >industry forums. >=20 >Tx >Jerome >=20 >=20 >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Tuesday, September 03, 2013 12:01 PM >To: nsc@ietf.org >Subject: [nsc] NSC Working Group Charter Proposal >=20 >Greetings, >=20 >As we look forward to the formation of a working group that will focus on >network service chaining, I would like to propose a discussion on this >alias to try and reach consensus on an initial charter as requested by >the routing area AD's. The following is a first draft of the charter and >I invite you to actively participate and provide inputs into this process. >=20 >Proposed NSC WG Charter >=20 >Existing service insertion and deployment techniques have not evolved to >meet modern network architectures and do not reflect multi-tenancy, >virtualization, elasticity, rich classification, and other network >requirements. Networks, servers, storage, and applications, have all >undergone significant change in recent years: virtualization, network >overlays, and orchestration are increasingly the norm. All of these have >profound effects on network and services design. >=20 >Today, deploying new services, or making changes to existing services, >often requires network topology changes. Adding and removing service >functions is a complex, risky task, that is tied to operationalizing >topological changes leading to mostly-static service definitions. New >service insertion and deployment techniques must enable the concept of >service functions as shared resources, and enable the linkage of these >resources using service chains that represent the abstracted view of the >required service functions, and define the order in which they should be >applied. When a service chain is instantiated in a network, specific >instances of service functions are selected, and a service topology is >created and used for forwarding packets through the service chain. >=20 >A basic service chain might simply utilize an existing overlay technology >to force traffic through the necessary service functions. However, >additional information enables a richer service chain for more advanced >composite services. For example, shared information (e.g., the result of >classification) can be used to offload service function processing or >inform other service functions about information that would otherwise be >hard to glean.=20 >=20 >The Network Service Chaining (NSC) working group focuses on new >approaches to service insertion and deployment, providing a framework for >the construction of services built using service chains. The WG focuses >on the necessary protocols for the creation of service chains, and the >passing of metadata from the network to service functions, and between >service functions. When possible, the WG will extend existing protocols >to provide service chaining functionality, and any protocol extensions >will be reviewed by both the Network Service Chaining WG and by the WG >responsible for the protocol being extended. >=20 >Specifically, the Network Service Chaining WG is chartered to deliver the >following work items: >=20 >1) Problem Statement: this document will provide a summary of the problem >space to be addressed by the Network Service Chaining WG including >terminology and sample use cases. Additionally, the WG will normalize on >nomenclature and definitions for Network Service Chaining. >=20 >2) System Architecture: this set of documents will provide a description >of the architecture building blocks and their relationships including >interconnection, placement of capabilities, and security models, as well >as requirements on the control mechanisms and data plane encapsulation. >=20 >3) Service Chaining Data Plane: this document will describe on the wire >data plane encapsulation in support of (2). A single encapsulation will >be selected in order to enable interoperability of data plane components. >=20 >4) Manageability: this document will address service chaining operation, >monitoring and troubleshooting including relevant service chaining models >such as MIBs or YANG modules, along with relevant OAM capabilities and >how they are realized. >=20 >Proposed Milestones: >=20 >Dec 2013 Request publication of an Informational document defining the >Network Service Chaining problem statement to the IESG >=20 >Mar 2014 Request publication of informational documents defining the >system architecture including protocol requirements and framework to the >IESG >=20 >May 2014 Request publication of a Standards Track document specifying the >data-plane (including metadata) for Service Chaining to IESG >=20 >May 2014 Request publication of an informational document specifying >Service Chaining Control Plane requirements to IESG >=20 >Dec 2014 Request publication of informational documents defining Service >Chaining manageability requirements including MIBs, OAM, and information >models to IESG=20 >=20 >=20 From tnadeau@lucidvision.com Tue Sep 3 15:22: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 AC31521E808A for ; Tue, 3 Sep 2013 15:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Fxj1SXJgv01z for ; Tue, 3 Sep 2013 15:21:51 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id AEF1611E8146 for ; Tue, 3 Sep 2013 15:21:50 -0700 (PDT) Received: from [172.28.132.200] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 05A562558A79; Tue, 3 Sep 2013 18:21:48 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CC758C5A-872E-4776-8947-16F29F46B0ED"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: <94a335d4108844199675b6a673b6e1ba@BN1PR05MB251.namprd05.prod.outlook.com> Date: Tue, 3 Sep 2013 18:21:46 -0400 Message-Id: References: <57C3345230A4F94C9B2F5CFA05D7F2BD1D3B27FD@xmb-rcd-x01.cisco.com> <94a335d4108844199675b6a673b6e1ba@BN1PR05MB251.namprd05.prod.outlook.com> To: Jerome Moisand X-Mailer: Apple Mail (2.1508) Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Roberta Maglione \(robmgl\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 03 Sep 2013 22:22:03 -0000 --Apple-Mail=_CC758C5A-872E-4776-8947-16F29F46B0ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 3, 2013:6:10 PM, at 6:10 PM, Jerome Moisand = wrote: > Hi Roberta, >=20 > Small world=85 ;-) >=20 > Use cases: seems to me we should separate the problem statement from = the use cases, the former could be spelled out at a high level and = hopefully agreed upon, while gathering (and beefing up) a good = collection of use cases will probably take longer. This is why I = suggested a separate milestone, sorry I wasn=92t clear. Bonjour! I agree; this is for its own document. But for the moment as a = means of illustrating the problem space, we put some high level examples = in here. Of course, these can be moved to a problem statement draft(s) = later. --Tom > BBF: yes, agreed with you about the challenges of using references and = the need for a liaison. But given that many of us know each other from = past experiences, we should be able to make it less formal and more = directly collaborative. I=92ll test the waters in this respect at the = next BBF (in a couple of weeks). I=92m co-editor of the BBF SIMR study = document on service chaining, by the way, if this didn=92t cross your = radar. Goal is essentially... to gather (broadband-centric) use cases! >=20 > Cheers, > Jerome >=20 >=20 > From: Roberta Maglione (robmgl) [mailto:robmgl@cisco.com]=20 > Sent: Tuesday, September 03, 2013 5:00 PM > To: Jerome Moisand; Jim Guichard (jguichar); nsc@ietf.org > Subject: RE: [nsc] NSC Working Group Charter Proposal >=20 > Hello Jerome, > A couple of comments on this point: >> As to the milestones, something about documenting use cases would = seem in order. As you probably know, both BBF SIMR >and ETSI NFV have = such ongoing activities, > =20 > My reading of the proposed charter is that the Problem Statement is = going to include also the use cases: > =20 > 1) Problem Statement: this document will provide a summary of the = problem space to be addressed by the Network Service Chaining WG = including terminology and sample use cases > =20 > Regarding leveraging BBF work: I fully agree with you we should not = replicate the same work in different SDOs. However, based on my previous = experience in BBF, I think it may be difficult to refer in internet = drafts to BBF work in progress documents because these documents are = not public until they are published, so only BBF members have access to = them. It could be useful to have a liaison from BBF to nsc WG that = summarizes the uses cases already agreed in BBF. > =20 > Best Regards > Roberta > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of = Jerome Moisand > Sent: Tuesday, September 03, 2013 3:50 PM > To: Jim Guichard (jguichar); nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal > =20 > Hi Jim and al. > =20 > This sounds like a nice start.=20 > =20 > =46rom my first pass, something seems missing: there is a reference to = a Service Chaining Control Plane at the very end, in the list of = milestones, but nothing in the text alludes to it. And this is clearly = NOT the same thing as Manageability. I do agree we need to think hard to = such control plane matters, and this should be made more explicit in the = charter. > =20 > As to the milestones, something about documenting use cases would seem = in order. As you probably know, both BBF SIMR and ETSI NFV have such = ongoing activities, albeit very new, and this should be leveraged, no = point re-inventing the wheel. I can be used as point of contact on the = BBF side, by the way. Anyhoo, I would just suggest to add a milestone = about collecting use cases, either directly or via other standard bodies = and industry forums. > =20 > Tx > Jerome > =20 > =20 > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 > Sent: Tuesday, September 03, 2013 12:01 PM > To: nsc@ietf.org > Subject: [nsc] NSC Working Group Charter Proposal > =20 > Greetings, > =20 > As we look forward to the formation of a working group that will focus = on network service chaining, I would like to propose a discussion on = this alias to try and reach consensus on an initial charter as requested = by the routing area AD's. The following is a first draft of the charter = and I invite you to actively participate and provide inputs into this = process. > =20 > Proposed NSC WG Charter > =20 > Existing service insertion and deployment techniques have not evolved = to meet modern network architectures and do not reflect multi-tenancy, = virtualization, elasticity, rich classification, and other network = requirements. Networks, servers, storage, and applications, have all = undergone significant change in recent years: virtualization, network = overlays, and orchestration are increasingly the norm. All of these have = profound effects on network and services design. > =20 > Today, deploying new services, or making changes to existing services, = often requires network topology changes. Adding and removing service = functions is a complex, risky task, that is tied to operationalizing = topological changes leading to mostly-static service definitions. New = service insertion and deployment techniques must enable the concept of = service functions as shared resources, and enable the linkage of these = resources using service chains that represent the abstracted view of the = required service functions, and define the order in which they should be = applied. When a service chain is instantiated in a network, specific = instances of service functions are selected, and a service topology is = created and used for forwarding packets through the service chain. > =20 > A basic service chain might simply utilize an existing overlay = technology to force traffic through the necessary service functions. = However, additional information enables a richer service chain for more = advanced composite services. For example, shared information (e.g., the = result of classification) can be used to offload service function = processing or inform other service functions about information that = would otherwise be hard to glean.=20 > =20 > The Network Service Chaining (NSC) working group focuses on new = approaches to service insertion and deployment, providing a framework = for the construction of services built using service chains. The WG = focuses on the necessary protocols for the creation of service chains, = and the passing of metadata from the network to service functions, and = between service functions. When possible, the WG will extend existing = protocols to provide service chaining functionality, and any protocol = extensions will be reviewed by both the Network Service Chaining WG and = by the WG responsible for the protocol being extended. =20 > =20 > Specifically, the Network Service Chaining WG is chartered to deliver = the following work items:=20 > =20 > 1) Problem Statement: this document will provide a summary of the = problem space to be addressed by the Network Service Chaining WG = including terminology and sample use cases. Additionally, the WG will = normalize on nomenclature and definitions for Network Service Chaining. > =20 > 2) System Architecture: this set of documents will provide a = description of the architecture building blocks and their relationships = including interconnection, placement of capabilities, and security = models, as well as requirements on the control mechanisms and data plane = encapsulation. > =20 > 3) Service Chaining Data Plane: this document will describe on the = wire data plane encapsulation in support of (2). A single encapsulation = will be selected in order to enable interoperability of data plane = components. > =20 > 4) Manageability: this document will address service chaining = operation, monitoring and troubleshooting including relevant service = chaining models such as MIBs or YANG modules, along with relevant OAM = capabilities and how they are realized. > =20 > Proposed Milestones: > =20 > Dec 2013 Request publication of an Informational document defining the = Network Service Chaining problem statement to the IESG > =20 > Mar 2014 Request publication of informational documents defining the = system architecture including protocol requirements and framework to the = IESG > =20 > May 2014 Request publication of a Standards Track document specifying = the data-plane (including metadata) for Service Chaining to IESG > =20 > May 2014 Request publication of an informational document specifying = Service Chaining Control Plane requirements to IESG > =20 > Dec 2014 Request publication of informational documents defining = Service Chaining manageability requirements including MIBs, OAM, and = information models to IESG=20 > =20 > =20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc --Apple-Mail=_CC758C5A-872E-4776-8947-16F29F46B0ED 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 iQIcBAEBCgAGBQJSJmD6AAoJEPcO+I7eiUJZXJAQAKS9WJfZ7+JdxxDTagPmcYel LYeSeS6NmfCooROis8k5c2xEJsAiw3Sn+FyLqPVvLHYbgrB9JVyWvtSwTYZRtmrS bdO6N1ocL0TOzgsC/fzVmKdnP8HSLgik/MeQ1MfLQhBHbSgVT5vjgzMMruyFfEc1 3dZYxwDynfkB9Jb0WuUNJGzCrIQmxLbhnkS9kFdS0nKdt0AqkuZebHD2DeH6SsLx ZIKk3hfoE/S4UioRpT4EhQQjj6EpZmAx2TWveazWHznSuQSoWzrWEA2QwM4GGJm/ CnfiGVyqqsvPRuVg8U3oLiPI1G2AZfof7tdHMR9ka3xhXOOPZJ1eUj5MAopDZJFk fRrEEegNDuNhzUltClxr/Uxhv7gT6Lj0e9iwYz+z5SLFUAEW2kuqN8U16DdmRfAO sJOFduSK2qxQvQXBdBpc+mOzB22Zks5GFQBREnkDYlGDm6GTbfDDXUF19J0tLORg 8UYDW2sTyMmRh/v1f+CXRBZbjJl6oEcQDa02dtur8VOPo+9Ik9vo47pT2wwk6HGN HoXxd3EMuQ6NjRX4ESaCZJrm+/dU63cHX8lBH/hP4ifVjMJO+sgAvigJzChXrb0j v/l8opmIsktgpT1AxpRexMI8zTyRqmQ5kWA7H5HMwzSTbIXiqzbYd0kOFqRLgFVd nge4II16cyrS6rEqvEDG =+ck0 -----END PGP SIGNATURE----- --Apple-Mail=_CC758C5A-872E-4776-8947-16F29F46B0ED-- From linda.dunbar@huawei.com Tue Sep 3 15:26: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 CF86911E8142 for ; Tue, 3 Sep 2013 15:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.768 X-Spam-Level: X-Spam-Status: No, score=-5.768 tagged_above=-999 required=5 tests=[AWL=0.231, 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 oNpBYSpatcFg for ; Tue, 3 Sep 2013 15:26:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 04E3711E814C for ; Tue, 3 Sep 2013 15:25:57 -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.5-GA FastPath queued) with ESMTP id AVA25373; Tue, 03 Sep 2013 22:25:55 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Sep 2013 23:25:32 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Sep 2013 23:25:45 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Tue, 3 Sep 2013 15:25:39 -0700 From: Linda Dunbar To: Thomas Nadeau Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqOMaexl2TK45oEebqJb9MjX0ypm0iPEwgACBtAD//4uI4A== Date: Tue, 3 Sep 2013 22:25:39 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9C961@dfweml509-mbx.china.huawei.com> References: <03bd01ce9817$346a3b10$9d3eb130$@olddog.co.uk> <68B171751455884590F8E38E96416F363F672CBC@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C8F1@dfweml509-mbx.china.huawei.com> <85C48C97-5F2D-4159-997E-A572E996D886@lucidvision.com> In-Reply-To: <85C48C97-5F2D-4159-997E-A572E996D886@lucidvision.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Stewart Bryant \(stbryant\)" , Thomas Narten , "adrian@olddog.co.uk" Subject: Re: [nsc] NSC BoF Outcomes 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, 03 Sep 2013 22:26:30 -0000 Thomas,=20 Are you saying that the NSC scope includes chaining Layer 2, Layer 3 servic= e functions, Layer 4 to Layer 7 service functions, and various combination = of them?=20 Linda > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Tuesday, September 03, 2013 5:19 PM > To: Linda Dunbar > Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org; Thomas > Narten; Stewart Bryant (stbryant) > Subject: Re: [nsc] NSC BoF Outcomes >=20 >=20 > On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar > wrote: >=20 > > My comments are inserted below marked by [Linda]: > > > >> -----Original Message----- > >> > >>> > >>> However, it was less clear to me that there is agreement about the > >> layer > >>> in > >>> which service chaining has to be solved. I felt that some people > >>> were talking about service chaining in the application layer, some > >>> about service chaining based on flows, and some about per-packet > >>> services. The solutions are, > >> I > >>> think, > >>> likely to be very different for the different problems, and it > would > >> be > >>> wrong to > >>> try to bunch them all together. > >> > >> Jim> although there was certainly initial confusion I believe this > is > >> becoming less and less so as we socialize the basic idea of service > >> chaining; indeed, as we move forward we will reflect a more common > >> understanding within the problem statement. > > > > It is still not clear which layer service functions are chained > together. The draft-quinn-nsc-problem-statement-03 discussed chaining > of service functions that can be a network or application based packet > treatment,..., to enable a service offered by a network operators. >=20 > Why do you think that matters? >=20 > > Today, there are many services offered by operators, e.g. L2VPN, > > L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 > service functions (like proxy forwarding, or fragmentation, etc.); You > can also interpret NSC as chaining L4 (and above) service functions; > or chaining of mixed L4-L7 service functions (i.e. with some service > nodes consuming packets and reinitiate new packets). >=20 > You can, and people actually do implement this today. >=20 > > Is NSC including all chaining of all those services? > > > > Layer 2/3 service function chaining might require different schemes > than Layer 4-7 service chaining. Therefore, it is more effective to > define them separately to make the discussion more focused. >=20 > I do not think so. I'd prefer to not make this only as > complicated as it needs to be, and no more. There are implementations > of Layer 2 and 3 chaining that are all done with the same > encap/provisioning systems. >=20 > --Tom >=20 >=20 > > > > Linda Dunbar > > > >> > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > From tnadeau@lucidvision.com Tue Sep 3 15:28: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 51AA021E8051 for ; Tue, 3 Sep 2013 15:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 fiyTZWNVaBr6 for ; Tue, 3 Sep 2013 15:28:03 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 48D2E11E814C for ; Tue, 3 Sep 2013 15:28:03 -0700 (PDT) Received: from [172.28.132.200] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 8CC272558AB5; Tue, 3 Sep 2013 18:27:51 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_AF80BC94-C4C3-4AB4-8D44-3491C8573900"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9C961@dfweml509-mbx.china.huawei.com> Date: Tue, 3 Sep 2013 18:27:49 -0400 Message-Id: <5F1E64BA-FA49-489B-982F-BAFF64FD9CC9@lucidvision.com> References: <03bd01ce9817$346a3b10$9d3eb130$@olddog.co.uk> <68B171751455884590F8E38E96416F363F672CBC@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C8F1@dfweml509-mbx.china.huawei.com> <85C48C97-5F2D-4159-997E-A572E996D886@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C961@dfweml509-mbx.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1508) Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Thomas Narten , "adrian@olddog.co.uk" , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 03 Sep 2013 22:28:08 -0000 --Apple-Mail=_AF80BC94-C4C3-4AB4-8D44-3491C8573900 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar = wrote: > Thomas,=20 >=20 > Are you saying that the NSC scope includes chaining Layer 2, Layer 3 = service functions, Layer 4 to Layer 7 service functions, and various = combination of them?=20 I don't define the scope; thats up to the ADs. Could you please answer the question below?=20 --Tom >=20 > Linda >=20 >> -----Original Message----- >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: Tuesday, September 03, 2013 5:19 PM >> To: Linda Dunbar >> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org; = Thomas >> Narten; Stewart Bryant (stbryant) >> Subject: Re: [nsc] NSC BoF Outcomes >>=20 >>=20 >> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar >> wrote: >>=20 >>> My comments are inserted below marked by [Linda]: >>>=20 >>>> -----Original Message----- >>>>=20 >>>>>=20 >>>>> However, it was less clear to me that there is agreement about the >>>> layer >>>>> in >>>>> which service chaining has to be solved. I felt that some people >>>>> were talking about service chaining in the application layer, some >>>>> about service chaining based on flows, and some about per-packet >>>>> services. The solutions are, >>>> I >>>>> think, >>>>> likely to be very different for the different problems, and it >> would >>>> be >>>>> wrong to >>>>> try to bunch them all together. >>>>=20 >>>> Jim> although there was certainly initial confusion I believe this >> is >>>> becoming less and less so as we socialize the basic idea of service >>>> chaining; indeed, as we move forward we will reflect a more common >>>> understanding within the problem statement. >>>=20 >>> It is still not clear which layer service functions are chained >> together. The draft-quinn-nsc-problem-statement-03 discussed chaining >> of service functions that can be a network or application based = packet >> treatment,..., to enable a service offered by a network operators. >>=20 >> Why do you think that matters? >>=20 >>> Today, there are many services offered by operators, e.g. L2VPN, >>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 >> service functions (like proxy forwarding, or fragmentation, etc.); = You >> can also interpret NSC as chaining L4 (and above) service functions; >> or chaining of mixed L4-L7 service functions (i.e. with some service >> nodes consuming packets and reinitiate new packets). >>=20 >> You can, and people actually do implement this today. >>=20 >>> Is NSC including all chaining of all those services? >>>=20 >>> Layer 2/3 service function chaining might require different schemes >> than Layer 4-7 service chaining. Therefore, it is more effective to >> define them separately to make the discussion more focused. >>=20 >> I do not think so. I'd prefer to not make this only as >> complicated as it needs to be, and no more. There are implementations >> of Layer 2 and 3 chaining that are all done with the same >> encap/provisioning systems. >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Linda Dunbar >>>=20 >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 --Apple-Mail=_AF80BC94-C4C3-4AB4-8D44-3491C8573900 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 iQIcBAEBCgAGBQJSJmJlAAoJEPcO+I7eiUJZIK0P/1T6Ufv/JQEFpa96Vh0nmgw4 r5QFdd/JaRHKqhUhfdhnMO8oRI6n/K9QEr3yYW9ShKivRGaHCngXDE+eSrWckHK5 9Axa8aqufbT107f/uvzNGtNXsSJvmXuUcfmKQ4YFYIwTrwAOL+2MXfLgxqamEe41 jo0hIk1fICf9/Y22J7RrBcqGnIG3MKhnntP5rRBwaUqKu8sEmzVik3rhD45f0nha QPNukSYFfK3L4rTr8n6J3eDGUpHkFk5LeHegXA+CKuYmk1mBeTlQkkc8V/Envi4q 7f9CrzvD2bamS7ejvxPBxJBijsEzq814mXwkYuV3+rHvZ24nlUyzYbpFbmY1umJI j8+pziacIcT2Wl27/4g1ngHNgdP1vH4nOKbRKJHLnVatXu3EUZ+Z+DwtTc9rl87+ Qyz5SGBOJ/p2IFdz9FkyopJfD+4XevEpg8da9XNr+7p/XM5ivlJKcLhrwwbvJb9B QYT4zN3AARPSB+FCde+LvQIczYGgxnnFvBsHJT0L8s6ZZUBJvBhqObPiwBewQmsh hrj1UHZJHlEj2ZsqqfWb2oBFAo5iVhHdAnvsbigvBE80I/GlGVoAuAhpmVujFGY5 UVA4mGVx/Ukw2Py+M0NOpGRt9sqoSPwoB0RLvjQX7SE1UUIGGgeR1Jw3OBecusP8 4d6rfGSdEpBDMQnU4YCX =A1Fj -----END PGP SIGNATURE----- --Apple-Mail=_AF80BC94-C4C3-4AB4-8D44-3491C8573900-- From syiu@Brocade.com Tue Sep 3 15:40: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 8E7BC11E8147 for ; Tue, 3 Sep 2013 15:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSAYZ5WA8PAo for ; Tue, 3 Sep 2013 15:40:53 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 79C8C21F9196 for ; Tue, 3 Sep 2013 15:40:52 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r83M2e4Z001330; Tue, 3 Sep 2013 15:40:41 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1en9nh969u-20 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 03 Sep 2013 15:40:41 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 3 Sep 2013 15:40:40 -0700 Received: from HQ1-EXCH03.corp.brocade.com ([fe80::411c:2971:c59e:5e4a]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Tue, 3 Sep 2013 15:40:37 -0700 From: Sean Yiu To: "Jim Guichard (jguichar)" , "tnarten@us.ibm.com" Date: Tue, 3 Sep 2013 15:40:35 -0700 Thread-Topic: More well defined Use Cases for NSC Thread-Index: Ac6ffOBqOL27Xl6OQu2npQbwq4pijwC67BiAAaKpUkA= Message-ID: References: <68B171751455884590F8E38E96416F363F64E696@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F64E696@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: multipart/alternative; boundary="_000_B6C027A5FECE784EACD1A9EDCCA0B7A2467F513253HQ1EXCH03corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-03_06:2013-09-03, 2013-09-03, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309030074 Cc: "nsc@ietf.org" Subject: Re: [nsc] More well defined Use Cases for NSC 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, 03 Sep 2013 22:40:58 -0000 --_000_B6C027A5FECE784EACD1A9EDCCA0B7A2467F513253HQ1EXCH03corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim Not saying we should document all use cases but, as you said, having some r= epresentational use cases in DC, mobility etc would help. Certainly not bec= ause we don't understand the concepts - which we all do I think - but to kn= ock down some clear ones so we can get more traction around NSV. Also, thes= e use cases should help us think through the somewhat heuristical nature of= service chaining - ie not all services are to be done in any sequence - th= ere are some that need to be done in a prescribed sequence. In turn, this h= opefully helps in getting NSV synthesized with better clarity in the archi= tecture phase of NSV. Eg where and how these perhaps built- in dependencies= are stated statically and/or dynamically, how the info is disseminated a= nd how the sequence is enforced, monitored , redirected and so on. Thanks Sean From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Monday, August 26, 2013 6:29 AM To: Sean Yiu; tnarten@us.ibm.com Cc: nsc@ietf.org Subject: Re: More well defined Use Cases for NSC Hi Sean, I think the problem with use cases is that there are so many of them and in= a lot of cases will be specific to a given operators deployment choices. T= rying to document them all serves little purpose other than informational i= mho. Having said that we will have high level use cases in the problem sta= tement draft. For more detailed use cases I think we will probably see a se= t of drafts that are relevant to specific deployment environments such as m= obility, DC, etc, and I think that is the right approach. From: Sean Yiu > Date: Thursday, August 22, 2013 5:20 PM To: Microsoft Office User >, = "tnarten@us.ibm.com" > Cc: "nsc@ietf.org" > Subject: More well defined Use Cases for NSC Hi Jim and Thomas et al Thanks much for moving NSC along. I do have some suggestions on the next st= eps - i.e. is that towards the WG sessions (in Vancouver ?) , one main fo= cus could be documenting some well defined use cases - especially from the = network operators' point of view. Closest I found so far seems to be http:= //datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases/?include_te= xt=3D1 but it has a few examples only (at least at this point in time). It= would be helpful to have more use cases from a larger set of network oper= ators. I also suggest that in collecting and documenting these use cases, w= e be "strict" to ourselves to state the use cases in some level of detail a= nd not jump into Architecture and even implementation details. Thanks Sean --_000_B6C027A5FECE784EACD1A9EDCCA0B7A2467F513253HQ1EXCH03corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim

 

Not saying we should document all use cases but, as = you said, having some representational use cases in DC, mobility etc would = help. Certainly not because we don’t understand the concepts – = which we all do I think – but to knock down some clear ones so we can= get more traction around NSV. Also, these use cases should help us think t= hrough the somewhat heuristical nature of service chaining – ie not a= ll services are to be done in any sequence – there are some that need= to be done in a prescribed sequence. In turn, this hopefully helps in &nbs= p;getting NSV synthesized with better clarity in the architecture phase of = NSV. Eg where and how these perhaps built- in dependencies are stated stati= cally and/or dynamically,  how the info is disseminated  and how = the sequence is enforced, monitored , redirected and so on.

 <= /span>

Thanks


Sean

 

From: Jim Guicha= rd (jguichar) [mailto:jguichar@cisco.com]
Sent: Monday, August 2= 6, 2013 6:29 AM
To: Sean Yiu; tnarten@us.ibm.com
Cc: ns= c@ietf.org
Subject: Re: More well defined Use Cases for NSC =

 

Hi Sean,=

 

I think the problem w= ith use cases is that there are so many of them and in a lot of cases will = be specific to a given operators deployment choices. Trying to document the= m all serves little purpose other than informational imho.  Having sai= d that we will have high level use cases in the problem statement draft. Fo= r more detailed use cases I think we will probably see a set of drafts that= are relevant to specific deployment environments such as mobility, DC, etc= , and I think that is the right approach. 

=

 

From: Sean Yiu <= syiu@Brocade.com>
Date: Thursday, August 22, 2013 5:20 PM
To: Microsoft Office User <= ;jguichar@cisco.com>, "tnarten@us.ibm.com" <tnarten@us.ibm.com>
Cc: &q= uot;nsc@ietf.org" <nsc@ietf.org>
Subject: More well defin= ed Use Cases for NSC

=  

Hi  Jim= and Thomas et al

 

Thanks much for moving NSC along. I do have some suggestio= ns on the next steps – i.e.  is that towards the WG sessions (in= Vancouver ?) , one main  focus could be documenting some well defined= use cases – especially from the network operators’  point= of view. Closest I found so far seems to be http://datatracker.ietf.org/doc/draft-liu-se= rvice-chaining-use-cases/?include_text=3D1 but it has a few examples only (at least at this point in time).=  It would be helpful to have  more use cases from a larger set o= f network operators. I also suggest that in collecting and documenting thes= e use cases, we be “strict” to ourselves to state the use cases= in some level of detail and not jump into Architecture and even implementa= tion details.

 

Thanks


Sean

 

= --_000_B6C027A5FECE784EACD1A9EDCCA0B7A2467F513253HQ1EXCH03corp_-- From linda.dunbar@huawei.com Tue Sep 3 15:48: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 9BDF921F9CC2 for ; Tue, 3 Sep 2013 15:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.215, 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 DHdvtoKNXxgG for ; Tue, 3 Sep 2013 15:48:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1938821F9DE9 for ; Tue, 3 Sep 2013 15:48:11 -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.5-GA FastPath queued) with ESMTP id AWW35344; Tue, 03 Sep 2013 22:48:09 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Sep 2013 23:47:52 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Sep 2013 23:48:06 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Tue, 3 Sep 2013 15:47:59 -0700 From: Linda Dunbar To: Thomas Nadeau Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqOMaexl2TK45oEebqJb9MjX0ypm0iPEwgACBtAD//4uI4IAAdwmA//+LeYA= Date: Tue, 3 Sep 2013 22:47:59 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9C99F@dfweml509-mbx.china.huawei.com> References: <03bd01ce9817$346a3b10$9d3eb130$@olddog.co.uk> <68B171751455884590F8E38E96416F363F672CBC@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C8F1@dfweml509-mbx.china.huawei.com> <85C48C97-5F2D-4159-997E-A572E996D886@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C961@dfweml509-mbx.china.huawei.com> <5F1E64BA-FA49-489B-982F-BAFF64FD9CC9@lucidvision.com> In-Reply-To: <5F1E64BA-FA49-489B-982F-BAFF64FD9CC9@lucidvision.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Thomas Narten , "adrian@olddog.co.uk" , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 03 Sep 2013 22:48:21 -0000 Here are some of the reasons that chaining of Layer 2 and 3 service functio= ns are different from chaining of Layer 4 to 7 service functions (I will ad= d more later): - Layer 4 to Layer 7 service functions (or service nodes) are to apply acti= ons to data packets traversing through. They don't impact overall network t= opologies/routes/restorations.=20 - Layer 4-7 service functions drop, pass, consume, re-initiate packets, etc= . They don't change network topologies, and they don't impact network resto= ration scheme (e.g. fast re-route). When you move a Layer 4 service module= from Location A to B, the Layer 2/3 topology is not changed, routes/restor= ation are not changed.=20 - When chaining Layer 4 to Layer 7 service functions together, like S1->S2-= >S3->S4, they are overlaying over the underlay network.=20 - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to dynamical= ly discover topology; forwarding paths; protection paths; restoration paths= , etc. Today, all routers are connected together by links. Their topology i= s more like a meshed graph than chain. So when you chain Router-1<->Router-= 2<->Router-3, are you talking about source routing? Therefore, need a clear= definition on what does it really mean by chaining Layer 2/3 service nodes= .=20 =20 Linda > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Tuesday, September 03, 2013 5:28 PM > To: Linda Dunbar > Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant (stbryant); > Thomas Narten; adrian@olddog.co.uk > Subject: Re: [nsc] NSC BoF Outcomes >=20 >=20 > On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar > wrote: >=20 > > Thomas, > > > > Are you saying that the NSC scope includes chaining Layer 2, Layer 3 > service functions, Layer 4 to Layer 7 service functions, and various > combination of them? >=20 > I don't define the scope; thats up to the ADs. >=20 > Could you please answer the question below? >=20 > --Tom >=20 > > > > Linda > > > >> -----Original Message----- > >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > >> Sent: Tuesday, September 03, 2013 5:19 PM > >> To: Linda Dunbar > >> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org; > >> Thomas Narten; Stewart Bryant (stbryant) > >> Subject: Re: [nsc] NSC BoF Outcomes > >> > >> > >> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar > >> wrote: > >> > >>> My comments are inserted below marked by [Linda]: > >>> > >>>> -----Original Message----- > >>>> > >>>>> > >>>>> However, it was less clear to me that there is agreement about > the > >>>> layer > >>>>> in > >>>>> which service chaining has to be solved. I felt that some people > >>>>> were talking about service chaining in the application layer, > some > >>>>> about service chaining based on flows, and some about per-packet > >>>>> services. The solutions are, > >>>> I > >>>>> think, > >>>>> likely to be very different for the different problems, and it > >> would > >>>> be > >>>>> wrong to > >>>>> try to bunch them all together. > >>>> > >>>> Jim> although there was certainly initial confusion I believe this > >> is > >>>> becoming less and less so as we socialize the basic idea of > service > >>>> chaining; indeed, as we move forward we will reflect a more common > >>>> understanding within the problem statement. > >>> > >>> It is still not clear which layer service functions are chained > >> together. The draft-quinn-nsc-problem-statement-03 discussed > chaining > >> of service functions that can be a network or application based > >> packet treatment,..., to enable a service offered by a network > operators. > >> > >> Why do you think that matters? > >> > >>> Today, there are many services offered by operators, e.g. L2VPN, > >>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 > >> service functions (like proxy forwarding, or fragmentation, etc.); > >> You can also interpret NSC as chaining L4 (and above) service > >> functions; or chaining of mixed L4-L7 service functions (i.e. with > >> some service nodes consuming packets and reinitiate new packets). > >> > >> You can, and people actually do implement this today. > >> > >>> Is NSC including all chaining of all those services? > >>> > >>> Layer 2/3 service function chaining might require different schemes > >> than Layer 4-7 service chaining. Therefore, it is more effective to > >> define them separately to make the discussion more focused. > >> > >> I do not think so. I'd prefer to not make this only as > complicated > >> as it needs to be, and no more. There are implementations of Layer 2 > >> and 3 chaining that are all done with the same encap/provisioning > >> systems. > >> > >> --Tom > >> > >> > >>> > >>> Linda Dunbar > >>> > >>>> > >>>> _______________________________________________ > >>>> nsc mailing list > >>>> nsc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/nsc > >>> _______________________________________________ > >>> nsc mailing 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 cpignata@cisco.com Tue Sep 3 16:28: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 D841B21E8087 for ; Tue, 3 Sep 2013 16:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.47 X-Spam-Level: X-Spam-Status: No, score=-110.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 XkvQohi-fHiI for ; Tue, 3 Sep 2013 16:28:26 -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 D804D21E8055 for ; Tue, 3 Sep 2013 16:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9418; q=dns/txt; s=iport; t=1378250906; x=1379460506; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZcvCpXkg5nVyDVglfh6xG8/0MTZv9eq/6GJ0dNNGJAA=; b=DPH+kzEFFEQrd7BNublKQCSPZ0sgZxdRYVrLkRp+GpJHGKrwt6ELfHTP MYd1geeY/S+3+srjptz5Y52RKjNAwRZRmHtMZ1xR54ntkg2Gg2d7tMXnK e1VCUf+3lOZ5YxJOFkQF7vqTt2sD7Y/GG4/Gh5WcsnZVSU8F4jCo0ThFu E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAKNvJlKtJXHA/2dsb2JhbABbgwc1wgWBKxZ0giQBAQEDAQEBAWsEBwULAgEIDgMBAwEBKAcnCxQDBggBAQQOBYd8Bgy5OASOQ4EAMweDHYEAA5Qbg1qRZoMggWk X-IronPort-AV: E=Sophos;i="4.89,1017,1367971200"; d="scan'208";a="255175245" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 03 Sep 2013 23:28:25 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r83NSOdJ022705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Sep 2013 23:28:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 18:28:23 -0500 From: "Carlos Pignataro (cpignata)" To: Jerome Moisand Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: Ac6o6J1arXOZ2m/vBEG19boxgCQmQwAM6NaA///CD1U= Date: Tue, 3 Sep 2013 23:28:23 +0000 Message-ID: <40B1DC63-C7CD-4962-B290-165ABC27F593@cisco.com> References: <57C3345230A4F94C9B2F5CFA05D7F2BD1D3B27FD@xmb-rcd-x01.cisco.com>, <94a335d4108844199675b6a673b6e1ba@BN1PR05MB251.namprd05.prod.outlook.com> In-Reply-To: <94a335d4108844199675b6a673b6e1ba@BN1PR05MB251.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Roberta Maglione \(robmgl\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 03 Sep 2013 23:28:31 -0000 Hi Jerome, Please find one comment inline.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Sep 3, 2013, at 6:10 PM, "Jerome Moisand" wrote: > Hi Roberta, >=20 > Small world=85 ;-) >=20 > Use cases: seems to me we should separate the problem statement from the = use cases, the former could be spelled out at a high level and hopefully ag= reed upon, while gathering (and beefing up) a good collection of use cases = will probably take longer. This is why I suggested a separate milestone, so= rry I wasn=92t clear. My sense is that at this point a focused approach with a small number of mi= lestones can yield faster and more productive results to the WG-to-be.=20 I completely agree with you on the usefulness of more detailed use cases --= but at the same time those seem second order that use cases high-level eno= ugh to move the core documents forward.=20 That also does not prevent start the work on separate documents with specif= ic use cases on service chaining for mobility, broadband access, etc. but a= re not needed as initial WG milestones.=20 Thanks! Carlos.=20 >=20 > BBF: yes, agreed with you about the challenges of using references and th= e need for a liaison. But given that many of us know each other from past e= xperiences, we should be able to make it less formal and more directly coll= aborative. I=92ll test the waters in this respect at the next BBF (in a cou= ple of weeks). I=92m co-editor of the BBF SIMR study document on service ch= aining, by the way, if this didn=92t cross your radar. Goal is essentially.= .. to gather (broadband-centric) use cases! >=20 > Cheers, > Jerome >=20 >=20 > From: Roberta Maglione (robmgl) [mailto:robmgl@cisco.com]=20 > Sent: Tuesday, September 03, 2013 5:00 PM > To: Jerome Moisand; Jim Guichard (jguichar); nsc@ietf.org > Subject: RE: [nsc] NSC Working Group Charter Proposal >=20 > Hello Jerome, > A couple of comments on this point: >> As to the milestones, something about documenting use cases would seem i= n order. As you probably know, both BBF SIMR >and ETSI NFV have such ongoin= g activities, > =20 > My reading of the proposed charter is that the Problem Statement is going= to include also the use cases: > =20 > 1) Problem Statement: this document will provide a summary of the problem= space to be addressed by the Network Service Chaining WG including termino= logy and sample use cases > =20 > Regarding leveraging BBF work: I fully agree with you we should not repli= cate the same work in different SDOs. However, based on my previous experie= nce in BBF, I think it may be difficult to refer in internet drafts to BBF = work in progress documents because these documents are not public until t= hey are published, so only BBF members have access to them. It could be use= ful to have a liaison from BBF to nsc WG that summarizes the uses cases alr= eady agreed in BBF. > =20 > Best Regards > Roberta > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jer= ome Moisand > Sent: Tuesday, September 03, 2013 3:50 PM > To: Jim Guichard (jguichar); nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal > =20 > Hi Jim and al. > =20 > This sounds like a nice start.=20 > =20 > From my first pass, something seems missing: there is a reference to a Se= rvice Chaining Control Plane at the very end, in the list of milestones, bu= t nothing in the text alludes to it. And this is clearly NOT the same thing= as Manageability. I do agree we need to think hard to such control plane m= atters, and this should be made more explicit in the charter. > =20 > As to the milestones, something about documenting use cases would seem in= order. As you probably know, both BBF SIMR and ETSI NFV have such ongoing = activities, albeit very new, and this should be leveraged, no point re-inve= nting the wheel. I can be used as point of contact on the BBF side, by the = way. Anyhoo, I would just suggest to add a milestone about collecting use c= ases, either directly or via other standard bodies and industry forums. > =20 > Tx > Jerome > =20 > =20 > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 > Sent: Tuesday, September 03, 2013 12:01 PM > To: nsc@ietf.org > Subject: [nsc] NSC Working Group Charter Proposal > =20 > Greetings, > =20 > As we look forward to the formation of a working group that will focus on= network service chaining, I would like to propose a discussion on this ali= as to try and reach consensus on an initial charter as requested by the rou= ting area AD's. The following is a first draft of the charter and I invite = you to actively participate and provide inputs into this process. > =20 > Proposed NSC WG Charter > =20 > Existing service insertion and deployment techniques have not evolved to = meet modern network architectures and do not reflect multi-tenancy, virtual= ization, elasticity, rich classification, and other network requirements. N= etworks, servers, storage, and applications, have all undergone significant= change in recent years: virtualization, network overlays, and orchestratio= n are increasingly the norm. All of these have profound effects on network = and services design. > =20 > Today, deploying new services, or making changes to existing services, of= ten requires network topology changes. Adding and removing service function= s is a complex, risky task, that is tied to operationalizing topological ch= anges leading to mostly-static service definitions. New service insertion a= nd deployment techniques must enable the concept of service functions as sh= ared resources, and enable the linkage of these resources using service cha= ins that represent the abstracted view of the required service functions, a= nd define the order in which they should be applied. When a service chain i= s instantiated in a network, specific instances of service functions are se= lected, and a service topology is created and used for forwarding packets t= hrough the service chain. > =20 > A basic service chain might simply utilize an existing overlay technology= to force traffic through the necessary service functions. However, additio= nal information enables a richer service chain for more advanced composite = services. For example, shared information (e.g., the result of classificati= on) can be used to offload service function processing or inform other serv= ice functions about information that would otherwise be hard to glean.=20 > =20 > The Network Service Chaining (NSC) working group focuses on new approache= s to service insertion and deployment, providing a framework for the constr= uction of services built using service chains. The WG focuses on the necess= ary protocols for the creation of service chains, and the passing of metada= ta from the network to service functions, and between service functions. Wh= en possible, the WG will extend existing protocols to provide service chain= ing functionality, and any protocol extensions will be reviewed by both the= Network Service Chaining WG and by the WG responsible for the protocol bei= ng extended. =20 > =20 > Specifically, the Network Service Chaining WG is chartered to deliver the= following work items:=20 > =20 > 1) Problem Statement: this document will provide a summary of the problem= space to be addressed by the Network Service Chaining WG including termino= logy and sample use cases. Additionally, the WG will normalize on nomencla= ture and definitions for Network Service Chaining. > =20 > 2) System Architecture: this set of documents will provide a description = of the architecture building blocks and their relationships including inter= connection, placement of capabilities, and security models, as well as requ= irements on the control mechanisms and data plane encapsulation. > =20 > 3) Service Chaining Data Plane: this document will describe on the wire d= ata plane encapsulation in support of (2). A single encapsulation will be = selected in order to enable interoperability of data plane components. > =20 > 4) Manageability: this document will address service chaining operation, = monitoring and troubleshooting including relevant service chaining models s= uch as MIBs or YANG modules, along with relevant OAM capabilities and how t= hey are realized. > =20 > Proposed Milestones: > =20 > Dec 2013 Request publication of an Informational document defining the Ne= twork Service Chaining problem statement to the IESG > =20 > Mar 2014 Request publication of informational documents defining the syst= em architecture including protocol requirements and framework to the IESG > =20 > May 2014 Request publication of a Standards Track document specifying the= data-plane (including metadata) for Service Chaining to IESG > =20 > May 2014 Request publication of an informational document specifying Serv= ice Chaining Control Plane requirements to IESG > =20 > Dec 2014 Request publication of informational documents defining Service = Chaining manageability requirements including MIBs, OAM, and information mo= dels to IESG=20 > =20 > =20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Tue Sep 3 17:45: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 3687721E80FB for ; Tue, 3 Sep 2013 17:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 DvZcQC+EXj43 for ; Tue, 3 Sep 2013 17:45:32 -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 370D121E8055 for ; Tue, 3 Sep 2013 17:45:32 -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, 3 Sep 2013 17:45:30 -0700 From: Ron Parker To: Linda Dunbar , Thomas Nadeau Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqOMRqGNOUrYckkyTmJK+S7Yz7pm1BAEAgAAGpACAAAH2gIAAAJuAgAAFo4D//6rY8A== Date: Wed, 4 Sep 2013 00:45:30 +0000 Message-ID: References: <03bd01ce9817$346a3b10$9d3eb130$@olddog.co.uk> <68B171751455884590F8E38E96416F363F672CBC@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C8F1@dfweml509-mbx.china.huawei.com> <85C48C97-5F2D-4159-997E-A572E996D886@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C961@dfweml509-mbx.china.huawei.com> <5F1E64BA-FA49-489B-982F-BAFF64FD9CC9@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C99F@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9C99F@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.76.112.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Stewart Bryant \(stbryant\)" , "adrian@olddog.co.uk" , Thomas Narten Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 00:45:39 -0000 Hi, Linda. With respect to: - Layer 4 to Layer 7 service functions (or service nodes) are to apply act= ions to data packets traversing through. They don't impact overall network = topologies/routes/restorations. Layer 4-7 services can, indeed, impact routing decisions. For example, if = the service is DPI analysis, then a detected protocol may cause the subsequ= ent packets to be policy routed on a path different than the SPF path. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda= Dunbar Sent: Tuesday, September 03, 2013 6:48 PM To: Thomas Nadeau Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; adrian@olddog.co.= uk; Stewart Bryant (stbryant) Subject: Re: [nsc] NSC BoF Outcomes Here are some of the reasons that chaining of Layer 2 and 3 service functio= ns are different from chaining of Layer 4 to 7 service functions (I will ad= d more later): - Layer 4 to Layer 7 service functions (or service nodes) are to apply acti= ons to data packets traversing through. They don't impact overall network t= opologies/routes/restorations.=20 - Layer 4-7 service functions drop, pass, consume, re-initiate packets, etc= . They don't change network topologies, and they don't impact network resto= ration scheme (e.g. fast re-route). When you move a Layer 4 service module= from Location A to B, the Layer 2/3 topology is not changed, routes/restor= ation are not changed.=20 - When chaining Layer 4 to Layer 7 service functions together, like S1->S2-= >S3->S4, they are overlaying over the underlay network.=20 - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to dynamical= ly discover topology; forwarding paths; protection paths; restoration paths= , etc. Today, all routers are connected together by links. Their topology i= s more like a meshed graph than chain. So when you chain Router-1<->Router-= 2<->Router-3, are you talking about source routing? Therefore, need a clear= definition on what does it really mean by chaining Layer 2/3 service nodes= .=20 =20 Linda > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Tuesday, September 03, 2013 5:28 PM > To: Linda Dunbar > Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant (stbryant);=20 > Thomas Narten; adrian@olddog.co.uk > Subject: Re: [nsc] NSC BoF Outcomes >=20 >=20 > On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar=20 > wrote: >=20 > > Thomas, > > > > Are you saying that the NSC scope includes chaining Layer 2, Layer 3 > service functions, Layer 4 to Layer 7 service functions, and various=20 > combination of them? >=20 > I don't define the scope; thats up to the ADs. >=20 > Could you please answer the question below? >=20 > --Tom >=20 > > > > Linda > > > >> -----Original Message----- > >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > >> Sent: Tuesday, September 03, 2013 5:19 PM > >> To: Linda Dunbar > >> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org;=20 > >> Thomas Narten; Stewart Bryant (stbryant) > >> Subject: Re: [nsc] NSC BoF Outcomes > >> > >> > >> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar=20 > >> wrote: > >> > >>> My comments are inserted below marked by [Linda]: > >>> > >>>> -----Original Message----- > >>>> > >>>>> > >>>>> However, it was less clear to me that there is agreement about > the > >>>> layer > >>>>> in > >>>>> which service chaining has to be solved. I felt that some people=20 > >>>>> were talking about service chaining in the application layer, > some > >>>>> about service chaining based on flows, and some about per-packet=20 > >>>>> services. The solutions are, > >>>> I > >>>>> think, > >>>>> likely to be very different for the different problems, and it > >> would > >>>> be > >>>>> wrong to > >>>>> try to bunch them all together. > >>>> > >>>> Jim> although there was certainly initial confusion I believe=20 > >>>> Jim> this > >> is > >>>> becoming less and less so as we socialize the basic idea of > service > >>>> chaining; indeed, as we move forward we will reflect a more=20 > >>>> common understanding within the problem statement. > >>> > >>> It is still not clear which layer service functions are chained > >> together. The draft-quinn-nsc-problem-statement-03 discussed > chaining > >> of service functions that can be a network or application based=20 > >> packet treatment,..., to enable a service offered by a network > operators. > >> > >> Why do you think that matters? > >> > >>> Today, there are many services offered by operators, e.g. L2VPN,=20 > >>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 > >> service functions (like proxy forwarding, or fragmentation, etc.);=20 > >> You can also interpret NSC as chaining L4 (and above) service=20 > >> functions; or chaining of mixed L4-L7 service functions (i.e. with=20 > >> some service nodes consuming packets and reinitiate new packets). > >> > >> You can, and people actually do implement this today. > >> > >>> Is NSC including all chaining of all those services? > >>> > >>> Layer 2/3 service function chaining might require different=20 > >>> schemes > >> than Layer 4-7 service chaining. Therefore, it is more effective to=20 > >> define them separately to make the discussion more focused. > >> > >> I do not think so. I'd prefer to not make this only as > complicated > >> as it needs to be, and no more. There are implementations of Layer=20 > >> 2 and 3 chaining that are all done with the same encap/provisioning=20 > >> systems. > >> > >> --Tom > >> > >> > >>> > >>> Linda Dunbar > >>> > >>>> > >>>> _______________________________________________ > >>>> nsc mailing list > >>>> nsc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/nsc > >>> _______________________________________________ > >>> nsc mailing list > >>> nsc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/nsc > >>> > > > > _______________________________________________ > > nsc mailing 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 jiangyuanlong@huawei.com Tue Sep 3 20:15: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 C478921E8141 for ; Tue, 3 Sep 2013 20:15:30 -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 Wj-HjA0wqrEr for ; Tue, 3 Sep 2013 20:15:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1938621E815A for ; Tue, 3 Sep 2013 20:15:24 -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.5-GA FastPath queued) with ESMTP id AVA39428; Wed, 04 Sep 2013 03:15:22 +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.146.0; Wed, 4 Sep 2013 04:15:05 +0100 Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 04:15:19 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.127]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 11:15:09 +0800 From: Jiangyuanlong To: "Carlos Pignataro (cpignata)" , Jerome Moisand Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: Ac6o6J1arXOZ2m/vBEG19boxgCQmQ///jViAgAAV4YD//0KBsA== Date: Wed, 4 Sep 2013 03:15:09 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A244B@szxema506-mbs.china.huawei.com> References: <57C3345230A4F94C9B2F5CFA05D7F2BD1D3B27FD@xmb-rcd-x01.cisco.com>, <94a335d4108844199675b6a673b6e1ba@BN1PR05MB251.namprd05.prod.outlook.com> <40B1DC63-C7CD-4962-B290-165ABC27F593@cisco.com> In-Reply-To: <40B1DC63-C7CD-4962-B290-165ABC27F593@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Roberta Maglione \(robmgl\)" , Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 03:15:31 -0000 Hi Carlos, Jerome and all, Actually I think it makes more sense to separate the problem statement from= the use cases completely, since a standalone suite of use cases is easier = to be aligned, otherwise, if high level use cases are coupled with problem = statements and published, we can hardly change it (as I am aware, no detail= ed use cases is available yet). =20 Thanks, Yuanlong -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Carlo= s Pignataro (cpignata) Sent: Wednesday, September 04, 2013 7:28 AM To: Jerome Moisand Cc: nsc@ietf.org; Jim Guichard (jguichar); Roberta Maglione (robmgl) Subject: Re: [nsc] NSC Working Group Charter Proposal Hi Jerome, Please find one comment inline.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Sep 3, 2013, at 6:10 PM, "Jerome Moisand" wrote: > Hi Roberta, >=20 > Small world... ;-) >=20 > Use cases: seems to me we should separate the problem statement from the = use cases, the former could be spelled out at a high level and hopefully ag= reed upon, while gathering (and beefing up) a good collection of use cases = will probably take longer. This is why I suggested a separate milestone, so= rry I wasn't clear. My sense is that at this point a focused approach with a small number of mi= lestones can yield faster and more productive results to the WG-to-be.=20 I completely agree with you on the usefulness of more detailed use cases --= but at the same time those seem second order that use cases high-level eno= ugh to move the core documents forward.=20 That also does not prevent start the work on separate documents with specif= ic use cases on service chaining for mobility, broadband access, etc. but a= re not needed as initial WG milestones.=20 Thanks! Carlos.=20 >=20 > BBF: yes, agreed with you about the challenges of using references and th= e need for a liaison. But given that many of us know each other from past e= xperiences, we should be able to make it less formal and more directly coll= aborative. I'll test the waters in this respect at the next BBF (in a coupl= e of weeks). I'm co-editor of the BBF SIMR study document on service chaini= ng, by the way, if this didn't cross your radar. Goal is essentially... to = gather (broadband-centric) use cases! >=20 > Cheers, > Jerome >=20 >=20 > From: Roberta Maglione (robmgl) [mailto:robmgl@cisco.com]=20 > Sent: Tuesday, September 03, 2013 5:00 PM > To: Jerome Moisand; Jim Guichard (jguichar); nsc@ietf.org > Subject: RE: [nsc] NSC Working Group Charter Proposal >=20 > Hello Jerome, > A couple of comments on this point: >> As to the milestones, something about documenting use cases would seem i= n order. As you probably know, both BBF SIMR >and ETSI NFV have such ongoin= g activities, > =20 > My reading of the proposed charter is that the Problem Statement is going= to include also the use cases: > =20 > 1) Problem Statement: this document will provide a summary of the problem= space to be addressed by the Network Service Chaining WG including termino= logy and sample use cases > =20 > Regarding leveraging BBF work: I fully agree with you we should not repli= cate the same work in different SDOs. However, based on my previous experie= nce in BBF, I think it may be difficult to refer in internet drafts to BBF = work in progress documents because these documents are not public until t= hey are published, so only BBF members have access to them. It could be use= ful to have a liaison from BBF to nsc WG that summarizes the uses cases alr= eady agreed in BBF. > =20 > Best Regards > Roberta > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jer= ome Moisand > Sent: Tuesday, September 03, 2013 3:50 PM > To: Jim Guichard (jguichar); nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal > =20 > Hi Jim and al. > =20 > This sounds like a nice start.=20 > =20 > From my first pass, something seems missing: there is a reference to a Se= rvice Chaining Control Plane at the very end, in the list of milestones, bu= t nothing in the text alludes to it. And this is clearly NOT the same thing= as Manageability. I do agree we need to think hard to such control plane m= atters, and this should be made more explicit in the charter. > =20 > As to the milestones, something about documenting use cases would seem in= order. As you probably know, both BBF SIMR and ETSI NFV have such ongoing = activities, albeit very new, and this should be leveraged, no point re-inve= nting the wheel. I can be used as point of contact on the BBF side, by the = way. Anyhoo, I would just suggest to add a milestone about collecting use c= ases, either directly or via other standard bodies and industry forums. > =20 > Tx > Jerome > =20 > =20 > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 > Sent: Tuesday, September 03, 2013 12:01 PM > To: nsc@ietf.org > Subject: [nsc] NSC Working Group Charter Proposal > =20 > Greetings, > =20 > As we look forward to the formation of a working group that will focus on= network service chaining, I would like to propose a discussion on this ali= as to try and reach consensus on an initial charter as requested by the rou= ting area AD's. The following is a first draft of the charter and I invite = you to actively participate and provide inputs into this process. > =20 > Proposed NSC WG Charter > =20 > Existing service insertion and deployment techniques have not evolved to = meet modern network architectures and do not reflect multi-tenancy, virtual= ization, elasticity, rich classification, and other network requirements. N= etworks, servers, storage, and applications, have all undergone significant= change in recent years: virtualization, network overlays, and orchestratio= n are increasingly the norm. All of these have profound effects on network = and services design. > =20 > Today, deploying new services, or making changes to existing services, of= ten requires network topology changes. Adding and removing service function= s is a complex, risky task, that is tied to operationalizing topological ch= anges leading to mostly-static service definitions. New service insertion a= nd deployment techniques must enable the concept of service functions as sh= ared resources, and enable the linkage of these resources using service cha= ins that represent the abstracted view of the required service functions, a= nd define the order in which they should be applied. When a service chain i= s instantiated in a network, specific instances of service functions are se= lected, and a service topology is created and used for forwarding packets t= hrough the service chain. > =20 > A basic service chain might simply utilize an existing overlay technology= to force traffic through the necessary service functions. However, additio= nal information enables a richer service chain for more advanced composite = services. For example, shared information (e.g., the result of classificati= on) can be used to offload service function processing or inform other serv= ice functions about information that would otherwise be hard to glean.=20 > =20 > The Network Service Chaining (NSC) working group focuses on new approache= s to service insertion and deployment, providing a framework for the constr= uction of services built using service chains. The WG focuses on the necess= ary protocols for the creation of service chains, and the passing of metada= ta from the network to service functions, and between service functions. Wh= en possible, the WG will extend existing protocols to provide service chain= ing functionality, and any protocol extensions will be reviewed by both the= Network Service Chaining WG and by the WG responsible for the protocol bei= ng extended. =20 > =20 > Specifically, the Network Service Chaining WG is chartered to deliver the= following work items:=20 > =20 > 1) Problem Statement: this document will provide a summary of the problem= space to be addressed by the Network Service Chaining WG including termino= logy and sample use cases. Additionally, the WG will normalize on nomencla= ture and definitions for Network Service Chaining. > =20 > 2) System Architecture: this set of documents will provide a description = of the architecture building blocks and their relationships including inter= connection, placement of capabilities, and security models, as well as requ= irements on the control mechanisms and data plane encapsulation. > =20 > 3) Service Chaining Data Plane: this document will describe on the wire d= ata plane encapsulation in support of (2). A single encapsulation will be = selected in order to enable interoperability of data plane components. > =20 > 4) Manageability: this document will address service chaining operation, = monitoring and troubleshooting including relevant service chaining models s= uch as MIBs or YANG modules, along with relevant OAM capabilities and how t= hey are realized. > =20 > Proposed Milestones: > =20 > Dec 2013 Request publication of an Informational document defining the Ne= twork Service Chaining problem statement to the IESG > =20 > Mar 2014 Request publication of informational documents defining the syst= em architecture including protocol requirements and framework to the IESG > =20 > May 2014 Request publication of a Standards Track document specifying the= data-plane (including metadata) for Service Chaining to IESG > =20 > May 2014 Request publication of an informational document specifying Serv= ice Chaining Control Plane requirements to IESG > =20 > Dec 2014 Request publication of informational documents defining Service = Chaining manageability requirements including MIBs, OAM, and information mo= dels to IESG=20 > =20 > =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 jiangyuanlong@huawei.com Tue Sep 3 20:27: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 A52DD21F9951 for ; Tue, 3 Sep 2013 20:27:26 -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 JKf1BjkFDU5X for ; Tue, 3 Sep 2013 20:27:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D71AB11E80D1 for ; Tue, 3 Sep 2013 20:27:21 -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.5-GA FastPath queued) with ESMTP id AVA40260; Wed, 04 Sep 2013 03:27:18 +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; Wed, 4 Sep 2013 04:26:17 +0100 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 04:26:30 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.127]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 11:26:19 +0800 From: Jiangyuanlong To: "Jim Guichard (jguichar)" , Jerome Moisand , "Roberta Maglione (robmgl)" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: Ac6o6J1arXOZ2m/vBEG19boxgCQmQ///jViAgAACbQD//ybUcA== Date: Wed, 4 Sep 2013 03:26:19 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A245B@szxema506-mbs.china.huawei.com> References: <94a335d4108844199675b6a673b6e1ba@BN1PR05MB251.namprd05.prod.outlook.com> <68B171751455884590F8E38E96416F363F67304A@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F67304A@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: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Hongyu Li \(Julio\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 03:27:26 -0000 Hi Jim, Given the complexity of the use cases as we had discussed in the mailing li= st and the reason I gave in the previous email, I think it is fair enough t= o add a bullet of "Informational document(s) defining Network Service Chain= ing use cases" as a milestone. Thanks, Yuanlong -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Wednesday, September 04, 2013 6:19 AM To: Jerome Moisand; Roberta Maglione (robmgl); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Hi Jerome, On the use cases front we only intend to have high-level examples in the problem statement. More detailed use cases, for example mobility, should be separate I-D's as you pointed out and I would fully expect to see a number of them as we move forward with this work. Not sure that we can add this as a milestone though (?) On 9/3/13 6:10 PM, "Jerome Moisand" wrote: >Hi Roberta, > >Small world=D0 ;-) > >Use cases: seems to me we should separate the problem statement from the >use cases, the former could be spelled out at a high level and hopefully >agreed upon, while gathering (and beefing up) a good collection of use >cases will probably take longer. This is why I suggested a separate >milestone, sorry I wasn=B9t clear. > >BBF: yes, agreed with you about the challenges of using references and >the need for a liaison. But given that many of us know each other from >past experiences, we should be able to make it less formal and more >directly collaborative. I=B9ll test the waters in this respect at the next >BBF (in a couple of weeks). I=B9m co-editor of the BBF SIMR study document >on service chaining, by the way, if this didn=B9t cross your radar. Goal i= s >essentially... to gather (broadband-centric) use cases! > >Cheers, >Jerome > > >From: Roberta Maglione (robmgl) [mailto:robmgl@cisco.com] >Sent: Tuesday, September 03, 2013 5:00 PM >To: Jerome Moisand; Jim Guichard (jguichar); nsc@ietf.org >Subject: RE: [nsc] NSC Working Group Charter Proposal > >Hello Jerome, >A couple of comments on this point: >>As to the milestones, something about documenting use cases would seem >>in order. As you probably know, both BBF SIMR >and ETSI NFV have such >>ongoing activities, >=20 >My reading of the proposed charter is that the Problem Statement is going >to include also the use cases: >=20 >1) Problem Statement: this document will provide a summary of the problem >space to be addressed by the Network Service Chaining WG including >terminology and sample use cases >=20 >Regarding leveraging BBF work: I fully agree with you we should not >replicate the same work in different SDOs. However, based on my previous >experience in BBF, I think it may be difficult to refer in internet >drafts to BBF work in progress documents because these documents are not >public until they are published, so only BBF members have access to >them. It could be useful to have a liaison from BBF to nsc WG that >summarizes the uses cases already agreed in BBF. >=20 >Best Regards >Roberta >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Jerome Moisand >Sent: Tuesday, September 03, 2013 3:50 PM >To: Jim Guichard (jguichar); nsc@ietf.org >Subject: Re: [nsc] NSC Working Group Charter Proposal >=20 >Hi Jim and al. >=20 >This sounds like a nice start. >=20 >From my first pass, something seems missing: there is a reference to a >Service Chaining Control Plane at the very end, in the list of >milestones, but nothing in the text alludes to it. And this is clearly >NOT the same thing as Manageability. I do agree we need to think hard to >such control plane matters, and this should be made more explicit in the >charter. >=20 >As to the milestones, something about documenting use cases would seem in >order. As you probably know, both BBF SIMR and ETSI NFV have such ongoing >activities, albeit very new, and this should be leveraged, no point >re-inventing the wheel. I can be used as point of contact on the BBF >side, by the way. Anyhoo, I would just suggest to add a milestone about >collecting use cases, either directly or via other standard bodies and >industry forums. >=20 >Tx >Jerome >=20 >=20 >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Tuesday, September 03, 2013 12:01 PM >To: nsc@ietf.org >Subject: [nsc] NSC Working Group Charter Proposal >=20 >Greetings, >=20 >As we look forward to the formation of a working group that will focus on >network service chaining, I would like to propose a discussion on this >alias to try and reach consensus on an initial charter as requested by >the routing area AD's. The following is a first draft of the charter and >I invite you to actively participate and provide inputs into this process. >=20 >Proposed NSC WG Charter >=20 >Existing service insertion and deployment techniques have not evolved to >meet modern network architectures and do not reflect multi-tenancy, >virtualization, elasticity, rich classification, and other network >requirements. Networks, servers, storage, and applications, have all >undergone significant change in recent years: virtualization, network >overlays, and orchestration are increasingly the norm. All of these have >profound effects on network and services design. >=20 >Today, deploying new services, or making changes to existing services, >often requires network topology changes. Adding and removing service >functions is a complex, risky task, that is tied to operationalizing >topological changes leading to mostly-static service definitions. New >service insertion and deployment techniques must enable the concept of >service functions as shared resources, and enable the linkage of these >resources using service chains that represent the abstracted view of the >required service functions, and define the order in which they should be >applied. When a service chain is instantiated in a network, specific >instances of service functions are selected, and a service topology is >created and used for forwarding packets through the service chain. >=20 >A basic service chain might simply utilize an existing overlay technology >to force traffic through the necessary service functions. However, >additional information enables a richer service chain for more advanced >composite services. For example, shared information (e.g., the result of >classification) can be used to offload service function processing or >inform other service functions about information that would otherwise be >hard to glean.=20 >=20 >The Network Service Chaining (NSC) working group focuses on new >approaches to service insertion and deployment, providing a framework for >the construction of services built using service chains. The WG focuses >on the necessary protocols for the creation of service chains, and the >passing of metadata from the network to service functions, and between >service functions. When possible, the WG will extend existing protocols >to provide service chaining functionality, and any protocol extensions >will be reviewed by both the Network Service Chaining WG and by the WG >responsible for the protocol being extended. >=20 >Specifically, the Network Service Chaining WG is chartered to deliver the >following work items: >=20 >1) Problem Statement: this document will provide a summary of the problem >space to be addressed by the Network Service Chaining WG including >terminology and sample use cases. Additionally, the WG will normalize on >nomenclature and definitions for Network Service Chaining. >=20 >2) System Architecture: this set of documents will provide a description >of the architecture building blocks and their relationships including >interconnection, placement of capabilities, and security models, as well >as requirements on the control mechanisms and data plane encapsulation. >=20 >3) Service Chaining Data Plane: this document will describe on the wire >data plane encapsulation in support of (2). A single encapsulation will >be selected in order to enable interoperability of data plane components. >=20 >4) Manageability: this document will address service chaining operation, >monitoring and troubleshooting including relevant service chaining models >such as MIBs or YANG modules, along with relevant OAM capabilities and >how they are realized. >=20 >Proposed Milestones: >=20 >Dec 2013 Request publication of an Informational document defining the >Network Service Chaining problem statement to the IESG >=20 >Mar 2014 Request publication of informational documents defining the >system architecture including protocol requirements and framework to the >IESG >=20 >May 2014 Request publication of a Standards Track document specifying the >data-plane (including metadata) for Service Chaining to IESG >=20 >May 2014 Request publication of an informational document specifying >Service Chaining Control Plane requirements to IESG >=20 >Dec 2014 Request publication of informational documents defining Service >Chaining manageability requirements including MIBs, OAM, and information >models to IESG=20 >=20 >=20 _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Wed Sep 4 03:51: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 5088311E819F for ; Wed, 4 Sep 2013 03:51:09 -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.300, 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 kKkc8dbgNWnb for ; Wed, 4 Sep 2013 03:51:04 -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 1EE4211E819B for ; Wed, 4 Sep 2013 03:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6835; q=dns/txt; s=iport; t=1378291864; x=1379501464; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YTDAd5onAdfDev7pShsw+SZeO4E+I0Sq4FvDQ59VBf4=; b=ZvlMAJIMZ1e3qP4jBrGjSBsjsLXIexc6i1qNx+hVY+xC8LwuQAj/ryVl KBTlG5YRosQhIkYPlhIllS5NC378gvYohIUFb0SxztQ+8RSW5G8tG41Lm Mf6JILtIN0rnaqlhA9RjpST6bBfruMMp6oaosp0L2h7/RCPn+m1NCp/2z 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADoPJ1KtJV2d/2dsb2JhbABagwc1wgSBJBZ0giQBAQEDAQEBASQTNAsFBwQCAQgRBAEBAR4JBycLFAkIAgQOBRuHYQYMuUsEj0MIKwcGgxeBAAOXdZFmgyA X-IronPort-AV: E=Sophos;i="4.89,1020,1367971200"; d="scan'208";a="255405781" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 04 Sep 2013 10:51:03 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r84Ap3H3030584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 10:51:03 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 05:51:02 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: Ac6YFyk/aYEs8EPbQVuX5dlVLbZ5nAQ1EMqAAAutBgAAANR+AAAAPryAAAATX4AAALROgAAEGq4AAAqrvDY= Date: Wed, 4 Sep 2013 10:51:02 +0000 Message-ID: References: <03bd01ce9817$346a3b10$9d3eb130$@olddog.co.uk> <68B171751455884590F8E38E96416F363F672CBC@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C8F1@dfweml509-mbx.china.huawei.com> <85C48C97-5F2D-4159-997E-A572E996D886@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C961@dfweml509-mbx.china.huawei.com> <5F1E64BA-FA49-489B-982F-BAFF64FD9CC9@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C99F@dfweml509-mbx.china.huawei.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , Thomas Nadeau , Thomas Narten , "adrian@olddog.co.uk" , Linda Dunbar , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 10:51:09 -0000 The same argument could be applied for firewalls as without them packets wo= uld get routed instead of perhaps dropped. Sent from my iPhone On Sep 3, 2013, at 8:45 PM, "Ron Parker" = wrote: > Hi, Linda. >=20 > With respect to: >=20 > - Layer 4 to Layer 7 service functions (or service nodes) are to apply= actions to data packets traversing through. They don't impact overall netw= ork topologies/routes/restorations. >=20 > Layer 4-7 services can, indeed, impact routing decisions. For example, i= f the service is DPI analysis, then a detected protocol may cause the subse= quent packets to be policy routed on a path different than the SPF path. >=20 > Ron >=20 >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Lin= da Dunbar > Sent: Tuesday, September 03, 2013 6:48 PM > To: Thomas Nadeau > Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; adrian@olddog.c= o.uk; Stewart Bryant (stbryant) > Subject: Re: [nsc] NSC BoF Outcomes >=20 > Here are some of the reasons that chaining of Layer 2 and 3 service funct= ions are different from chaining of Layer 4 to 7 service functions (I will = add more later): >=20 >=20 > - Layer 4 to Layer 7 service functions (or service nodes) are to apply ac= tions to data packets traversing through. They don't impact overall network= topologies/routes/restorations.=20 >=20 > - Layer 4-7 service functions drop, pass, consume, re-initiate packets, e= tc. They don't change network topologies, and they don't impact network res= toration scheme (e.g. fast re-route). When you move a Layer 4 service modu= le from Location A to B, the Layer 2/3 topology is not changed, routes/rest= oration are not changed.=20 >=20 > - When chaining Layer 4 to Layer 7 service functions together, like S1->S= 2->S3->S4, they are overlaying over the underlay network.=20 >=20 > - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to dynamic= ally discover topology; forwarding paths; protection paths; restoration pat= hs, etc. Today, all routers are connected together by links. Their topology= is more like a meshed graph than chain. So when you chain Router-1<->Route= r-2<->Router-3, are you talking about source routing? Therefore, need a cle= ar definition on what does it really mean by chaining Layer 2/3 service nod= es.=20 >=20 > Linda >=20 >> -----Original Message----- >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: Tuesday, September 03, 2013 5:28 PM >> To: Linda Dunbar >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant (stbryant);=20 >> Thomas Narten; adrian@olddog.co.uk >> Subject: Re: [nsc] NSC BoF Outcomes >>=20 >>=20 >> On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar=20 >> wrote: >>=20 >>> Thomas, >>>=20 >>> Are you saying that the NSC scope includes chaining Layer 2, Layer 3 >> service functions, Layer 4 to Layer 7 service functions, and various=20 >> combination of them? >>=20 >> I don't define the scope; thats up to the ADs. >>=20 >> Could you please answer the question below? >>=20 >> --Tom >>=20 >>>=20 >>> Linda >>>=20 >>>> -----Original Message----- >>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>> Sent: Tuesday, September 03, 2013 5:19 PM >>>> To: Linda Dunbar >>>> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org;=20 >>>> Thomas Narten; Stewart Bryant (stbryant) >>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>=20 >>>>=20 >>>> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar=20 >>>> wrote: >>>>=20 >>>>> My comments are inserted below marked by [Linda]: >>>>>=20 >>>>>> -----Original Message----- >>>>>>=20 >>>>>>>=20 >>>>>>> However, it was less clear to me that there is agreement about >> the >>>>>> layer >>>>>>> in >>>>>>> which service chaining has to be solved. I felt that some people=20 >>>>>>> were talking about service chaining in the application layer, >> some >>>>>>> about service chaining based on flows, and some about per-packet=20 >>>>>>> services. The solutions are, >>>>>> I >>>>>>> think, >>>>>>> likely to be very different for the different problems, and it >>>> would >>>>>> be >>>>>>> wrong to >>>>>>> try to bunch them all together. >>>>>>=20 >>>>>> Jim> although there was certainly initial confusion I believe=20 >>>>>> Jim> this >>>> is >>>>>> becoming less and less so as we socialize the basic idea of >> service >>>>>> chaining; indeed, as we move forward we will reflect a more=20 >>>>>> common understanding within the problem statement. >>>>>=20 >>>>> It is still not clear which layer service functions are chained >>>> together. The draft-quinn-nsc-problem-statement-03 discussed >> chaining >>>> of service functions that can be a network or application based=20 >>>> packet treatment,..., to enable a service offered by a network >> operators. >>>>=20 >>>> Why do you think that matters? >>>>=20 >>>>> Today, there are many services offered by operators, e.g. L2VPN,=20 >>>>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 >>>> service functions (like proxy forwarding, or fragmentation, etc.);=20 >>>> You can also interpret NSC as chaining L4 (and above) service=20 >>>> functions; or chaining of mixed L4-L7 service functions (i.e. with=20 >>>> some service nodes consuming packets and reinitiate new packets). >>>>=20 >>>> You can, and people actually do implement this today. >>>>=20 >>>>> Is NSC including all chaining of all those services? >>>>>=20 >>>>> Layer 2/3 service function chaining might require different=20 >>>>> schemes >>>> than Layer 4-7 service chaining. Therefore, it is more effective to=20 >>>> define them separately to make the discussion more focused. >>>>=20 >>>> I do not think so. I'd prefer to not make this only as >> complicated >>>> as it needs to be, and no more. There are implementations of Layer=20 >>>> 2 and 3 chaining that are all done with the same encap/provisioning=20 >>>> systems. >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>>=20 >>>>> Linda Dunbar >>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Wed Sep 4 06:04: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 9A87B21E80CB for ; Wed, 4 Sep 2013 06:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qnh4YhkYzhZp for ; Wed, 4 Sep 2013 06:04:23 -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 7E80921E80B8 for ; Wed, 4 Sep 2013 06:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13762; q=dns/txt; s=iport; t=1378299863; x=1379509463; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wE6kX/gON4SUEx111esvg+36kbgh3kmOdBUQo9WBJVc=; b=flbucj4qCAi4Gm430fH6iu7FQybscuiYkHoQ+KN8jE2Oh7A0uNrdj0d7 hpaLQwWbJEngx1N6TbgK+fSG0a78SMcMwMsh0arEvaE0NL95E/hpPKw7w H/KATX6irH5ic2cEkRQg8sfSU3lF9opa+dlTilrPt6Fp5zTjif9zFifdy Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAFYvJ1KtJV2Y/2dsb2JhbABagwc1UYMovgsXgREWdIIkAQEBBAEBASAROgQHDAYBCBEBAwEBAQICBh0DAgQlCxQBAgYIAQEEAQ0FCId6DKgSkT8EgSmNBBaBAAIWGwcGgmM0gQADlBuVQIMggWkIFyI X-IronPort-AV: E=Sophos;i="4.89,1021,1367971200"; d="scan'208";a="252451676" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 04 Sep 2013 13:04:12 +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 r84D4C1Z016271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 13:04:12 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 08:04:11 -0500 From: "Jim Guichard (jguichar)" To: Jiangyuanlong , Jerome Moisand , "Roberta Maglione (robmgl)" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: Ac6o6J1arXOZ2m/vBEG19boxgCQmQwAM6NaA//+/XACAAJj+gIAAXmSA Date: Wed, 4 Sep 2013 13:04:11 +0000 Message-ID: <68B171751455884590F8E38E96416F363F675135@xmb-rcd-x01.cisco.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A245B@szxema506-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.131.36.46] Content-Type: text/plain; charset="utf-8" Content-ID: <99D07D608CE5FB4CBDAAF12112479631@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Hongyu Li \(Julio\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 13:04:28 -0000 SGkgWXVhbmxvbmcsDQoNClllcywgSSB0aGluayB0aGVyZSBpcyBjb25zZW5zdXMgKG9yIGF0IGxl YXN0IGxhY2sgb2YgcHJvdGVzdCkgdGhhdCB3ZQ0Kc2hvdWxkIGluY2x1ZGUgc2VwYXJhdGUgSS1E J3MgdGhhdCBzcGVjaWZ5IHNwZWNpZmljIHVzZSBjYXNlcyBhbmQgYXMgSQ0Kc2FpZCBiZWZvcmUg SSBmdWxseSBleHBlY3QgdGhlc2UgdG8gYmUgcHJlc2VudGVkIHRvIHRoZSBXRyBmb3INCmNvbnNp ZGVyYXRpb24gYXMgd2UgbW92ZSBmb3J3YXJkIHdpdGggdGhpcyB3b3JrLg0KDQpPbiA5LzMvMTMg MTE6MjYgUE0sICJKaWFuZ3l1YW5sb25nIiA8amlhbmd5dWFubG9uZ0BodWF3ZWkuY29tPiB3cm90 ZToNCg0KPkhpIEppbSwNCj4NCj5HaXZlbiB0aGUgY29tcGxleGl0eSBvZiB0aGUgdXNlIGNhc2Vz IGFzIHdlIGhhZCBkaXNjdXNzZWQgaW4gdGhlIG1haWxpbmcNCj5saXN0IGFuZCB0aGUgcmVhc29u IEkgZ2F2ZSBpbiB0aGUgcHJldmlvdXMgZW1haWwsIEkgdGhpbmsgaXQgaXMgZmFpcg0KPmVub3Vn aCB0byBhZGQgYSBidWxsZXQgb2YgIkluZm9ybWF0aW9uYWwgZG9jdW1lbnQocykgZGVmaW5pbmcg TmV0d29yaw0KPlNlcnZpY2UgQ2hhaW5pbmcgdXNlIGNhc2VzIiBhcyBhIG1pbGVzdG9uZS4NCj4N Cj5UaGFua3MsDQo+WXVhbmxvbmcNCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PkZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBKaW0NCj5HdWljaGFyZCAoamd1aWNoYXIpDQo+U2VudDogV2VkbmVzZGF5 LCBTZXB0ZW1iZXIgMDQsIDIwMTMgNjoxOSBBTQ0KPlRvOiBKZXJvbWUgTW9pc2FuZDsgUm9iZXJ0 YSBNYWdsaW9uZSAocm9ibWdsKTsgbnNjQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtuc2NdIE5T QyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCj4NCj5IaSBKZXJvbWUsDQo+DQo+T24g dGhlIHVzZSBjYXNlcyBmcm9udCB3ZSBvbmx5IGludGVuZCB0byBoYXZlIGhpZ2gtbGV2ZWwgZXhh bXBsZXMgaW4gdGhlDQo+cHJvYmxlbSBzdGF0ZW1lbnQuIE1vcmUgZGV0YWlsZWQgdXNlIGNhc2Vz LCBmb3IgZXhhbXBsZSBtb2JpbGl0eSwgc2hvdWxkDQo+YmUgc2VwYXJhdGUgSS1EJ3MgYXMgeW91 IHBvaW50ZWQgb3V0IGFuZCBJIHdvdWxkIGZ1bGx5IGV4cGVjdCB0byBzZWUgYQ0KPm51bWJlciBv ZiB0aGVtIGFzIHdlIG1vdmUgZm9yd2FyZCB3aXRoIHRoaXMgd29yay4gTm90IHN1cmUgdGhhdCB3 ZSBjYW4gYWRkDQo+dGhpcyBhcyBhIG1pbGVzdG9uZSB0aG91Z2ggKD8pDQo+DQo+T24gOS8zLzEz IDY6MTAgUE0sICJKZXJvbWUgTW9pc2FuZCIgPGptb2lzYW5kQGp1bmlwZXIubmV0PiB3cm90ZToN Cj4NCj4+SGkgUm9iZXJ0YSwNCj4+DQo+PlNtYWxsIHdvcmxkxaAgOy0pDQo+Pg0KPj5Vc2UgY2Fz ZXM6IHNlZW1zIHRvIG1lIHdlIHNob3VsZCBzZXBhcmF0ZSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQg ZnJvbSB0aGUNCj4+dXNlIGNhc2VzLCB0aGUgZm9ybWVyIGNvdWxkIGJlIHNwZWxsZWQgb3V0IGF0 IGEgaGlnaCBsZXZlbCBhbmQgaG9wZWZ1bGx5DQo+PmFncmVlZCB1cG9uLCB3aGlsZSBnYXRoZXJp bmcgKGFuZCBiZWVmaW5nIHVwKSBhIGdvb2QgY29sbGVjdGlvbiBvZiB1c2UNCj4+Y2FzZXMgd2ls bCBwcm9iYWJseSB0YWtlIGxvbmdlci4gVGhpcyBpcyB3aHkgSSBzdWdnZXN0ZWQgYSBzZXBhcmF0 ZQ0KPj5taWxlc3RvbmUsIHNvcnJ5IEkgd2FzbsK5dCBjbGVhci4NCj4+DQo+PkJCRjogeWVzLCBh Z3JlZWQgd2l0aCB5b3UgYWJvdXQgdGhlIGNoYWxsZW5nZXMgb2YgdXNpbmcgcmVmZXJlbmNlcyBh bmQNCj4+dGhlIG5lZWQgZm9yIGEgbGlhaXNvbi4gQnV0IGdpdmVuIHRoYXQgbWFueSBvZiB1cyBr bm93IGVhY2ggb3RoZXIgZnJvbQ0KPj5wYXN0IGV4cGVyaWVuY2VzLCB3ZSBzaG91bGQgYmUgYWJs ZSB0byBtYWtlIGl0IGxlc3MgZm9ybWFsIGFuZCBtb3JlDQo+PmRpcmVjdGx5IGNvbGxhYm9yYXRp dmUuIEnCuWxsIHRlc3QgdGhlIHdhdGVycyBpbiB0aGlzIHJlc3BlY3QgYXQgdGhlIG5leHQNCj4+ QkJGIChpbiBhIGNvdXBsZSBvZiB3ZWVrcykuIEnCuW0gY28tZWRpdG9yIG9mIHRoZSBCQkYgU0lN UiBzdHVkeSBkb2N1bWVudA0KPj5vbiBzZXJ2aWNlIGNoYWluaW5nLCBieSB0aGUgd2F5LCBpZiB0 aGlzIGRpZG7CuXQgY3Jvc3MgeW91ciByYWRhci4gR29hbCBpcw0KPj5lc3NlbnRpYWxseS4uLiB0 byBnYXRoZXIgKGJyb2FkYmFuZC1jZW50cmljKSB1c2UgY2FzZXMhDQo+Pg0KPj5DaGVlcnMsDQo+ Pkplcm9tZQ0KPj4NCj4+DQo+PkZyb206IFJvYmVydGEgTWFnbGlvbmUgKHJvYm1nbCkgW21haWx0 bzpyb2JtZ2xAY2lzY28uY29tXQ0KPj5TZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDMsIDIwMTMg NTowMCBQTQ0KPj5UbzogSmVyb21lIE1vaXNhbmQ7IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBu c2NAaWV0Zi5vcmcNCj4+U3ViamVjdDogUkU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0 ZXIgUHJvcG9zYWwNCj4+DQo+PkhlbGxvIEplcm9tZSwNCj4+QSBjb3VwbGUgb2YgY29tbWVudHMg b24gdGhpcyBwb2ludDoNCj4+PkFzIHRvIHRoZSBtaWxlc3RvbmVzLCBzb21ldGhpbmcgYWJvdXQg ZG9jdW1lbnRpbmcgdXNlIGNhc2VzIHdvdWxkIHNlZW0NCj4+PmluIG9yZGVyLiBBcyB5b3UgcHJv YmFibHkga25vdywgYm90aCBCQkYgU0lNUiA+YW5kIEVUU0kgTkZWIGhhdmUgc3VjaA0KPj4+b25n b2luZyBhY3Rpdml0aWVzLA0KPj4gDQo+Pk15IHJlYWRpbmcgb2YgdGhlIHByb3Bvc2VkIGNoYXJ0 ZXIgaXMgdGhhdCB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQgaXMgZ29pbmcNCj4+dG8gaW5jbHVkZSBh bHNvIHRoZSB1c2UgY2FzZXM6DQo+PiANCj4+MSkgUHJvYmxlbSBTdGF0ZW1lbnQ6IHRoaXMgZG9j dW1lbnQgd2lsbCBwcm92aWRlIGEgc3VtbWFyeSBvZiB0aGUgcHJvYmxlbQ0KPj5zcGFjZSB0byBi ZSBhZGRyZXNzZWQgYnkgdGhlIE5ldHdvcmsgU2VydmljZSBDaGFpbmluZyBXRyBpbmNsdWRpbmcN Cj4+dGVybWlub2xvZ3kgYW5kIHNhbXBsZSB1c2UgY2FzZXMNCj4+IA0KPj5SZWdhcmRpbmcgbGV2 ZXJhZ2luZyBCQkYgd29yazogSSBmdWxseSBhZ3JlZSB3aXRoIHlvdSB3ZSBzaG91bGQgbm90DQo+ PnJlcGxpY2F0ZSB0aGUgc2FtZSB3b3JrIGluIGRpZmZlcmVudCBTRE9zLiBIb3dldmVyLCBiYXNl ZCBvbiBteSBwcmV2aW91cw0KPj5leHBlcmllbmNlIGluIEJCRiwgSSB0aGluayBpdCBtYXkgYmUg ZGlmZmljdWx0IHRvIHJlZmVyIGluIGludGVybmV0DQo+PmRyYWZ0cyB0byBCQkYgIHdvcmsgaW4g cHJvZ3Jlc3MgZG9jdW1lbnRzIGJlY2F1c2UgdGhlc2UgZG9jdW1lbnRzIGFyZSBub3QNCj4+cHVi bGljICB1bnRpbCB0aGV5IGFyZSBwdWJsaXNoZWQsIHNvIG9ubHkgQkJGIG1lbWJlcnMgaGF2ZSBh Y2Nlc3MgdG8NCj4+dGhlbS4gSXQgY291bGQgYmUgdXNlZnVsIHRvIGhhdmUgYSBsaWFpc29uIGZy b20gQkJGIHRvIG5zYyBXRyB0aGF0DQo+PnN1bW1hcml6ZXMgdGhlIHVzZXMgY2FzZXMgYWxyZWFk eSBhZ3JlZWQgaW4gQkJGLg0KPj4gDQo+PkJlc3QgUmVnYXJkcw0KPj5Sb2JlcnRhDQo+PkZyb206 IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZg0KPj5KZXJvbWUgTW9pc2FuZA0KPj5TZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDMs IDIwMTMgMzo1MCBQTQ0KPj5UbzogSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IG5zY0BpZXRmLm9y Zw0KPj5TdWJqZWN0OiBSZTogW25zY10gTlNDIFdvcmtpbmcgR3JvdXAgQ2hhcnRlciBQcm9wb3Nh bA0KPj4gDQo+PkhpIEppbSBhbmQgYWwuDQo+PiANCj4+VGhpcyBzb3VuZHMgbGlrZSBhIG5pY2Ug c3RhcnQuDQo+PiANCj4+RnJvbSBteSBmaXJzdCBwYXNzLCBzb21ldGhpbmcgc2VlbXMgbWlzc2lu ZzogdGhlcmUgaXMgYSByZWZlcmVuY2UgdG8gYQ0KPj5TZXJ2aWNlIENoYWluaW5nIENvbnRyb2wg UGxhbmUgYXQgdGhlIHZlcnkgZW5kLCBpbiB0aGUgbGlzdCBvZg0KPj5taWxlc3RvbmVzLCBidXQg bm90aGluZyBpbiB0aGUgdGV4dCBhbGx1ZGVzIHRvIGl0LiBBbmQgdGhpcyBpcyBjbGVhcmx5DQo+ Pk5PVCB0aGUgc2FtZSB0aGluZyBhcyBNYW5hZ2VhYmlsaXR5LiBJIGRvIGFncmVlIHdlIG5lZWQg dG8gdGhpbmsgaGFyZCB0bw0KPj5zdWNoIGNvbnRyb2wgcGxhbmUgbWF0dGVycywgYW5kIHRoaXMg c2hvdWxkIGJlIG1hZGUgbW9yZSBleHBsaWNpdCBpbiB0aGUNCj4+Y2hhcnRlci4NCj4+IA0KPj5B cyB0byB0aGUgbWlsZXN0b25lcywgc29tZXRoaW5nIGFib3V0IGRvY3VtZW50aW5nIHVzZSBjYXNl cyB3b3VsZCBzZWVtIGluDQo+Pm9yZGVyLiBBcyB5b3UgcHJvYmFibHkga25vdywgYm90aCBCQkYg U0lNUiBhbmQgRVRTSSBORlYgaGF2ZSBzdWNoIG9uZ29pbmcNCj4+YWN0aXZpdGllcywgYWxiZWl0 IHZlcnkgbmV3LCBhbmQgdGhpcyBzaG91bGQgYmUgbGV2ZXJhZ2VkLCBubyBwb2ludA0KPj5yZS1p bnZlbnRpbmcgdGhlIHdoZWVsLiBJIGNhbiBiZSB1c2VkIGFzIHBvaW50IG9mIGNvbnRhY3Qgb24g dGhlIEJCRg0KPj5zaWRlLCBieSB0aGUgd2F5LiBBbnlob28sIEkgd291bGQganVzdCBzdWdnZXN0 IHRvIGFkZCBhIG1pbGVzdG9uZSBhYm91dA0KPj5jb2xsZWN0aW5nIHVzZSBjYXNlcywgZWl0aGVy IGRpcmVjdGx5IG9yIHZpYSBvdGhlciBzdGFuZGFyZCBib2RpZXMgYW5kDQo+PmluZHVzdHJ5IGZv cnVtcy4NCj4+IA0KPj5UeA0KPj5KZXJvbWUNCj4+IA0KPj4gDQo+PkZyb206IEppbSBHdWljaGFy ZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0KPj5TZW50OiBUdWVzZGF5 LCBTZXB0ZW1iZXIgMDMsIDIwMTMgMTI6MDEgUE0NCj4+VG86IG5zY0BpZXRmLm9yZw0KPj5TdWJq ZWN0OiBbbnNjXSBOU0MgV29ya2luZyBHcm91cCBDaGFydGVyIFByb3Bvc2FsDQo+PiANCj4+R3Jl ZXRpbmdzLA0KPj4gDQo+PkFzIHdlIGxvb2sgZm9yd2FyZCB0byB0aGUgZm9ybWF0aW9uIG9mIGEg d29ya2luZyBncm91cCB0aGF0IHdpbGwgZm9jdXMgb24NCj4+bmV0d29yayBzZXJ2aWNlIGNoYWlu aW5nLCBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSBhIGRpc2N1c3Npb24gb24gdGhpcw0KPj5hbGlh cyB0byB0cnkgYW5kIHJlYWNoIGNvbnNlbnN1cyBvbiBhbiBpbml0aWFsIGNoYXJ0ZXIgYXMgcmVx dWVzdGVkIGJ5DQo+PnRoZSByb3V0aW5nIGFyZWEgQUQncy4gVGhlIGZvbGxvd2luZyBpcyBhIGZp cnN0IGRyYWZ0IG9mIHRoZSBjaGFydGVyIGFuZA0KPj5JIGludml0ZSB5b3UgdG8gYWN0aXZlbHkg cGFydGljaXBhdGUgYW5kIHByb3ZpZGUgaW5wdXRzIGludG8gdGhpcw0KPj5wcm9jZXNzLg0KPj4g DQo+PlByb3Bvc2VkIE5TQyBXRyBDaGFydGVyDQo+PiANCj4+RXhpc3Rpbmcgc2VydmljZSBpbnNl cnRpb24gYW5kIGRlcGxveW1lbnQgdGVjaG5pcXVlcyBoYXZlIG5vdCBldm9sdmVkIHRvDQo+Pm1l ZXQgbW9kZXJuIG5ldHdvcmsgYXJjaGl0ZWN0dXJlcyBhbmQgZG8gbm90IHJlZmxlY3QgbXVsdGkt dGVuYW5jeSwNCj4+dmlydHVhbGl6YXRpb24sIGVsYXN0aWNpdHksIHJpY2ggY2xhc3NpZmljYXRp b24sIGFuZCBvdGhlciBuZXR3b3JrDQo+PnJlcXVpcmVtZW50cy4gTmV0d29ya3MsIHNlcnZlcnMs IHN0b3JhZ2UsIGFuZCBhcHBsaWNhdGlvbnMsIGhhdmUgYWxsDQo+PnVuZGVyZ29uZSBzaWduaWZp Y2FudCBjaGFuZ2UgaW4gcmVjZW50IHllYXJzOiB2aXJ0dWFsaXphdGlvbiwgbmV0d29yaw0KPj5v dmVybGF5cywgYW5kIG9yY2hlc3RyYXRpb24gYXJlIGluY3JlYXNpbmdseSB0aGUgbm9ybS4gQWxs IG9mIHRoZXNlIGhhdmUNCj4+cHJvZm91bmQgZWZmZWN0cyBvbiBuZXR3b3JrIGFuZCBzZXJ2aWNl cyBkZXNpZ24uDQo+PiANCj4+VG9kYXksIGRlcGxveWluZyBuZXcgc2VydmljZXMsIG9yIG1ha2lu ZyBjaGFuZ2VzIHRvIGV4aXN0aW5nIHNlcnZpY2VzLA0KPj5vZnRlbiByZXF1aXJlcyBuZXR3b3Jr IHRvcG9sb2d5IGNoYW5nZXMuIEFkZGluZyBhbmQgcmVtb3Zpbmcgc2VydmljZQ0KPj5mdW5jdGlv bnMgaXMgYSBjb21wbGV4LCByaXNreSB0YXNrLCB0aGF0IGlzIHRpZWQgdG8gb3BlcmF0aW9uYWxp emluZw0KPj50b3BvbG9naWNhbCBjaGFuZ2VzIGxlYWRpbmcgdG8gbW9zdGx5LXN0YXRpYyBzZXJ2 aWNlIGRlZmluaXRpb25zLiBOZXcNCj4+c2VydmljZSBpbnNlcnRpb24gYW5kIGRlcGxveW1lbnQg dGVjaG5pcXVlcyBtdXN0IGVuYWJsZSB0aGUgY29uY2VwdCBvZg0KPj5zZXJ2aWNlIGZ1bmN0aW9u cyBhcyBzaGFyZWQgcmVzb3VyY2VzLCBhbmQgZW5hYmxlIHRoZSBsaW5rYWdlIG9mIHRoZXNlDQo+ PnJlc291cmNlcyB1c2luZyBzZXJ2aWNlIGNoYWlucyB0aGF0IHJlcHJlc2VudCB0aGUgYWJzdHJh Y3RlZCB2aWV3IG9mIHRoZQ0KPj5yZXF1aXJlZCBzZXJ2aWNlIGZ1bmN0aW9ucywgYW5kIGRlZmlu ZSB0aGUgb3JkZXIgaW4gd2hpY2ggdGhleSBzaG91bGQgYmUNCj4+YXBwbGllZC4gV2hlbiBhIHNl cnZpY2UgY2hhaW4gaXMgaW5zdGFudGlhdGVkIGluIGEgbmV0d29yaywgc3BlY2lmaWMNCj4+aW5z dGFuY2VzIG9mIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBzZWxlY3RlZCwgYW5kIGEgc2VydmljZSB0 b3BvbG9neSBpcw0KPj5jcmVhdGVkIGFuZCB1c2VkIGZvciBmb3J3YXJkaW5nIHBhY2tldHMgdGhy b3VnaCB0aGUgc2VydmljZSBjaGFpbi4NCj4+IA0KPj5BIGJhc2ljIHNlcnZpY2UgY2hhaW4gbWln aHQgc2ltcGx5IHV0aWxpemUgYW4gZXhpc3Rpbmcgb3ZlcmxheSB0ZWNobm9sb2d5DQo+PnRvIGZv cmNlIHRyYWZmaWMgdGhyb3VnaCB0aGUgbmVjZXNzYXJ5IHNlcnZpY2UgZnVuY3Rpb25zLiBIb3dl dmVyLA0KPj5hZGRpdGlvbmFsIGluZm9ybWF0aW9uIGVuYWJsZXMgYSByaWNoZXIgc2VydmljZSBj aGFpbiBmb3IgbW9yZSBhZHZhbmNlZA0KPj5jb21wb3NpdGUgc2VydmljZXMuIEZvciBleGFtcGxl LCBzaGFyZWQgaW5mb3JtYXRpb24gKGUuZy4sIHRoZSByZXN1bHQgb2YNCj4+Y2xhc3NpZmljYXRp b24pIGNhbiBiZSB1c2VkIHRvIG9mZmxvYWQgc2VydmljZSBmdW5jdGlvbiBwcm9jZXNzaW5nIG9y DQo+PmluZm9ybSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9ucyBhYm91dCBpbmZvcm1hdGlvbiB0aGF0 IHdvdWxkIG90aGVyd2lzZSBiZQ0KPj5oYXJkIHRvIGdsZWFuLiANCj4+IA0KPj5UaGUgTmV0d29y ayBTZXJ2aWNlIENoYWluaW5nIChOU0MpIHdvcmtpbmcgZ3JvdXAgZm9jdXNlcyBvbiBuZXcNCj4+ YXBwcm9hY2hlcyB0byBzZXJ2aWNlIGluc2VydGlvbiBhbmQgZGVwbG95bWVudCwgcHJvdmlkaW5n IGEgZnJhbWV3b3JrIGZvcg0KPj50aGUgY29uc3RydWN0aW9uIG9mIHNlcnZpY2VzIGJ1aWx0IHVz aW5nIHNlcnZpY2UgY2hhaW5zLiBUaGUgV0cgZm9jdXNlcw0KPj5vbiB0aGUgbmVjZXNzYXJ5IHBy b3RvY29scyBmb3IgdGhlIGNyZWF0aW9uIG9mIHNlcnZpY2UgY2hhaW5zLCBhbmQgdGhlDQo+PnBh c3Npbmcgb2YgbWV0YWRhdGEgZnJvbSB0aGUgbmV0d29yayB0byBzZXJ2aWNlIGZ1bmN0aW9ucywg YW5kIGJldHdlZW4NCj4+c2VydmljZSBmdW5jdGlvbnMuIFdoZW4gcG9zc2libGUsIHRoZSBXRyB3 aWxsIGV4dGVuZCBleGlzdGluZyBwcm90b2NvbHMNCj4+dG8gcHJvdmlkZSBzZXJ2aWNlIGNoYWlu aW5nIGZ1bmN0aW9uYWxpdHksIGFuZCBhbnkgcHJvdG9jb2wgZXh0ZW5zaW9ucw0KPj53aWxsIGJl IHJldmlld2VkIGJ5IGJvdGggdGhlIE5ldHdvcmsgU2VydmljZSBDaGFpbmluZyBXRyBhbmQgYnkg dGhlIFdHDQo+PnJlc3BvbnNpYmxlIGZvciB0aGUgcHJvdG9jb2wgYmVpbmcgZXh0ZW5kZWQuDQo+ PiANCj4+U3BlY2lmaWNhbGx5LCB0aGUgTmV0d29yayBTZXJ2aWNlIENoYWluaW5nIFdHIGlzIGNo YXJ0ZXJlZCB0byBkZWxpdmVyIHRoZQ0KPj5mb2xsb3dpbmcgd29yayBpdGVtczoNCj4+IA0KPj4x KSBQcm9ibGVtIFN0YXRlbWVudDogdGhpcyBkb2N1bWVudCB3aWxsIHByb3ZpZGUgYSBzdW1tYXJ5 IG9mIHRoZSBwcm9ibGVtDQo+PnNwYWNlIHRvIGJlIGFkZHJlc3NlZCBieSB0aGUgTmV0d29yayBT ZXJ2aWNlIENoYWluaW5nIFdHIGluY2x1ZGluZw0KPj50ZXJtaW5vbG9neSBhbmQgc2FtcGxlIHVz ZSBjYXNlcy4gIEFkZGl0aW9uYWxseSwgdGhlIFdHIHdpbGwgbm9ybWFsaXplIG9uDQo+Pm5vbWVu Y2xhdHVyZSBhbmQgZGVmaW5pdGlvbnMgZm9yIE5ldHdvcmsgU2VydmljZSBDaGFpbmluZy4NCj4+ IA0KPj4yKSBTeXN0ZW0gQXJjaGl0ZWN0dXJlOiB0aGlzIHNldCBvZiBkb2N1bWVudHMgd2lsbCBw cm92aWRlIGEgZGVzY3JpcHRpb24NCj4+b2YgdGhlIGFyY2hpdGVjdHVyZSBidWlsZGluZyBibG9j a3MgYW5kIHRoZWlyIHJlbGF0aW9uc2hpcHMgaW5jbHVkaW5nDQo+PmludGVyY29ubmVjdGlvbiwg cGxhY2VtZW50IG9mIGNhcGFiaWxpdGllcywgYW5kIHNlY3VyaXR5IG1vZGVscywgYXMgd2VsbA0K Pj5hcyByZXF1aXJlbWVudHMgb24gdGhlIGNvbnRyb2wgbWVjaGFuaXNtcyBhbmQgZGF0YSBwbGFu ZSBlbmNhcHN1bGF0aW9uLg0KPj4gDQo+PjMpIFNlcnZpY2UgQ2hhaW5pbmcgRGF0YSBQbGFuZTog dGhpcyBkb2N1bWVudCB3aWxsIGRlc2NyaWJlIG9uIHRoZSB3aXJlDQo+PmRhdGEgcGxhbmUgZW5j YXBzdWxhdGlvbiBpbiBzdXBwb3J0IG9mICgyKS4gIEEgc2luZ2xlIGVuY2Fwc3VsYXRpb24gd2ls bA0KPj5iZSBzZWxlY3RlZCBpbiBvcmRlciB0byBlbmFibGUgaW50ZXJvcGVyYWJpbGl0eSBvZiBk YXRhIHBsYW5lIGNvbXBvbmVudHMuDQo+PiANCj4+NCkgTWFuYWdlYWJpbGl0eTogdGhpcyBkb2N1 bWVudCB3aWxsIGFkZHJlc3Mgc2VydmljZSBjaGFpbmluZyBvcGVyYXRpb24sDQo+Pm1vbml0b3Jp bmcgYW5kIHRyb3VibGVzaG9vdGluZyBpbmNsdWRpbmcgcmVsZXZhbnQgc2VydmljZSBjaGFpbmlu ZyBtb2RlbHMNCj4+c3VjaCBhcyBNSUJzIG9yIFlBTkcgbW9kdWxlcywgYWxvbmcgd2l0aCByZWxl dmFudCBPQU0gY2FwYWJpbGl0aWVzIGFuZA0KPj5ob3cgdGhleSBhcmUgcmVhbGl6ZWQuDQo+PiAN Cj4+UHJvcG9zZWQgTWlsZXN0b25lczoNCj4+IA0KPj5EZWMgMjAxMyBSZXF1ZXN0IHB1YmxpY2F0 aW9uIG9mIGFuIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQgZGVmaW5pbmcgdGhlDQo+Pk5ldHdvcmsg U2VydmljZSBDaGFpbmluZyBwcm9ibGVtIHN0YXRlbWVudCB0byB0aGUgSUVTRw0KPj4gDQo+Pk1h ciAyMDE0IFJlcXVlc3QgcHVibGljYXRpb24gb2YgaW5mb3JtYXRpb25hbCBkb2N1bWVudHMgZGVm aW5pbmcgdGhlDQo+PnN5c3RlbSBhcmNoaXRlY3R1cmUgaW5jbHVkaW5nIHByb3RvY29sIHJlcXVp cmVtZW50cyBhbmQgZnJhbWV3b3JrIHRvIHRoZQ0KPj5JRVNHDQo+PiANCj4+TWF5IDIwMTQgUmVx dWVzdCBwdWJsaWNhdGlvbiBvZiBhIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5n IHRoZQ0KPj5kYXRhLXBsYW5lIChpbmNsdWRpbmcgbWV0YWRhdGEpIGZvciBTZXJ2aWNlIENoYWlu aW5nIHRvIElFU0cNCj4+IA0KPj5NYXkgMjAxNCBSZXF1ZXN0IHB1YmxpY2F0aW9uIG9mIGFuIGlu Zm9ybWF0aW9uYWwgZG9jdW1lbnQgc3BlY2lmeWluZw0KPj5TZXJ2aWNlIENoYWluaW5nIENvbnRy b2wgUGxhbmUgcmVxdWlyZW1lbnRzIHRvIElFU0cNCj4+IA0KPj5EZWMgMjAxNCBSZXF1ZXN0IHB1 YmxpY2F0aW9uIG9mIGluZm9ybWF0aW9uYWwgZG9jdW1lbnRzIGRlZmluaW5nIFNlcnZpY2UNCj4+ Q2hhaW5pbmcgbWFuYWdlYWJpbGl0eSByZXF1aXJlbWVudHMgaW5jbHVkaW5nIE1JQnMsIE9BTSwg YW5kIGluZm9ybWF0aW9uDQo+Pm1vZGVscyB0byBJRVNHIA0KPj4gDQo+PiANCj4NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5zYyBtYWlsaW5nIGxp c3QNCj5uc2NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25zYw0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ bnNjIG1haWxpbmcgbGlzdA0KPm5zY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbnNjDQoNCg== From jmoisand@juniper.net Wed Sep 4 06:55: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 70E5A21E80C9 for ; Wed, 4 Sep 2013 06:55:55 -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 07vZjVkZvdJ0 for ; Wed, 4 Sep 2013 06:55:49 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id AECAA21E80B8 for ; Wed, 4 Sep 2013 06:55:49 -0700 (PDT) Received: from mail5-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE003.bigfish.com (10.236.130.66) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 13:55:49 +0000 Received: from mail5-co9 (localhost [127.0.0.1]) by mail5-co9-R.bigfish.com (Postfix) with ESMTP id 0136412016F; Wed, 4 Sep 2013 13:55:49 +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: -22 X-BigFish: VPS-22(zz98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail5-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(13464003)(189002)(199002)(51704005)(377454003)(74876001)(74706001)(76482001)(53806001)(74316001)(79102001)(83072001)(15975445006)(65816001)(80022001)(76576001)(56776001)(59766001)(54316002)(81816001)(76786001)(81686001)(77982001)(76796001)(74366001)(54356001)(33646001)(56816003)(63696002)(77096001)(19580395003)(80976001)(83322001)(19580405001)(46102001)(69226001)(81342001)(81542001)(66066001)(49866001)(50986001)(47736001)(47976001)(4396001)(51856001)(31966008)(74662001)(47446002)(74502001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB249; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail5-co9 (localhost.localdomain [127.0.0.1]) by mail5-co9 (MessageSwitch) id 1378302946958585_8994; Wed, 4 Sep 2013 13:55:46 +0000 (UTC) Received: from CO9EHSMHS021.bigfish.com (unknown [10.236.132.228]) by mail5-co9.bigfish.com (Postfix) with ESMTP id E3F6118004A; Wed, 4 Sep 2013 13:55:46 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS021.bigfish.com (10.236.130.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 13:55:43 +0000 Received: from BN1PR05MB249.namprd05.prod.outlook.com (10.255.206.11) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 4 Sep 2013 13:55:43 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BN1PR05MB249.namprd05.prod.outlook.com (10.255.206.11) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 4 Sep 2013 13:55:42 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.242]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.242]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 13:55:41 +0000 From: Jerome Moisand To: "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqVy6Z9mmIGq2k0KPvTqkQ6aemJm1lc+w Date: Wed, 4 Sep 2013 13:55:40 +0000 Message-ID: References: <03bd01ce9817$346a3b10$9d3eb130$@olddog.co.uk> <68B171751455884590F8E38E96416F363F672CBC@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C8F1@dfweml509-mbx.china.huawei.com> <85C48C97-5F2D-4159-997E-A572E996D886@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C961@dfweml509-mbx.china.huawei.com> <5F1E64BA-FA49-489B-982F-BAFF64FD9CC9@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C99F@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: [66.129.232.2] x-forefront-prvs: 095972DF2F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nsc@ietf.org" , Thomas Nadeau , Linda Dunbar , "adrian@olddog.co.uk" , Thomas Narten , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 13:55:57 -0000 It seems to me that the entire point of service chaining is indeed to chain= together heterogeneous service-enabling elements, and make the best out of= such combo.=20 Service Edge routers (including Biz-PEs, BNGs and Mobile GWs) enable L3 ser= vices, on a per subscriber basis. Firewalls can act either at L3/L4 or L4/L= 7 (e.g. adding some Intrusion Detection to the mix). DPI or HTTP Proxies/Fi= lters engines act at L7. Session Border Controllers act at L7, although the= y do some L3/L4 processing too (NAT). All those various elements have their= own strengths in terms of traffic classification and in terms of policy en= forcement. Which can combined in smart ways (e.g. use DPI to identify/class= ify an application flow, use an edge router to perform fancy queuing based = on such DPI classification among other traffic flows).=20 The beauty of service chaining is to combine all those elements to make som= ething truly useful (e.g. provide a more complex Service -with a capital 'S= '- to service provider users or enterprise users). All the use cases I've h= eard so far from various parties do mix edge routers, security and applicat= ion-oriented elements. So... I would not be supportive to trying to separate a form of L2/L3 chain= ing from a form of L4/L7 chaining. On the contrary! ;-) I would actually go as far as suggesting that we should make clearer in the= proposed charter that this is a strong goal, to deal with such heterogeneo= us combos. Just my 2 cents, Jerome =3D=3D=3D=3D Totally unrelated PS for Jim: you didn't answer my question about the contr= ol plane aspects, this may have slipped through the cracks! ;-) -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Wednesday, September 04, 2013 6:51 AM To: Ron Parker Cc: nsc@ietf.org; Thomas Nadeau; Thomas Narten; adrian@olddog.co.uk; Linda = Dunbar; Stewart Bryant (stbryant) Subject: Re: [nsc] NSC BoF Outcomes The same argument could be applied for firewalls as without them packets wo= uld get routed instead of perhaps dropped. Sent from my iPhone On Sep 3, 2013, at 8:45 PM, "Ron Parker" = wrote: > Hi, Linda. >=20 > With respect to: >=20 > - Layer 4 to Layer 7 service functions (or service nodes) are to apply= actions to data packets traversing through. They don't impact overall netw= ork topologies/routes/restorations. >=20 > Layer 4-7 services can, indeed, impact routing decisions. For example, i= f the service is DPI analysis, then a detected protocol may cause the subse= quent packets to be policy routed on a path different than the SPF path. >=20 > Ron >=20 >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 > Linda Dunbar > Sent: Tuesday, September 03, 2013 6:48 PM > To: Thomas Nadeau > Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten;=20 > adrian@olddog.co.uk; Stewart Bryant (stbryant) > Subject: Re: [nsc] NSC BoF Outcomes >=20 > Here are some of the reasons that chaining of Layer 2 and 3 service funct= ions are different from chaining of Layer 4 to 7 service functions (I will = add more later): >=20 >=20 > - Layer 4 to Layer 7 service functions (or service nodes) are to apply ac= tions to data packets traversing through. They don't impact overall network= topologies/routes/restorations.=20 >=20 > - Layer 4-7 service functions drop, pass, consume, re-initiate packets, e= tc. They don't change network topologies, and they don't impact network res= toration scheme (e.g. fast re-route). When you move a Layer 4 service modu= le from Location A to B, the Layer 2/3 topology is not changed, routes/rest= oration are not changed.=20 >=20 > - When chaining Layer 4 to Layer 7 service functions together, like S1->S= 2->S3->S4, they are overlaying over the underlay network.=20 >=20 > - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to dynamic= ally discover topology; forwarding paths; protection paths; restoration pat= hs, etc. Today, all routers are connected together by links. Their topology= is more like a meshed graph than chain. So when you chain Router-1<->Route= r-2<->Router-3, are you talking about source routing? Therefore, need a cle= ar definition on what does it really mean by chaining Layer 2/3 service nod= es.=20 >=20 > Linda >=20 >> -----Original Message----- >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: Tuesday, September 03, 2013 5:28 PM >> To: Linda Dunbar >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant (stbryant);=20 >> Thomas Narten; adrian@olddog.co.uk >> Subject: Re: [nsc] NSC BoF Outcomes >>=20 >>=20 >> On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar=20 >> wrote: >>=20 >>> Thomas, >>>=20 >>> Are you saying that the NSC scope includes chaining Layer 2, Layer 3 >> service functions, Layer 4 to Layer 7 service functions, and various=20 >> combination of them? >>=20 >> I don't define the scope; thats up to the ADs. >>=20 >> Could you please answer the question below? >>=20 >> --Tom >>=20 >>>=20 >>> Linda >>>=20 >>>> -----Original Message----- >>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>> Sent: Tuesday, September 03, 2013 5:19 PM >>>> To: Linda Dunbar >>>> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org;=20 >>>> Thomas Narten; Stewart Bryant (stbryant) >>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>=20 >>>>=20 >>>> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar=20 >>>> wrote: >>>>=20 >>>>> My comments are inserted below marked by [Linda]: >>>>>=20 >>>>>> -----Original Message----- >>>>>>=20 >>>>>>>=20 >>>>>>> However, it was less clear to me that there is agreement about >> the >>>>>> layer >>>>>>> in >>>>>>> which service chaining has to be solved. I felt that some people=20 >>>>>>> were talking about service chaining in the application layer, >> some >>>>>>> about service chaining based on flows, and some about per-packet=20 >>>>>>> services. The solutions are, >>>>>> I >>>>>>> think, >>>>>>> likely to be very different for the different problems, and it >>>> would >>>>>> be >>>>>>> wrong to >>>>>>> try to bunch them all together. >>>>>>=20 >>>>>> Jim> although there was certainly initial confusion I believe=20 >>>>>> Jim> this >>>> is >>>>>> becoming less and less so as we socialize the basic idea of >> service >>>>>> chaining; indeed, as we move forward we will reflect a more=20 >>>>>> common understanding within the problem statement. >>>>>=20 >>>>> It is still not clear which layer service functions are chained >>>> together. The draft-quinn-nsc-problem-statement-03 discussed >> chaining >>>> of service functions that can be a network or application based=20 >>>> packet treatment,..., to enable a service offered by a network >> operators. >>>>=20 >>>> Why do you think that matters? >>>>=20 >>>>> Today, there are many services offered by operators, e.g. L2VPN,=20 >>>>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 >>>> service functions (like proxy forwarding, or fragmentation, etc.);=20 >>>> You can also interpret NSC as chaining L4 (and above) service=20 >>>> functions; or chaining of mixed L4-L7 service functions (i.e. with=20 >>>> some service nodes consuming packets and reinitiate new packets). >>>>=20 >>>> You can, and people actually do implement this today. >>>>=20 >>>>> Is NSC including all chaining of all those services? >>>>>=20 >>>>> Layer 2/3 service function chaining might require different=20 >>>>> schemes >>>> than Layer 4-7 service chaining. Therefore, it is more effective to=20 >>>> define them separately to make the discussion more focused. >>>>=20 >>>> I do not think so. I'd prefer to not make this only as >> complicated >>>> as it needs to be, and no more. There are implementations of Layer >>>> 2 and 3 chaining that are all done with the same encap/provisioning=20 >>>> systems. >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>>=20 >>>>> Linda Dunbar >>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From mohamed.boucadair@orange.com Wed Sep 4 07:05: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 099F711E81C4 for ; Wed, 4 Sep 2013 07:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEoMcmOzykKy for ; Wed, 4 Sep 2013 07:05:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5930911E81B5 for ; Wed, 4 Sep 2013 07:05:20 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 51AF53B4481; Wed, 4 Sep 2013 16:05:16 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 31489238085; Wed, 4 Sep 2013 16:05:16 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 4 Sep 2013 16:05:16 +0200 From: To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Date: Wed, 4 Sep 2013 16:05:14 +0200 Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1Ee0Q Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF0336604PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 14:05:40 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF0336604PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jim, Thank you for preparing the text. I fully agree that, for the sake of interoperability, one standard track so= lution must be specified by the working group. I'm fully supportive to ment= ion this in the charter and avoid that during the lifetime of the working g= roup multiple solutions are envisaged. I have some comments about the proposed deliverables and the proposed timin= g: (1) I don't think it is a good idea to split the requirements into multiple= documents. For the sake of consistency and also to have the big picture, I= suggest only one single document be chartered to record the requirements. = The requirements document should include functional requirements, manageabi= lity requirements (as per RFC5706) and security requirements. The full set = of requirements should be taken into account during the design phase. (2) The specification effort should start once the requirements are almost = stable, not before. (3) I would remove the word "metadata" from the milestones. (4) I personally don't see a value to add dedicated items for detailed use = cases. There is already an undergoing effort in other fora; no need to have= redundant effort in this space. Having an abstract description level in th= e Problem Statement is sufficient IMHO. (5) I suggest to add a "Analysis and Design Choices" document: Details rate= d to design motivations and justifications will be recorded in the analysis= document while the specification document(s) focuses exclusively on the sp= ecification part. Past experience has shown that some questions are raised = multiple times during the lifetime of the wg and it is not sometimes obviou= s to find where the decision was made and for what reason. This kind of det= ails are hard (sometime) to find: either you need to check mailing list arc= hives, or contact the authors. I see the design analysis document as a form= al tool to record the consensus on controversial design issues. The documen= t can also answer to "why not my favourite solution" solve the problem(s). (6) We don't know at this stage how many specification documents will be ne= eded. Perhaps only one Standard Track document will be required. I suggest = we leave the decision on the exact number of Standard Track documents open. To sum up: my suggestion is to go for this set of deliverables: (a) Problem Statement document (b) Framework document (terminology, functional elements, architecture, and= overall procedure) (c) Requirements document (d) Design Analysis document (e) Specification document(s) I wouldn't object if the first charter of the future WG covers only items (= a) to (d). An updated charter can be envisaged once the future WG has more = visibility on the detailed set of specification documents. Cheers, Med De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Jim G= uichard (jguichar) Envoy=E9 : mardi 3 septembre 2013 18:01 =C0 : nsc@ietf.org Objet : [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_94C682931C08B048B7A8645303FDC9F36EF0336604PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jim,=

 

I fully agree that, for th= e sake of interoperability, one standard track solution must be specified b= y the working group. I’m fully supportive to mention this in the char= ter and avoid that during the lifetime of the working group multiple soluti= ons are envisaged.

 

I have some comments about the proposed d= eliverables and the proposed timing:

(1) I don’t think it= is a good idea to split the requirements into multiple documents. For the = sake of consistency and also to have the big picture, I suggest only one si= ngle document be chartered to record the requirements. The requirements doc= ument should include functional requirements, manageability requirements (a= s per RFC5706) and security requirements. The full set of requirements shou= ld be taken into account during the design phase.

 

(2) The speci= fication effort should start once the requirements are almost stable, not b= efore.

 

=

(3) I would remove the word “metadata” from = the milestones.

 

(4) I personally don’t see a value to add= dedicated items for detailed use cases. There is already an undergoing eff= ort in other fora; no need to have redundant effort in this space. Having a= n abstract description level in the Problem Statement is sufficient IMHO.

 

(5) I suggest to add a “Analysis and Design Choices”= document: Details rated to design motivations and justifications will be r= ecorded in the analysis document while the specification document(s) focuse= s exclusively on the specification part. Past experience has shown that som= e questions are raised multiple times during the lifetime of the wg and it = is not sometimes obvious to find where the decision was made and for what r= eason. This kind of details are hard (sometime) to find: either you need to= check mailing list archives, or contact the authors. I see the design anal= ysis document as a formal tool to record the consensus on controversial des= ign issues. The document can also answer to “why not my favourite sol= ution” solve the problem(s).

 

(6) We don’t know at = this stage how many specification documents will be needed. Perhaps only on= e Standard Track document will be required. I suggest we leave the decision= on the exact number of Standard Track documents open.

 

To sum = up: my suggestion is to go for this set of deliverables:<= /p>

 

(a) Pr= oblem Statement document

(b) Framew= ork document (terminology, functional elements, architecture, and overall p= rocedure)

(c) Requireme= nts document

(d) Design A= nalysis document

(e) Spec= ification document(s)

 

I wouldn’t object if the= first charter of the future WG covers only items (a) to (d). An updated ch= arter can be envisaged once the future WG has more visibility on the detail= ed set of specification documents.

 

Cheers,

Med

 

 

De = ;: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoy=E9 : mardi 3 septembre 2013= 18:01
=C0 : nsc@ietf.org
Objet : [n= sc] NSC Working Group Charter Proposal

 

= Greetings,

&= nbsp;

As we look forwa= rd to the formation of a working group that will focus on network service c= haining, I would like to propose a discussion on this alias to try and reac= h consensus on an initial charter as requested by the routing area AD's. Th= e following is a first draft of the charter and I invite you to actively pa= rticipate and provide inputs into this process.

=

 

Proposed NSC WG Charter<= /o:p>

 

Existing service insertion = and deployment techniques have not evolved to meet modern network architect= ures and do not reflect multi-tenancy, virtualization, elasticity, rich cla= ssification, and other network requirements. Networks, servers, storage, an= d applications, have all undergone significant change in recent years: virt= ualization, network overlays, and orchestration are increasingly the norm. = All of these have profound effects on network and services design.

 <= /p>

Today, deploying new services, or m= aking changes to existing services, often requires network topology changes= . Adding and removing service functions is a complex, risky task, that is t= ied to operationalizing topological changes leading to mostly-static servic= e definitions. New service insertion and deployment techniques must enable = the concept of service functions as shared resources, and enable the linkag= e of these resources using service chains that represent the abstracted vie= w of the required service functions, and define the order in which they sho= uld be applied. When a service chain is instantiated in a network, specific= instances of service functions are selected, and a service topology is cre= ated and used for forwarding packets through the service chain.<= /span>

 

=

A basic service chain might simply uti= lize an existing overlay technology to force traffic through the necessary = service functions. However, additional information enables a richer service= chain for more advanced composite services. For example, shared informatio= n (e.g., the result of classification) can be used to offload service funct= ion processing or inform other service functions about information that wou= ld otherwise be hard to glean. 

 

The Network Service Chaining (NSC) working group focuses on new a= pproaches to service insertion and deployment, providing a framework for th= e construction of services built using service chains. The WG focuses on th= e necessary protocols for the creation of service chains, and the passing o= f metadata from the network to service functions, and between service funct= ions. When possible, the WG will extend existing protocols to provide servi= ce chaining functionality, and any protocol extensions will be reviewed by = both the Network Service Chaining WG and by the WG responsible for the prot= ocol being extended.  

 

Specifically, the Network Service Chaining WG is chartered to deliver the = following work items: 

 

1) Problem Statement: this document will provide a summary of the problem = space to be addressed by the Network Service Chaining WG including terminol= ogy and sample use cases.  Additionally, the WG will normalize on nome= nclature and definitions for Network Service Chaining.

 

2) System Architecture: this set of documents w= ill provide a description of the architecture building blocks and their rel= ationships including interconnection, placement of capabilities, and securi= ty models, as well as requirements on the control mechanisms and data plane= encapsulation.

<= o:p> 

3) Service = Chaining Data Plane: this document will describe on the wire data plane enc= apsulation in support of (2).  A single encapsulation will be selected= in order to enable interoperability of data plane components.

 

<= /div>

4) Manageability: this document will ad= dress service chaining operation, monitoring and troubleshooting including = relevant service chaining models such as MIBs or YANG modules, along with r= elevant OAM capabilities and how they are realized.

 

<= p class=3DMsoNormal>Proposed Milestones:

 

Dec 2013 Request publication of an Informational documen= t defining the Network Service Chaining problem statement to the IESG<= /o:p>

 

Mar 2014 Request publication of = informational documents defining the system architecture including protocol= requirements and framework to the IESG

 

May 2014 Request publication of a Standards Track document spe= cifying the data-plane (including metadata) for Service Chaining to IESG

 

May 2014 Request publication = of an informational document specifying Service Chaining Control Plane requ= irements to IESG

=  

Dec 2014 R= equest publication of informational documents defining Service Chaining man= ageability requirements including MIBs, OAM, and information models to IESG=  

 = ;

 

= --_000_94C682931C08B048B7A8645303FDC9F36EF0336604PUEXCB1Bnante_-- From jguichar@cisco.com Wed Sep 4 07:17: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 136AC21F970E for ; Wed, 4 Sep 2013 07:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 P-NW0IUrD4uy for ; Wed, 4 Sep 2013 07:17:27 -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 EDB9721F93D4 for ; Wed, 4 Sep 2013 07:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9769; q=dns/txt; s=iport; t=1378304247; x=1379513847; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GciMVSjPvih46CMzsMG9NJC4/0ZSoTqCxwCaGUnuMGA=; b=WaFGMLQUEcV3VFpioZdJ8J3cnXZSxUpO4Q3lwx4fg1zXxQJLJEujWf8S 5+lqz4rSUIEKWu2yMFKxjy5QYcZWogYVdS8nSSNO0qajjVANbk4sYWVIx N7mBDqr1cBCL2KMo9wpXePqjZRMjeu2rcz4yFF6PyPj+ZtUYk6iNa3SH7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADZAJ1KtJV2b/2dsb2JhbABQCoMHNVHBNYElFnSCJAEBAQQBAQEkRwsMBgEIDgMEAQEBCh0uCxQJCAIEAQ0FCBOHZwy5ZQSOM4ESBisHBoMXgQADqVuDIIIq X-IronPort-AV: E=Sophos;i="4.89,1021,1367971200"; d="scan'208";a="255290369" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 04 Sep 2013 14:17:26 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r84EHQCi031370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 14:17:26 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 09:17:26 -0500 From: "Jim Guichard (jguichar)" To: Jerome Moisand , Ron Parker Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: Ac6YFyk/aYEs8EPbQVuX5dlVLbZ5nAQ1EMqAAAutBgAAANR+AAAAPryAAAATX4AAALROgAAEGq4AAAqrvDYAEOzoAP//wwOA Date: Wed, 4 Sep 2013 14:17:25 +0000 Message-ID: <68B171751455884590F8E38E96416F363F675278@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.46] Content-Type: text/plain; charset="Windows-1252" Content-ID: <468EA8445A1BAA40ABE03ED01DCECF62@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , Thomas Nadeau , Linda Dunbar , "adrian@olddog.co.uk" , Thomas Narten , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 14:17:32 -0000 Hi Jerome, My bad .. Responding to your PS ;) =8A Right now the charter suggests that the WG be responsible for defining the requirements of the control plane with respect to service chaining. The problem here is of course that there are multiple control planes. In my mind it makes little sense to try and tackle them all but rather define what is necessary for a control plane to implement to successfully enable service chains and then liaise with other WG's on the details. Some further comments inline. On 9/4/13 9:55 AM, "Jerome Moisand" wrote: >It seems to me that the entire point of service chaining is indeed to >chain together heterogeneous service-enabling elements, and make the best >out of such combo. Jim> exactly. The point being separate service functions into a resource pool that can be utilized and not constrained based on topology. >=20 > >Service Edge routers (including Biz-PEs, BNGs and Mobile GWs) enable L3 >services, on a per subscriber basis. Firewalls can act either at L3/L4 or >L4/L7 (e.g. adding some Intrusion Detection to the mix). DPI or HTTP >Proxies/Filters engines act at L7. Session Border Controllers act at L7, >although they do some L3/L4 processing too (NAT). All those various >elements have their own strengths in terms of traffic classification and >in terms of policy enforcement. Which can combined in smart ways (e.g. >use DPI to identify/classify an application flow, use an edge router to >perform fancy queuing based on such DPI classification among other >traffic flows). Jim> yep.=20 >=20 > >The beauty of service chaining is to combine all those elements to make >something truly useful (e.g. provide a more complex Service -with a >capital 'S'- to service provider users or enterprise users). All the use >cases I've heard so far from various parties do mix edge routers, >security and application-oriented elements. > >So... I would not be supportive to trying to separate a form of L2/L3 >chaining from a form of L4/L7 chaining. On the contrary! ;-) > >I would actually go as far as suggesting that we should make clearer in >the proposed charter that this is a strong goal, to deal with such >heterogeneous combos. Jim> any text and suggestion of where to insert into the charter? > >Just my 2 cents, >Jerome > >=3D=3D=3D=3D >Totally unrelated PS for Jim: you didn't answer my question about the >control plane aspects, this may have slipped through the cracks! ;-) > >-----Original Message----- >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Wednesday, September 04, 2013 6:51 AM >To: Ron Parker >Cc: nsc@ietf.org; Thomas Nadeau; Thomas Narten; adrian@olddog.co.uk; >Linda Dunbar; Stewart Bryant (stbryant) >Subject: Re: [nsc] NSC BoF Outcomes > >The same argument could be applied for firewalls as without them packets >would get routed instead of perhaps dropped. > >Sent from my iPhone > >On Sep 3, 2013, at 8:45 PM, "Ron Parker" > wrote: > >> Hi, Linda. >>=20 >> With respect to: >>=20 >> - Layer 4 to Layer 7 service functions (or service nodes) are to >>apply actions to data packets traversing through. They don't impact >>overall network topologies/routes/restorations. >>=20 >> Layer 4-7 services can, indeed, impact routing decisions. For example, >>if the service is DPI analysis, then a detected protocol may cause the >>subsequent packets to be policy routed on a path different than the SPF >>path. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Linda Dunbar >> Sent: Tuesday, September 03, 2013 6:48 PM >> To: Thomas Nadeau >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; >> adrian@olddog.co.uk; Stewart Bryant (stbryant) >> Subject: Re: [nsc] NSC BoF Outcomes >>=20 >> Here are some of the reasons that chaining of Layer 2 and 3 service >>functions are different from chaining of Layer 4 to 7 service functions >>(I will add more later): >>=20 >>=20 >> - Layer 4 to Layer 7 service functions (or service nodes) are to apply >>actions to data packets traversing through. They don't impact overall >>network topologies/routes/restorations. >>=20 >> - Layer 4-7 service functions drop, pass, consume, re-initiate packets, >>etc. They don't change network topologies, and they don't impact network >>restoration scheme (e.g. fast re-route). When you move a Layer 4 >>service module from Location A to B, the Layer 2/3 topology is not >>changed, routes/restoration are not changed. >>=20 >> - When chaining Layer 4 to Layer 7 service functions together, like >>S1->S2->S3->S4, they are overlaying over the underlay network. >>=20 >> - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to >>dynamically discover topology; forwarding paths; protection paths; >>restoration paths, etc. Today, all routers are connected together by >>links. Their topology is more like a meshed graph than chain. So when >>you chain Router-1<->Router-2<->Router-3, are you talking about source >>routing? Therefore, need a clear definition on what does it really mean >>by chaining Layer 2/3 service nodes. >>=20 >> Linda >>=20 >>> -----Original Message----- >>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>> Sent: Tuesday, September 03, 2013 5:28 PM >>> To: Linda Dunbar >>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant (stbryant); >>> Thomas Narten; adrian@olddog.co.uk >>> Subject: Re: [nsc] NSC BoF Outcomes >>>=20 >>>=20 >>> On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar >>> wrote: >>>=20 >>>> Thomas, >>>>=20 >>>> Are you saying that the NSC scope includes chaining Layer 2, Layer 3 >>> service functions, Layer 4 to Layer 7 service functions, and various >>> combination of them? >>>=20 >>> I don't define the scope; thats up to the ADs. >>>=20 >>> Could you please answer the question below? >>>=20 >>> --Tom >>>=20 >>>>=20 >>>> Linda >>>>=20 >>>>> -----Original Message----- >>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>> Sent: Tuesday, September 03, 2013 5:19 PM >>>>> To: Linda Dunbar >>>>> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org; >>>>> Thomas Narten; Stewart Bryant (stbryant) >>>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>>=20 >>>>>=20 >>>>> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar >>>>> wrote: >>>>>=20 >>>>>> My comments are inserted below marked by [Linda]: >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>>=20 >>>>>>>>=20 >>>>>>>> However, it was less clear to me that there is agreement about >>> the >>>>>>> layer >>>>>>>> in >>>>>>>> which service chaining has to be solved. I felt that some people >>>>>>>> were talking about service chaining in the application layer, >>> some >>>>>>>> about service chaining based on flows, and some about per-packet >>>>>>>> services. The solutions are, >>>>>>> I >>>>>>>> think, >>>>>>>> likely to be very different for the different problems, and it >>>>> would >>>>>>> be >>>>>>>> wrong to >>>>>>>> try to bunch them all together. >>>>>>>=20 >>>>>>> Jim> although there was certainly initial confusion I believe >>>>>>> Jim> this >>>>> is >>>>>>> becoming less and less so as we socialize the basic idea of >>> service >>>>>>> chaining; indeed, as we move forward we will reflect a more >>>>>>> common understanding within the problem statement. >>>>>>=20 >>>>>> It is still not clear which layer service functions are chained >>>>> together. The draft-quinn-nsc-problem-statement-03 discussed >>> chaining >>>>> of service functions that can be a network or application based >>>>> packet treatment,..., to enable a service offered by a network >>> operators. >>>>>=20 >>>>> Why do you think that matters? >>>>>=20 >>>>>> Today, there are many services offered by operators, e.g. L2VPN, >>>>>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 >>>>> service functions (like proxy forwarding, or fragmentation, etc.); >>>>> You can also interpret NSC as chaining L4 (and above) service >>>>> functions; or chaining of mixed L4-L7 service functions (i.e. with >>>>> some service nodes consuming packets and reinitiate new packets). >>>>>=20 >>>>> You can, and people actually do implement this today. >>>>>=20 >>>>>> Is NSC including all chaining of all those services? >>>>>>=20 >>>>>> Layer 2/3 service function chaining might require different >>>>>> schemes >>>>> than Layer 4-7 service chaining. Therefore, it is more effective to >>>>> define them separately to make the discussion more focused. >>>>>=20 >>>>> I do not think so. I'd prefer to not make this only as >>> complicated >>>>> as it needs to be, and no more. There are implementations of Layer >>>>> 2 and 3 chaining that are all done with the same encap/provisioning >>>>> systems. >>>>>=20 >>>>> --Tom >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Linda Dunbar >>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > > From kgray@juniper.net Wed Sep 4 07:54: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 B661F21E80DA for ; Wed, 4 Sep 2013 07:54:22 -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 cLhZfIv8i3z5 for ; Wed, 4 Sep 2013 07:54:14 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 00B7221E80C2 for ; Wed, 4 Sep 2013 07:54:03 -0700 (PDT) Received: from mail62-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE002.bigfish.com (10.236.130.65) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 14:53:59 +0000 Received: from mail62-co9 (localhost [127.0.0.1]) by mail62-co9-R.bigfish.com (Postfix) with ESMTP id 85C46A0091; Wed, 4 Sep 2013 14:53:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -74 X-BigFish: VPS-74(zzbb2dI98dI9371Ic89bh936eI1454I148cI1432I1418I15caKJa706lzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail62-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=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(55784002)(52044002)(51444003)(52604005)(51704005)(479174003)(377454003)(199002)(189002)(377424004)(83072001)(80976001)(36756003)(76796001)(76786001)(63696002)(81542001)(74662001)(47446002)(74502001)(31966008)(15202345003)(74706001)(83506001)(79102001)(81816001)(81686001)(74876001)(74366001)(54356001)(56776001)(53806001)(76176001)(59766001)(77982001)(56816003)(77096001)(76482001)(54316002)(15975445006)(19580395003)(46102001)(51856001)(83322001)(19580405001)(80022001)(47736001)(65816001)(4396001)(69226001)(47976001)(81342001)(50986001)(49866001)(427584002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB082; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail62-co9 (localhost.localdomain [127.0.0.1]) by mail62-co9 (MessageSwitch) id 137830637716389_13086; Wed, 4 Sep 2013 14:52:57 +0000 (UTC) Received: from CO9EHSMHS004.bigfish.com (unknown [10.236.132.246]) by mail62-co9.bigfish.com (Postfix) with ESMTP id E5C53B00096; Wed, 4 Sep 2013 14:52:49 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS004.bigfish.com (10.236.130.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 14:52:48 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 4 Sep 2013 14:52:46 +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.745.25; Wed, 4 Sep 2013 14:52:45 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 14:52:45 +0000 From: Ken Gray To: "mohamed.boucadair@orange.com" , "nsc@ietf.org" Thread-Topic: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt Thread-Index: Ac6fMhIAzIOqddliRk+cqJ/CnVKw9ADv8zVgAZrASQA= Date: Wed, 4 Sep 2013 14:52:44 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEEE4EC9B@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 095972DF2F Content-Type: text/plain; charset="iso-8859-1" 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% Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.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, 04 Sep 2013 14:54:24 -0000 Heya, Med. I gave it a quick read. I have the following questions/observations: REQ#2 - The document doesn't specifically say whether we're constraining our focus on chains that require an "externality" for each link (that is, ARE we assuming that each "link" will pass through a network/networked element e.g. Hypervisor switch) - and are thus excluding from discussion IPC (or RPC) mechanisms between service elements on the same device (which are much harder to detect, monitor, standardize). REQ#13 is putting a constraint on the header discussion. Is this the right place to put that, particularly since the requirements there haven't been fully defined (yet)? REQ#15 - while I fully appreciate your desire to avoid another 80+ part email thread on whether MPLS is an overlay, I think you make your point well enough in the main assertion and part "b" is actually redundant. 8^) REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22 has to be a MUST (I think the need for downstream reclassification can be a normal outcome of the function of an individual service element as it potentially transforms a header - unless your argument is that we should avoid this wherever possible by imbedding a clue in the header - in which case we run into issues with "non-speakers" or legacy devices). REQ#23 seems to obviate the use of simple route NH manipulation to create a chain (this is destination address based). So, to be inclusive, I think that has to be a SHOULD. REQ#25 seems to be difficult to require if you don't dictate how the chain is formed (how the forwarding is instantiated) and should be worded more like REQ#29, IMO. REQ#30 I think you're trying to say that static definition/topology of service functions SHOULD be supported but dynamic MUST (not that every element has to support dynamic discovery but that the overall goal of the ongoing architecture should be dynamic with static augmentation for corner/legacy cases) ...which would be more in alignment with the tenor of REQ#32. Thanks for kicking it off and reading this drivel ... On 8/27/13 2:58 AM, "mohamed.boucadair@orange.com" wrote: >Dear all, > >A new version of the requirements draft is now available online. The main >changes in this new version are as follows: > >* Enrich the document with inputs from >draft-li-service-chaining-requirements >* Welcome authors of draft-li-service-chaining-requirements as co-authors >* Add new security-related requirements. >* Re-order the requirements > >A more detailed diff is available at: >http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirements= -0 >1.txt=20 > >Feel free to share your comments, suggestions and text contributions on >the list or direct them to the authors. > >Cheers, >Med > >-----Message d'origine----- >De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >De la part de internet-drafts@ietf.org >Envoy=E9 : jeudi 22 ao=FBt 2013 14:21 >=C0 : i-d-announce@ietf.org >Objet : I-D Action: draft-boucadair-chaining-requirements-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Requirements for Service Function Chaining > Author(s) : Mohamed Boucadair > Christian Jacquenet > Yuanlong Jiang > Hongyu Li > Ron Parker > Filename : draft-boucadair-chaining-requirements-01.txt > Pages : 10 > Date : 2013-08-22 > >Abstract: > This document identifies the requirements for the Service Function > Chaining. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirements > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-boucadair-chaining-requirements-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirements-0= 1 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > From christian.jacquenet@orange.com Wed Sep 4 08:00: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 19EE621E80DE for ; Wed, 4 Sep 2013 08:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7razupTuTYPw for ; Wed, 4 Sep 2013 08:00:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id DD7B221E80CD for ; Wed, 4 Sep 2013 08:00:27 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id C819C374DE7; Wed, 4 Sep 2013 17:00:21 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id A6EA915811C; Wed, 4 Sep 2013 17:00:21 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 4 Sep 2013 17:00:21 +0200 From: To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Date: Wed, 4 Sep 2013 17:00:20 +0200 Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1pL9g Message-ID: <25062_1378306821_52274B05_25062_3214_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64714@PUEXCB1C.nanterre.francetelecom.fr> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64714PUEXCB1Cnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.4.141521 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 15:00:39 -0000 --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64714PUEXCB1Cnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, Thanks to Jim for this proposal. A few comments from my side inline, in add= ition to those that were recently submitted by Med (and which I agree with). [snip] Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. [CJ] I would smooth the first statement a bit (mostly because it depends on= the nature and the number of the functions involved, as well as the networ= king environment). Something like: "...deployment techniques fail to addres= s new challenging requirements raised by the introduction of emerging techn= iques such as multi-tenancy, virtualization, etc." I would suppress the "mo= dern network architectures" quotation of the sentence. Networks, servers,[CJ] and other storage[CJ] technologies, [CJ] let alone= applications, have all undergone significant change in recent years: virtu= alization, network overlays, and orchestration [CJ] have increasingly becom= e techniques that count and sometimes prevail. All of these have profound e= ffects on network and services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. [CJ] maybe "...leading to massively static configuration procedures for net= work service delivery or update purposes." New service insertion and deployment techniques [CJ] Maybe "The structuring and the delivery of new network services assume= the (smart) combination of various service functions as shared resources, = and enable..." must enable the concept of service functions as shared resources, and enabl= e the linkage of these resources using service chains that represent the ab= stracted view of the required service functions, and define the order in wh= ich they should be invoked. When a service chain is instantiated in a netwo= rk, specific instances of service functions are selected, and a service top= ology is created and used for forwarding packets [CJ] according to the serv= ice chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. [CJ] I don't understand the previous sentence, including the kind of causal= ity effect between classification outcomes and shared information. Did you = mean: "For example, the combined and ordered activation of a set of service= functions possibly located in different regions of the network (or differe= nt network elements) is an information that will be distributed to the netw= ork elements for the sake of optimized service function and resource usage.= "? The Network Service Chaining (NSC) working group focuses on new approaches = to[CJ] network service [CJ] structuring and deployment, providing a framew= ork for the construction of services [CJ] based upon the construction of se= rvice [CJ] function chains. The WG focuses on the necessary protocols for t= he creation of service chains, and the [CJ] transmission of service-specifi= c information from the network to service functions, and between service fu= nctions. When possible, the WG will extend existing protocols to provide se= rvice chaining functionality, and any protocol extensions will be reviewed = by both the Network Service Chaining WG and by the WG responsible for the p= rotocol being extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the pro= blem space to be addressed by the Network Service Chaining WG including ter= minology and sample use cases. Additionally, the WG will normalize on nome= nclature and definitions for Network Service Chaining. CJ: as already mentioned by Med, I don't think the terminology effort shoul= d be part of the PS document, but rather the framework document. 2) System Architecture: this set of documents will provide a descript= ion of the architecture building blocks and their relationships including i= nterconnection, placement of capabilities, and security models, as well as = requirements on the control mechanisms and data plane encapsulation. CJ: requirements should be described in a specific document. 3) Service Chaining Data Plane: this document will describe on the wi= re data plane encapsulation in support of (2). A single encapsulation will= be selected in order to enable interoperability of data plane components. CJ: this wording is too specific and somewhat speculative (because it impli= citly assumes some kind of encapsulation is needed anyway). I would relax t= he objective a bit, and derive the specification effort according to the co= ntents of the Framework document that basically corresponds to Point #2 abo= ve. Likewise, I share Jerome's comment (hello J=E9r=F4me :)) about the cont= rol plane. This should be explicitly investigated as part of the Framework = document, and derive the possible specification effort accordingly (for exa= mple, dynamic SF discovery capabilities may involve control plane features). 4) Manageability: this document will address service chaining operati= on, monitoring and troubleshooting including relevant service chaining mode= ls such as MIBs or YANG modules, along with relevant OAM capabilities and h= ow they are realized. CJ: corresponding manageability considerations should be documented first i= n the Framework. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG [CJ] Clearly distinguish between a Requirements document and a Framework do= cument, which should not be available at the same time presumably (I would = target June 2014 for the Framework document). May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG [CJ] Not sure I understand the difference in nature between the data plane = and the control plane documents (standard vs. informational). Also, I think= a gap analysis effort needs to be conducted and documented prior to any co= nsideration about publishing that kind of specification (as also suggested = by Med). This gap analysis document should be available some time in March/= April, presumably. Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG [CJ] You should delete "requirements" from the above sentence. Not sure I w= ould be that specific at this stage (e.g., the YANG modules mentioned earli= er have disappeared from the list above) and maybe stick to the PS/Requirem= ents/Gap analysis/Framework list of WG deliverables for the time being. Cheers, Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64714PUEXCB1Cnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Thanks to Jim for this proposal. A few comments from my side inline, in= addition to those that were recently submitted by Med (and which I agree w= ith).

[snip]

Proposed NSC WG Charter

 

Existing service insertion and depl= oyment techniques have not evolved to meet modern network architectures and= do not reflect multi-tenancy, virtualization, elasticity, rich classificat= ion, and other network requirements.

[CJ] I would smooth the first statement a bit (mostly becau= se it depends on the nature and the number of the functions involved, as we= ll as the networking environment). Something like: “…deployment= techniques fail to address new challenging requirements raised by the intr= oduction of emerging techniques such as multi-tenancy, virtualization, etc.= ” I would suppress the “modern network architectures” quo= tation of the sentence.

Networks, servers,[CJ]  and other storage[CJ]=  technologies, = [CJ] let alone applications, have all und= ergone significant change in recent years: virtualization, network overlays= , and orchestration [CJ] have increasingly become techniques that count and someti= mes prevail. All of these have profound effects on network and = services design.

 

Today, deploying new servic= es, or making changes to existing services, often requires network topology= changes. Adding and removing service functions is a complex, risky task, t= hat is tied to operationalizing topological changes leading to mostly-stati= c service definitions.

New service = insertion and deployment techniques

[CJ] Maybe “The structuring and the delivery of new ne= twork services assume the (smart) combination of various service functions = as shared resources, and enable…”

must enable the concept of = service functions as shared resources, and enable the linkage of these reso= urces using service chains that represent the abstracted view of the requir= ed service functions, and define the order in which they should be <= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:#5F= 497A'>invoked. When a service chain is instantiated in a networ= k, specific instances of service functions are selected, and a service topo= logy is created and used for forwarding packets [CJ] according to the service chain.<= /span>

 

A basic service chain might simply utilize an existing = overlay technology to force traffic through the necessary service functions= . However, additional information enables a richer service chain for more a= dvanced composite services. For example, shared information (e.g., the resu= lt of classification) can be used to offload service function processing or= inform other service functions about information that would otherwise be h= ard to glean. 

[CJ] I don= 217;t understand the previous sentence, including the kind of causality eff= ect between classification outcomes and shared information. Did you mean: &= #8220;For example, the combined and ordered activation of a set of service = functions possibly located in different regions of the network (or differen= t network elements) is an information that will be distributed to the netwo= rk elements for the sake of optimized service function and resource usage.&= #8221;?

 

The Network Service Chaining (NSC) w= orking group focuses on new approaches to[CJ]  network service [CJ] structuring and deployment, providing a fram= ework for the construction of services [CJ] = based upon the construction of service = [CJ] function chains. The WG focus= es on the necessary protocols for the creation of service chains, and the <= /span>[CJ] transmission of service-speci= fic information from the network to service functions, and betw= een service functions. When possible, the WG will extend existing protocols= to provide service chaining functionality, and any protocol extensions wil= l be reviewed by both the Network Service Chaining WG and by the WG respons= ible for the protocol being extended.  

 <= /span>

Specifically, the Network Service Chaining WG is chartered to deliver the = following work items: 

 

<= div>

1)  &nb= sp;    Problem Statement= : this document will provide a summary of the problem space to be addressed= by the Network Service Chaining WG including terminology and sample use ca= ses.  Additionally, the WG will normalize on nomenclature and definiti= ons for Network Service Chaining.

CJ: as already mentioned by Med= , I don’t think the terminology effort should be part of the PS docum= ent, but rather the framework document.

 

2)&n= bsp;      Syst= em Architecture: this set of documents will provide a description of the ar= chitecture building blocks and their relationships including interconnectio= n, placement of capabilities, and security models, as well as requirements = on the control mechanisms and data plane encapsulation.

CJ: requi= rements should be described in a specific document.

 =

= 3)       Service Chaining Data Plane: this document will describe on the wire= data plane encapsulation in support of (2).  A single encapsulation w= ill be selected in order to enable interoperability of data plane component= s.

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:#5F= 497A'>CJ: this wording is too specific and somewhat speculative (because it= implicitly assumes some kind of encapsulation is needed anyway). I would r= elax the objective a bit, and derive the specification effort according to = the contents of the Framework document that basically corresponds to Point = #2 above. Likewise, I share Jerome’s comment (hello Jérô= me J) about the control plane. This should be explicitly inv= estigated as part of the Framework document, and derive the possible specif= ication effort accordingly (for example, dynamic SF discovery capabilities = may involve control plane features).

 

4) =       Manage= ability: this document will address service chaining operation, monitoring = and troubleshooting including relevant service chaining models such as MIBs= or YANG modules, along with relevant OAM capabilities and how they are rea= lized.

CJ: corresponding manageability considerations should be document= ed first in the Framework.

 

Proposed Mileston= es:

 

Dec 2013 Request publication of an Infor= mational document defining the Network Service Chaining problem statement t= o the IESG

 

Mar 2014 Request publication of i= nformational documents defining the system architecture including protocol = requirements and framework to the IESG

[CJ] Clearly distinguish between a Requirements document and a Framewor= k document, which should not be available at the same time presumably (I wo= uld target June 2014 for the Framework document).

 

May 2014 Request publication of a Standards Track document specifying= the data-plane (including metadata) for Service Chaining to IESG

 

May 2014 Request publication of an informational docu= ment specifying Service Chaining Control Plane requirements to IESG

[CJ] Not sure I understand the difference = in nature between the data plane and the control plane documents (standard = vs. informational). Also, I think a gap analysis effort needs to be conduct= ed and documented prior to any consideration about publishing that kind of = specification (as also suggested by Med). This gap analysis document should= be available some time in March/April, presumably.

 =

Dec 2014 Request publication of informational documents defining Se= rvice Chaining manageability requirements including MIBs, OAM, and informat= ion models to IESG

= [C= J] You should delete “requirements” from the above sentence. No= t sure I would be that specific at this stage (e.g., the YANG modules menti= oned earlier have disappeared from the list above) and maybe stick to the P= S/Requirements/Gap analysis/Framework list of WG deliverables for the time = being.

 

=

Cheers,

&nb= sp;

Christian.

 =

=  

 

__________=
___________________________________________________________________________=
____________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64714PUEXCB1Cnante_-- From Ron_Parker@affirmednetworks.com Wed Sep 4 08:39: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 A963721F9196 for ; Wed, 4 Sep 2013 08:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 sNciC+9Ru099 for ; Wed, 4 Sep 2013 08:39:32 -0700 (PDT) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3C76321F9CBD for ; Wed, 4 Sep 2013 08:39:17 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0123.003; Wed, 4 Sep 2013 08:39:08 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , Jerome Moisand Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqOMRqGNOUrYckkyTmJK+S7Yz7pm1BAEAgAAGpACAAAH2gIAAAJuAgAAFo4D//6rY8IABHywAgAAzlgCAAAYUgP//oOrA Date: Wed, 4 Sep 2013 15:39:08 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F675278@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F675278@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: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , Thomas Nadeau , Linda Dunbar , "adrian@olddog.co.uk" , Thomas Narten , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 15:39:38 -0000 Jim, I agree that the charter should not be too specific on the design of the co= ntrol plane, but rather to recognize that one could be advantageous (althou= gh not necessarily required) for the overall service chaining solution. = A control plane requirements and/or use cases document should precede any c= ontrol plane protocol design or selection. Ron -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Wednesday, September 04, 2013 10:17 AM To: Jerome Moisand; Ron Parker Cc: nsc@ietf.org; Thomas Nadeau; Thomas Narten; adrian@olddog.co.uk; Linda = Dunbar; Stewart Bryant (stbryant) Subject: Re: [nsc] NSC BoF Outcomes Hi Jerome, My bad .. Responding to your PS ;) =A9 Right now the charter suggests that = the WG be responsible for defining the requirements of the control plane wi= th respect to service chaining. The problem here is of course that there ar= e multiple control planes. In my mind it makes little sense to try and tack= le them all but rather define what is necessary for a control plane to impl= ement to successfully enable service chains and then liaise with other WG's= on the details. Some further comments inline. On 9/4/13 9:55 AM, "Jerome Moisand" wrote: >It seems to me that the entire point of service chaining is indeed to=20 >chain together heterogeneous service-enabling elements, and make the=20 >best out of such combo. Jim> exactly. The point being separate service functions into a resource pool that can be utilized and not constrained based on topology. >=20 > >Service Edge routers (including Biz-PEs, BNGs and Mobile GWs) enable L3=20 >services, on a per subscriber basis. Firewalls can act either at L3/L4=20 >or >L4/L7 (e.g. adding some Intrusion Detection to the mix). DPI or HTTP=20 >Proxies/Filters engines act at L7. Session Border Controllers act at=20 >L7, although they do some L3/L4 processing too (NAT). All those various=20 >elements have their own strengths in terms of traffic classification=20 >and in terms of policy enforcement. Which can combined in smart ways (e.g. >use DPI to identify/classify an application flow, use an edge router to=20 >perform fancy queuing based on such DPI classification among other=20 >traffic flows). Jim> yep.=20 >=20 > >The beauty of service chaining is to combine all those elements to make=20 >something truly useful (e.g. provide a more complex Service -with a=20 >capital 'S'- to service provider users or enterprise users). All the=20 >use cases I've heard so far from various parties do mix edge routers,=20 >security and application-oriented elements. > >So... I would not be supportive to trying to separate a form of L2/L3=20 >chaining from a form of L4/L7 chaining. On the contrary! ;-) > >I would actually go as far as suggesting that we should make clearer in=20 >the proposed charter that this is a strong goal, to deal with such=20 >heterogeneous combos. Jim> any text and suggestion of where to insert into the charter? > >Just my 2 cents, >Jerome > >=3D=3D=3D=3D >Totally unrelated PS for Jim: you didn't answer my question about the=20 >control plane aspects, this may have slipped through the cracks! ;-) > >-----Original Message----- >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Wednesday, September 04, 2013 6:51 AM >To: Ron Parker >Cc: nsc@ietf.org; Thomas Nadeau; Thomas Narten; adrian@olddog.co.uk;=20 >Linda Dunbar; Stewart Bryant (stbryant) >Subject: Re: [nsc] NSC BoF Outcomes > >The same argument could be applied for firewalls as without them=20 >packets would get routed instead of perhaps dropped. > >Sent from my iPhone > >On Sep 3, 2013, at 8:45 PM, "Ron Parker" > wrote: > >> Hi, Linda. >>=20 >> With respect to: >>=20 >> - Layer 4 to Layer 7 service functions (or service nodes) are to=20 >>apply actions to data packets traversing through. They don't impact=20 >>overall network topologies/routes/restorations. >>=20 >> Layer 4-7 services can, indeed, impact routing decisions. For=20 >>example, if the service is DPI analysis, then a detected protocol may=20 >>cause the subsequent packets to be policy routed on a path different=20 >>than the SPF path. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >> Linda Dunbar >> Sent: Tuesday, September 03, 2013 6:48 PM >> To: Thomas Nadeau >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten;=20 >> adrian@olddog.co.uk; Stewart Bryant (stbryant) >> Subject: Re: [nsc] NSC BoF Outcomes >>=20 >> Here are some of the reasons that chaining of Layer 2 and 3 service=20 >>functions are different from chaining of Layer 4 to 7 service=20 >>functions (I will add more later): >>=20 >>=20 >> - Layer 4 to Layer 7 service functions (or service nodes) are to=20 >>apply actions to data packets traversing through. They don't impact=20 >>overall network topologies/routes/restorations. >>=20 >> - Layer 4-7 service functions drop, pass, consume, re-initiate=20 >>packets, etc. They don't change network topologies, and they don't=20 >>impact network restoration scheme (e.g. fast re-route). When you move=20 >>a Layer 4 service module from Location A to B, the Layer 2/3 topology=20 >>is not changed, routes/restoration are not changed. >>=20 >> - When chaining Layer 4 to Layer 7 service functions together, like >>S1->S2->S3->S4, they are overlaying over the underlay network. >>=20 >> - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to=20 >>dynamically discover topology; forwarding paths; protection paths;=20 >>restoration paths, etc. Today, all routers are connected together by=20 >>links. Their topology is more like a meshed graph than chain. So when=20 >>you chain Router-1<->Router-2<->Router-3, are you talking about source=20 >>routing? Therefore, need a clear definition on what does it really=20 >>mean by chaining Layer 2/3 service nodes. >>=20 >> Linda >>=20 >>> -----Original Message----- >>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>> Sent: Tuesday, September 03, 2013 5:28 PM >>> To: Linda Dunbar >>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant=20 >>> (stbryant); Thomas Narten; adrian@olddog.co.uk >>> Subject: Re: [nsc] NSC BoF Outcomes >>>=20 >>>=20 >>> On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar=20 >>> wrote: >>>=20 >>>> Thomas, >>>>=20 >>>> Are you saying that the NSC scope includes chaining Layer 2, Layer=20 >>>> 3 >>> service functions, Layer 4 to Layer 7 service functions, and various=20 >>> combination of them? >>>=20 >>> I don't define the scope; thats up to the ADs. >>>=20 >>> Could you please answer the question below? >>>=20 >>> --Tom >>>=20 >>>>=20 >>>> Linda >>>>=20 >>>>> -----Original Message----- >>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>> Sent: Tuesday, September 03, 2013 5:19 PM >>>>> To: Linda Dunbar >>>>> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org;=20 >>>>> Thomas Narten; Stewart Bryant (stbryant) >>>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>>=20 >>>>>=20 >>>>> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar=20 >>>>> wrote: >>>>>=20 >>>>>> My comments are inserted below marked by [Linda]: >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>>=20 >>>>>>>>=20 >>>>>>>> However, it was less clear to me that there is agreement about >>> the >>>>>>> layer >>>>>>>> in >>>>>>>> which service chaining has to be solved. I felt that some=20 >>>>>>>> people were talking about service chaining in the application=20 >>>>>>>> layer, >>> some >>>>>>>> about service chaining based on flows, and some about=20 >>>>>>>> per-packet services. The solutions are, >>>>>>> I >>>>>>>> think, >>>>>>>> likely to be very different for the different problems, and it >>>>> would >>>>>>> be >>>>>>>> wrong to >>>>>>>> try to bunch them all together. >>>>>>>=20 >>>>>>> Jim> although there was certainly initial confusion I believe=20 >>>>>>> Jim> this >>>>> is >>>>>>> becoming less and less so as we socialize the basic idea of >>> service >>>>>>> chaining; indeed, as we move forward we will reflect a more=20 >>>>>>> common understanding within the problem statement. >>>>>>=20 >>>>>> It is still not clear which layer service functions are chained >>>>> together. The draft-quinn-nsc-problem-statement-03 discussed >>> chaining >>>>> of service functions that can be a network or application based=20 >>>>> packet treatment,..., to enable a service offered by a network >>> operators. >>>>>=20 >>>>> Why do you think that matters? >>>>>=20 >>>>>> Today, there are many services offered by operators, e.g. L2VPN,=20 >>>>>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 >>>>> service functions (like proxy forwarding, or fragmentation, etc.);=20 >>>>> You can also interpret NSC as chaining L4 (and above) service=20 >>>>> functions; or chaining of mixed L4-L7 service functions (i.e. with=20 >>>>> some service nodes consuming packets and reinitiate new packets). >>>>>=20 >>>>> You can, and people actually do implement this today. >>>>>=20 >>>>>> Is NSC including all chaining of all those services? >>>>>>=20 >>>>>> Layer 2/3 service function chaining might require different=20 >>>>>> schemes >>>>> than Layer 4-7 service chaining. Therefore, it is more effective=20 >>>>> to define them separately to make the discussion more focused. >>>>>=20 >>>>> I do not think so. I'd prefer to not make this only as >>> complicated >>>>> as it needs to be, and no more. There are implementations of Layer >>>>> 2 and 3 chaining that are all done with the same=20 >>>>> encap/provisioning systems. >>>>>=20 >>>>> --Tom >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Linda Dunbar >>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > > From Ron_Parker@affirmednetworks.com Wed Sep 4 08:47: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 7AB1421F92B8 for ; Wed, 4 Sep 2013 08:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 5ySiFJiTI-k5 for ; Wed, 4 Sep 2013 08:47:23 -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 B024521E80DD for ; Wed, 4 Sep 2013 08:47:23 -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.0123.003; Wed, 4 Sep 2013 08:47:21 -0700 From: Ron Parker To: Ken Gray , "mohamed.boucadair@orange.com" , "nsc@ietf.org" Thread-Topic: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt Thread-Index: Ac6fMhIAzIOqddliRk+cqJ/CnVKw9ADv8zVgAZrASQAACgW9EA== Date: Wed, 4 Sep 2013 15:47:22 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36EEEE4EC9B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.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, 04 Sep 2013 15:47:28 -0000 Hi, Ken. Responding to your comment on REQ #2, from my perspective... A particular network element (physical or virtual) can definitely support m= ultiple service functions simultaneously. Any particular chain may invoke= any of them in any order. However, I feel that it is an implementation= specific design issue whether hops between these co-resident services lite= rally follow the exact service chaining procedures that we ultimately defin= e or simply behave as if they were exactly followed (i.e., external-service= A to internal-service B to internal-service C to external-service D -- onl= y the external A to internal B and the internal C to external D are externa= lly observable). Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ken G= ray Sent: Wednesday, September 04, 2013 10:53 AM To: mohamed.boucadair@orange.com; nsc@ietf.org Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01= .txt Heya, Med. I gave it a quick read. I have the following questions/observations: REQ#2 - The document doesn't specifically say whether we're constraining ou= r focus on chains that require an "externality" for each link (that is, ARE= we assuming that each "link" will pass through a network/networked element= e.g. Hypervisor switch) - and are thus excluding from discussion IPC (or R= PC) mechanisms between service elements on the same device (which are much = harder to detect, monitor, standardize). REQ#13 is putting a constraint on the header discussion. Is this the right= place to put that, particularly since the requirements there haven't been = fully defined (yet)? REQ#15 - while I fully appreciate your desire to avoid another 80+ part ema= il thread on whether MPLS is an overlay, I think you make your point well e= nough in the main assertion and part "b" is actually redundant. 8^) REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22 has to= be a MUST (I think the need for downstream reclassification can be a norma= l outcome of the function of an individual service element as it potentiall= y transforms a header - unless your argument is that we should avoid this w= herever possible by imbedding a clue in the header - in which case we run i= nto issues with "non-speakers" or legacy devices). REQ#23 seems to obviate the use of simple route NH manipulation to create a= chain (this is destination address based). So, to be inclusive, I think t= hat has to be a SHOULD. REQ#25 seems to be difficult to require if you don't dictate how the chain = is formed (how the forwarding is instantiated) and should be worded more li= ke REQ#29, IMO. REQ#30 I think you're trying to say that static definition/topology of serv= ice functions SHOULD be supported but dynamic MUST (not that every element = has to support dynamic discovery but that the overall goal of the ongoing a= rchitecture should be dynamic with static augmentation for corner/legacy ca= ses) ...which would be more in alignment with the tenor of REQ#32. Thanks for kicking it off and reading this drivel ... On 8/27/13 2:58 AM, "mohamed.boucadair@orange.com" wrote: >Dear all, > >A new version of the requirements draft is now available online. The=20 >main changes in this new version are as follows: > >* Enrich the document with inputs from >draft-li-service-chaining-requirements >* Welcome authors of draft-li-service-chaining-requirements as=20 >co-authors >* Add new security-related requirements. >* Re-order the requirements > >A more detailed diff is available at: >http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirement >s-0 >1.txt > >Feel free to share your comments, suggestions and text contributions on=20 >the list or direct them to the authors. > >Cheers, >Med > >-----Message d'origine----- >De : i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org] >De la part de internet-drafts@ietf.org >Envoy=E9 : jeudi 22 ao=FBt 2013 14:21 >=C0 : i-d-announce@ietf.org >Objet : I-D Action: draft-boucadair-chaining-requirements-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > > > Title : Requirements for Service Function Chaining > Author(s) : Mohamed Boucadair > Christian Jacquenet > Yuanlong Jiang > Hongyu Li > Ron Parker > Filename : draft-boucadair-chaining-requirements-01.txt > Pages : 10 > Date : 2013-08-22 > >Abstract: > This document identifies the requirements for the Service Function > Chaining. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirements > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-boucadair-chaining-requirements-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirements- >01 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt >_______________________________________________ >nsc mailing 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 Sep 4 08:55: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 AD76521E80C9 for ; Wed, 4 Sep 2013 08:55:56 -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=[AWL=-0.000, 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 bFoZixw5kV98 for ; Wed, 4 Sep 2013 08:55:44 -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 618BA21E80B7 for ; Wed, 4 Sep 2013 08:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40484; q=dns/txt; s=iport; t=1378310143; x=1379519743; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=/RyJJpYV/hfT18rkF89TOg7djEzvllk1n2jp981S4AQ=; b=bKkG7MXw+CvPOoQ9Xhk2QesxO+T33LACG2E3VVH7PjSWdNHeYJFUPcA2 r8QCJUkZNcym5G2/ZetgrXJu1XiAvgBDeuppxMU7yFuqrrPIg21sItiON jYWmsuNkU3qMAXYtPEJSFcTGTvOc9rHuzlIorgKZfxqvksb73LNJQfnZf U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAPBWJ1KtJV2Y/2dsb2JhbABbgkNEgQbBPIEmFnSCJAEBAQQMIUUCFwEIEQECAQILFgEGORQDBggCBAESCId6uXWOFxaBAiAXAQaDF4EAA5QblUCDIIFpCBci X-IronPort-AV: E=Sophos;i="4.89,1021,1367971200"; d="scan'208,217";a="255554966" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 04 Sep 2013 15:55:38 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r84Ftb58022647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 15:55:37 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 10:55:37 -0500 From: "Jim Guichard (jguichar)" To: "christian.jacquenet@orange.com" , "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1pL9ggAAo6AA= Date: Wed, 4 Sep 2013 15:55:37 +0000 Message-ID: <68B171751455884590F8E38E96416F363F67549D@xmb-rcd-x01.cisco.com> In-Reply-To: <25062_1378306821_52274B05_25062_3214_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64714@PUEXCB1C.nanterre.francetelecom.fr> 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.86.241.24] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F67549Dxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 15:55:57 -0000 --_000_68B171751455884590F8E38E96416F363F67549Dxmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Christian, Thanks for the thorough review. I am working through your comments but have= one comment below in response .. From: "christian.jacquenet@orange.com" > Date: Wednesday, September 4, 2013 11:00 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: NSC Working Group Charter Proposal Dear all, Thanks to Jim for this proposal. A few comments from my side inline, in add= ition to those that were recently submitted by Med (and which I agree with)= . [snip] Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. [CJ] I would smooth the first statement a bit (mostly because it depends on= the nature and the number of the functions involved, as well as the networ= king environment). Something like: =93=85deployment techniques fail to addr= ess new challenging requirements raised by the introduction of emerging tec= hniques such as multi-tenancy, virtualization, etc.=94 I would suppress the= =93modern network architectures=94 quotation of the sentence. Networks, servers,[CJ] and other storage[CJ] technologies, [CJ] let alone= applications, have all undergone significant change in recent years: virtu= alization, network overlays, and orchestration [CJ] have increasingly becom= e techniques that count and sometimes prevail. All of these have profound e= ffects on network and services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. [CJ] maybe =93=85leading to massively static configuration procedures for n= etwork service delivery or update purposes.=94 New service insertion and deployment techniques [CJ] Maybe =93The structuring and the delivery of new network services assu= me the (smart) combination of various service functions as shared resources= , and enable=85=94 must enable the concept of service functions as shared resources, and enabl= e the linkage of these resources using service chains that represent the ab= stracted view of the required service functions, and define the order in wh= ich they should be invoked. When a service chain is instantiated in a netwo= rk, specific instances of service functions are selected, and a service top= ology is created and used for forwarding packets [CJ] according to the serv= ice chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. [CJ] I don=92t understand the previous sentence, including the kind of caus= ality effect between classification outcomes and shared information. Did yo= u mean: =93For example, the combined and ordered activation of a set of ser= vice functions possibly located in different regions of the network (or dif= ferent network elements) is an information that will be distributed to the = network elements for the sake of optimized service function and resource us= age.=94? Jim> no. This last sentence basically means that a service function might p= erform a specific action, the result of which may be useful to one or more = service functions further down the chain. The example given is classificati= on; the results of this classification might be passed to a downstream serv= ice function so that it need not perform said classification again but rath= er glean the results of the initial classification from the upstream servic= e function. Given this do you have any suggested text changes to make this = clearer? The Network Service Chaining (NSC) working group focuses on new approaches = to[CJ] network service [CJ] structuring and deployment, providing a framew= ork for the construction of services [CJ] based upon the construction of se= rvice [CJ] function chains. The WG focuses on the necessary protocols for t= he creation of service chains, and the [CJ] transmission of service-specifi= c information from the network to service functions, and between service fu= nctions. When possible, the WG will extend existing protocols to provide se= rvice chaining functionality, and any protocol extensions will be reviewed = by both the Network Service Chaining WG and by the WG responsible for the p= rotocol being extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the pro= blem space to be addressed by the Network Service Chaining WG including ter= minology and sample use cases. Additionally, the WG will normalize on nome= nclature and definitions for Network Service Chaining. CJ: as already mentioned by Med, I don=92t think the terminology effort sho= uld be part of the PS document, but rather the framework document. 2) System Architecture: this set of documents will provide a descript= ion of the architecture building blocks and their relationships including i= nterconnection, placement of capabilities, and security models, as well as = requirements on the control mechanisms and data plane encapsulation. CJ: requirements should be described in a specific document. 3) Service Chaining Data Plane: this document will describe on the wi= re data plane encapsulation in support of (2). A single encapsulation will= be selected in order to enable interoperability of data plane components. CJ: this wording is too specific and somewhat speculative (because it impli= citly assumes some kind of encapsulation is needed anyway). I would relax t= he objective a bit, and derive the specification effort according to the co= ntents of the Framework document that basically corresponds to Point #2 abo= ve. Likewise, I share Jerome=92s comment (hello J=E9r=F4me :)) about the co= ntrol plane. This should be explicitly investigated as part of the Framewor= k document, and derive the possible specification effort accordingly (for e= xample, dynamic SF discovery capabilities may involve control plane feature= s). 4) Manageability: this document will address service chaining operati= on, monitoring and troubleshooting including relevant service chaining mode= ls such as MIBs or YANG modules, along with relevant OAM capabilities and h= ow they are realized. CJ: corresponding manageability considerations should be documented first i= n the Framework. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG [CJ] Clearly distinguish between a Requirements document and a Framework do= cument, which should not be available at the same time presumably (I would = target June 2014 for the Framework document). May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG [CJ] Not sure I understand the difference in nature between the data plane = and the control plane documents (standard vs. informational). Also, I think= a gap analysis effort needs to be conducted and documented prior to any co= nsideration about publishing that kind of specification (as also suggested = by Med). This gap analysis document should be available some time in March/= April, presumably. Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG [CJ] You should delete =93requirements=94 from the above sentence. Not sure= I would be that specific at this stage (e.g., the YANG modules mentioned e= arlier have disappeared from the list above) and maybe stick to the PS/Requ= irements/Gap analysis/Framework list of WG deliverables for the time being. Cheers, Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_68B171751455884590F8E38E96416F363F67549Dxmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8967EECF45DA2641A67DB957DE9E53BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Christian,

Thanks for the thorough review. I am working through your comments but= have one comment below in response ..

From: "christian.jacquenet@orange.com" <christian.jacquenet@orange.c= om>
Date: Wednesday, September 4, 2013 = 11:00 AM
To: Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: NSC Working Group Char= ter Proposal

Dear all,

 

Thanks to Jim for this proposal. A few c= omments from my side inline, in addition to those that were recently submit= ted by Med (and which I agree with).

[snip]

Proposed NS= C WG Charter

 

Existing servi= ce insertion and deployment techniques have not evolved to meet modern netw= ork architectures and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network require= ments.

[CJ] I would smooth the first statement = a bit (mostly because it depends on the nature and the number of the functi= ons involved, as well as the networking environment). Something like: =93=85deployment techniques fail to address = new challenging requirements raised by the introduction of emerging techniq= ues such as multi-tenancy, virtualization, etc.=94 I would suppress the =93= modern network architectures=94 quotation of the sentence.

Networks, serv= ers,[CJ]  and other storage<= /span>[CJ]  technologies, [CJ] let alone applications, = have all undergone significant change in recent years: virtualization, network overlays, and orchestration [CJ] have increasingly become techniques that count and sometimes preva= il. All of these have profound effects on network and services design.

 

Today, deployi= ng new services, or making changes to existing services, often requires net= work topology changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizi= ng topological changes leading to mostly-static service definitions.=

[CJ] maybe =93=85leading to massively st= atic configuration procedures for network service delivery or update purpos= es.=94

New service in= sertion and deployment techniques

[CJ] Maybe =93The structuring and the de= livery of new network services assume the (smart) combination of various se= rvice functions as shared resources, and enable=85=94

must enable th= e concept of service functions as shared resources, and enable the linkage = of these resources using service chains that represent the abstracted view of the required service functions, and = define the order in which they should be invoked. When a service chain is= instantiated in a network, specific instances of service functions are selected, and a service topology is cre= ated and used for forwarding packets [CJ] according to the service= chain.

 

A basic servic= e chain might simply utilize an existing overlay technology to force traffi= c through the necessary service functions. However, additional information enables a richer service chain for more ad= vanced composite services. For example, shared information (e.g., the resul= t of classification) can be used to offload service function processing or = inform other service functions about information that would otherwise be hard to glean. =

[CJ] I don=92t understand the previous s= entence, including the kind of causality effect between classification outc= omes and shared information. Did you mean: =93For example, the combined and ordered activation of a set of service fu= nctions possibly located in different regions of the network (or different = network elements) is an information that will be distributed to the network= elements for the sake of optimized service function and resource usage.=94?

Jim> no. This last sentence basically means that a service function= might perform a specific action, the result of which may be useful to one = or more service functions further down the chain. The example given is clas= sification; the results of this classification might be passed to a downstream service function so that it need not perfo= rm said classification again but rather glean the results of the initial cl= assification from the upstream service function. Given this do you have any= suggested text changes to make this clearer?

 

The Network Se= rvice Chaining (NSC) working group focuses on new approaches to[CJ]  network service [CJ] structuring and deployme= nt, providing a framework for the construction of services [CJ] based upon the construction of service [CJ] function chains. The WG focuses on the necessary protocols for the c= reation of service chains, and the [CJ] transmission of service-specific informa= tion from the network to service functions, and between service functions. When possible, the WG= will extend existing protocols to provide service chaining functionality, = and any protocol extensions will be reviewed by both the Network Service Ch= aining WG and by the WG responsible for the protocol being extended.  

 

Specifically, = the Network Service Chaining WG is chartered to deliver the following work = items: 

 

1)  = ;     Problem Statement: this documen= t will provide a summary of the problem space to be addressed by the Networ= k Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomencl= ature and definitions for Network Service Chaining.

CJ: as already mentioned by Med, I don=92t think the terminology effort= should be part of the PS document, but rather the framework document.

 

2)  = ;     System Architecture: this set o= f documents will provide a description of the architecture building blocks = and their relationships including interconnection, placement of capabilities, and security models, as well a= s requirements on the control mechanisms and data plane encapsulation.=

CJ: requirements should be described in a specific document.=

 

3)  = ;     Service Chaining Data Plane: th= is document will describe on the wire data plane encapsulation in support o= f (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.<= o:p>

CJ:= this wording is too specific and somewhat speculative (because it implicit= ly assumes some kind of encapsulation is needed anyway). I would relax the objective a bit, and derive the speci= fication effort according to the contents of the Framework document that ba= sically corresponds to Point #2 above. Likewise, I share Jerome=92s comment= (hello J=E9r=F4me J) about the control plane. This should be expl= icitly investigated as part of the Framework document, and derive the possible specification effort accordingly (for ex= ample, dynamic SF discovery capabilities may involve control plane features= ).

 

4)  = ;     Manageability: this document wi= ll address service chaining operation, monitoring and troubleshooting inclu= ding relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how= they are realized.

CJ:= corresponding manageability considerations should be documented first in t= he Framework.

 

Proposed Miles= tones:

 

Dec 2013 Reque= st publication of an Informational document defining the Network Service Ch= aining problem statement to the IESG

 

Mar 2014 Reque= st publication of informational documents defining the system architecture = including protocol requirements and framework to the IESG

[CJ] Clearly distinguish between a Requi= rements document and a Framework document, which should not be available at= the same time presumably (I would target June 2014 for the Framework document).

 

May 2014 Reque= st publication of a Standards Track document specifying the data-plane (inc= luding metadata) for Service Chaining to IESG

 

May 2014 Reque= st publication of an informational document specifying Service Chaining Con= trol Plane requirements to IESG

[CJ] Not sure I understand the differenc= e in nature between the data plane and the control plane documents (standar= d vs. informational). Also, I think a gap analysis effort needs to be conducted and documented prior to any co= nsideration about publishing that kind of specification (as also suggested = by Med). This gap analysis document should be available some time in March/= April, presumably.

 

Dec 2014 Reque= st publication of informational documents defining Service Chaining managea= bility requirements including MIBs, OAM, and information models to IESG

[CJ] You should delete =93requirements= =94 from the above sentence. Not sure I would be that specific at this stag= e (e.g., the YANG modules mentioned earlier have disappeared from the list above) and maybe stick to the PS/Requiremen= ts/Gap analysis/Framework list of WG deliverables for the time being.<= /o:p>

 

Cheers,

 

Christian.

 

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_68B171751455884590F8E38E96416F363F67549Dxmbrcdx01ciscoc_-- From jguichar@cisco.com Wed Sep 4 08:57: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 2CD1A11E81D2 for ; Wed, 4 Sep 2013 08:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 nTsqOQrJyjOE for ; Wed, 4 Sep 2013 08:56:58 -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 59C7611E81D3 for ; Wed, 4 Sep 2013 08:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11001; q=dns/txt; s=iport; t=1378310218; x=1379519818; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=tLxVfSu3lzSbLxQQ+T8iJCTHTe0A4/HTG1ORBPKvy4M=; b=fS+y4YKiZNav+9Bc2eR9Guh4tmjO2Rw08ZfG/sg3tk3YBXJy00L5ZNwg 3N6f1+jjYRorgO6wKBJvV7KU192LsOB8uSgG21JEquMkQmBqbmim08EPr lx+Ccuvqkt6ydofID9EETZvT/1SU2vCnktWOgowJL3wQSUf1NBwajMKnW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAOFXJ1KtJXHB/2dsb2JhbABRCoMHNVHBPIEmFnSCJAEBAQQBAQEkRwsMBgEIEQQBAQEKHS4LFAkIAgQBDQUIE4dnDLloBI4dgRIGKwcGgxeBAAOpW4Mggio X-IronPort-AV: E=Sophos;i="4.89,1021,1367971200"; d="scan'208";a="255342937" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 04 Sep 2013 15:56:57 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r84FuvXQ003156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 15:56:57 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 10:56:56 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker , Jerome Moisand Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: Ac6YFyk/aYEs8EPbQVuX5dlVLbZ5nAQ1EMqAAAutBgAAANR+AAAAPryAAAATX4AAALROgAAEGq4AAAqrvDYAEOzoAP//wwOAgABZ5QD//8HmAA== Date: Wed, 4 Sep 2013 15:56:56 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6754BE@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.86.241.24] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <81ABA135B0F5A24F8377CCDF111FC467@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , Thomas Nadeau , Linda Dunbar , "adrian@olddog.co.uk" , Thomas Narten , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 15:57:06 -0000 Is the suggestion therefore that separate data and control plane requirements I-D's should be created rather than an overall requirements document covering both? On 9/4/13 11:39 AM, "Ron Parker" wrote: >Jim, > >I agree that the charter should not be too specific on the design of the >control plane, but rather to recognize that one could be advantageous >(although not necessarily required) for the overall service chaining >solution. A control plane requirements and/or use cases document >should precede any control plane protocol design or selection. > > Ron > > >-----Original Message----- >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Wednesday, September 04, 2013 10:17 AM >To: Jerome Moisand; Ron Parker >Cc: nsc@ietf.org; Thomas Nadeau; Thomas Narten; adrian@olddog.co.uk; >Linda Dunbar; Stewart Bryant (stbryant) >Subject: Re: [nsc] NSC BoF Outcomes > >Hi Jerome, > >My bad .. Responding to your PS ;) =A9 Right now the charter suggests that >the WG be responsible for defining the requirements of the control plane >with respect to service chaining. The problem here is of course that >there are multiple control planes. In my mind it makes little sense to >try and tackle them all but rather define what is necessary for a control >plane to implement to successfully enable service chains and then liaise >with other WG's on the details. > >Some further comments inline. > >On 9/4/13 9:55 AM, "Jerome Moisand" wrote: > >>It seems to me that the entire point of service chaining is indeed to >>chain together heterogeneous service-enabling elements, and make the >>best out of such combo. > >Jim> exactly. The point being separate service functions into a resource >pool that can be utilized and not constrained based on topology. > >>=20 >> >>Service Edge routers (including Biz-PEs, BNGs and Mobile GWs) enable L3 >>services, on a per subscriber basis. Firewalls can act either at L3/L4 >>or >>L4/L7 (e.g. adding some Intrusion Detection to the mix). DPI or HTTP >>Proxies/Filters engines act at L7. Session Border Controllers act at >>L7, although they do some L3/L4 processing too (NAT). All those various >>elements have their own strengths in terms of traffic classification >>and in terms of policy enforcement. Which can combined in smart ways >>(e.g. >>use DPI to identify/classify an application flow, use an edge router to >>perform fancy queuing based on such DPI classification among other >>traffic flows). > >Jim> yep.=20 > >>=20 >> >>The beauty of service chaining is to combine all those elements to make >>something truly useful (e.g. provide a more complex Service -with a >>capital 'S'- to service provider users or enterprise users). All the >>use cases I've heard so far from various parties do mix edge routers, >>security and application-oriented elements. >> >>So... I would not be supportive to trying to separate a form of L2/L3 >>chaining from a form of L4/L7 chaining. On the contrary! ;-) >> >>I would actually go as far as suggesting that we should make clearer in >>the proposed charter that this is a strong goal, to deal with such >>heterogeneous combos. > >Jim> any text and suggestion of where to insert into the charter? > >> >>Just my 2 cents, >>Jerome >> >>=3D=3D=3D=3D >>Totally unrelated PS for Jim: you didn't answer my question about the >>control plane aspects, this may have slipped through the cracks! ;-) >> >>-----Original Message----- >>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>Sent: Wednesday, September 04, 2013 6:51 AM >>To: Ron Parker >>Cc: nsc@ietf.org; Thomas Nadeau; Thomas Narten; adrian@olddog.co.uk; >>Linda Dunbar; Stewart Bryant (stbryant) >>Subject: Re: [nsc] NSC BoF Outcomes >> >>The same argument could be applied for firewalls as without them >>packets would get routed instead of perhaps dropped. >> >>Sent from my iPhone >> >>On Sep 3, 2013, at 8:45 PM, "Ron Parker" >> wrote: >> >>> Hi, Linda. >>>=20 >>> With respect to: >>>=20 >>> - Layer 4 to Layer 7 service functions (or service nodes) are to >>>apply actions to data packets traversing through. They don't impact >>>overall network topologies/routes/restorations. >>>=20 >>> Layer 4-7 services can, indeed, impact routing decisions. For >>>example, if the service is DPI analysis, then a detected protocol may >>>cause the subsequent packets to be policy routed on a path different >>>than the SPF path. >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>> Linda Dunbar >>> Sent: Tuesday, September 03, 2013 6:48 PM >>> To: Thomas Nadeau >>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; >>> adrian@olddog.co.uk; Stewart Bryant (stbryant) >>> Subject: Re: [nsc] NSC BoF Outcomes >>>=20 >>> Here are some of the reasons that chaining of Layer 2 and 3 service >>>functions are different from chaining of Layer 4 to 7 service >>>functions (I will add more later): >>>=20 >>>=20 >>> - Layer 4 to Layer 7 service functions (or service nodes) are to >>>apply actions to data packets traversing through. They don't impact >>>overall network topologies/routes/restorations. >>>=20 >>> - Layer 4-7 service functions drop, pass, consume, re-initiate >>>packets, etc. They don't change network topologies, and they don't >>>impact network restoration scheme (e.g. fast re-route). When you move >>>a Layer 4 service module from Location A to B, the Layer 2/3 topology >>>is not changed, routes/restoration are not changed. >>>=20 >>> - When chaining Layer 4 to Layer 7 service functions together, like >>>S1->S2->S3->S4, they are overlaying over the underlay network. >>>=20 >>> - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to >>>dynamically discover topology; forwarding paths; protection paths; >>>restoration paths, etc. Today, all routers are connected together by >>>links. Their topology is more like a meshed graph than chain. So when >>>you chain Router-1<->Router-2<->Router-3, are you talking about source >>>routing? Therefore, need a clear definition on what does it really >>>mean by chaining Layer 2/3 service nodes. >>>=20 >>> Linda >>>=20 >>>> -----Original Message----- >>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>> Sent: Tuesday, September 03, 2013 5:28 PM >>>> To: Linda Dunbar >>>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant >>>> (stbryant); Thomas Narten; adrian@olddog.co.uk >>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>=20 >>>>=20 >>>> On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar >>>> wrote: >>>>=20 >>>>> Thomas, >>>>>=20 >>>>> Are you saying that the NSC scope includes chaining Layer 2, Layer >>>>> 3 >>>> service functions, Layer 4 to Layer 7 service functions, and various >>>> combination of them? >>>>=20 >>>> I don't define the scope; thats up to the ADs. >>>>=20 >>>> Could you please answer the question below? >>>>=20 >>>> --Tom >>>>=20 >>>>>=20 >>>>> Linda >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>>> Sent: Tuesday, September 03, 2013 5:19 PM >>>>>> To: Linda Dunbar >>>>>> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org; >>>>>> Thomas Narten; Stewart Bryant (stbryant) >>>>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>>>=20 >>>>>>=20 >>>>>> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar >>>>>> wrote: >>>>>>=20 >>>>>>> My comments are inserted below marked by [Linda]: >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> However, it was less clear to me that there is agreement about >>>> the >>>>>>>> layer >>>>>>>>> in >>>>>>>>> which service chaining has to be solved. I felt that some >>>>>>>>> people were talking about service chaining in the application >>>>>>>>> layer, >>>> some >>>>>>>>> about service chaining based on flows, and some about >>>>>>>>> per-packet services. The solutions are, >>>>>>>> I >>>>>>>>> think, >>>>>>>>> likely to be very different for the different problems, and it >>>>>> would >>>>>>>> be >>>>>>>>> wrong to >>>>>>>>> try to bunch them all together. >>>>>>>>=20 >>>>>>>> Jim> although there was certainly initial confusion I believe >>>>>>>> Jim> this >>>>>> is >>>>>>>> becoming less and less so as we socialize the basic idea of >>>> service >>>>>>>> chaining; indeed, as we move forward we will reflect a more >>>>>>>> common understanding within the problem statement. >>>>>>>=20 >>>>>>> It is still not clear which layer service functions are chained >>>>>> together. The draft-quinn-nsc-problem-statement-03 discussed >>>> chaining >>>>>> of service functions that can be a network or application based >>>>>> packet treatment,..., to enable a service offered by a network >>>> operators. >>>>>>=20 >>>>>> Why do you think that matters? >>>>>>=20 >>>>>>> Today, there are many services offered by operators, e.g. L2VPN, >>>>>>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 >>>>>> service functions (like proxy forwarding, or fragmentation, etc.); >>>>>> You can also interpret NSC as chaining L4 (and above) service >>>>>> functions; or chaining of mixed L4-L7 service functions (i.e. with >>>>>> some service nodes consuming packets and reinitiate new packets). >>>>>>=20 >>>>>> You can, and people actually do implement this today. >>>>>>=20 >>>>>>> Is NSC including all chaining of all those services? >>>>>>>=20 >>>>>>> Layer 2/3 service function chaining might require different >>>>>>> schemes >>>>>> than Layer 4-7 service chaining. Therefore, it is more effective >>>>>> to define them separately to make the discussion more focused. >>>>>>=20 >>>>>> I do not think so. I'd prefer to not make this only as >>>> complicated >>>>>> as it needs to be, and no more. There are implementations of Layer >>>>>> 2 and 3 chaining that are all done with the same >>>>>> encap/provisioning systems. >>>>>>=20 >>>>>> --Tom >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Linda Dunbar >>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>=20 >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >> >> > From Ron_Parker@affirmednetworks.com Wed Sep 4 09:03: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 0F48921F8E2D for ; Wed, 4 Sep 2013 09:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 bFU7-XQ9NLms for ; Wed, 4 Sep 2013 09:03:12 -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 0640F11E81D1 for ; Wed, 4 Sep 2013 09:02:41 -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.0123.003; Wed, 4 Sep 2013 09:02:36 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , Jerome Moisand Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqOMRqGNOUrYckkyTmJK+S7Yz7pm1BAEAgAAGpACAAAH2gIAAAJuAgAAFo4D//6rY8IABHywAgAAzlgCAAAYUgP//oOrAgAB65AD//4vnAA== Date: Wed, 4 Sep 2013 16:02:35 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F6754BE@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6754BE@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: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , Thomas Nadeau , Linda Dunbar , "adrian@olddog.co.uk" , Thomas Narten , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 16:03:19 -0000 Yes, that is my suggestion. It is motivated by my feeling that a control = plane is advantageous but not required. By separating them, we could mor= e readily phase the work. Ron -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Wednesday, September 04, 2013 11:57 AM To: Ron Parker; Jerome Moisand Cc: nsc@ietf.org; Thomas Nadeau; Thomas Narten; adrian@olddog.co.uk; Linda = Dunbar; Stewart Bryant (stbryant) Subject: Re: [nsc] NSC BoF Outcomes Is the suggestion therefore that separate data and control plane requiremen= ts I-D's should be created rather than an overall requirements document cov= ering both? On 9/4/13 11:39 AM, "Ron Parker" wrote: >Jim, > >I agree that the charter should not be too specific on the design of=20 >the control plane, but rather to recognize that one could be=20 >advantageous (although not necessarily required) for the overall service c= haining >solution. A control plane requirements and/or use cases document >should precede any control plane protocol design or selection. > > Ron > > >-----Original Message----- >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Wednesday, September 04, 2013 10:17 AM >To: Jerome Moisand; Ron Parker >Cc: nsc@ietf.org; Thomas Nadeau; Thomas Narten; adrian@olddog.co.uk;=20 >Linda Dunbar; Stewart Bryant (stbryant) >Subject: Re: [nsc] NSC BoF Outcomes > >Hi Jerome, > >My bad .. Responding to your PS ;) =A9 Right now the charter suggests=20 >that the WG be responsible for defining the requirements of the control=20 >plane with respect to service chaining. The problem here is of course=20 >that there are multiple control planes. In my mind it makes little=20 >sense to try and tackle them all but rather define what is necessary=20 >for a control plane to implement to successfully enable service chains=20 >and then liaise with other WG's on the details. > >Some further comments inline. > >On 9/4/13 9:55 AM, "Jerome Moisand" wrote: > >>It seems to me that the entire point of service chaining is indeed to=20 >>chain together heterogeneous service-enabling elements, and make the=20 >>best out of such combo. > >Jim> exactly. The point being separate service functions into a=20 >Jim> resource >pool that can be utilized and not constrained based on topology. > >>=20 >> >>Service Edge routers (including Biz-PEs, BNGs and Mobile GWs) enable=20 >>L3 services, on a per subscriber basis. Firewalls can act either at=20 >>L3/L4 or >>L4/L7 (e.g. adding some Intrusion Detection to the mix). DPI or HTTP=20 >>Proxies/Filters engines act at L7. Session Border Controllers act at=20 >>L7, although they do some L3/L4 processing too (NAT). All those=20 >>various elements have their own strengths in terms of traffic=20 >>classification and in terms of policy enforcement. Which can combined=20 >>in smart ways (e.g. >>use DPI to identify/classify an application flow, use an edge router=20 >>to perform fancy queuing based on such DPI classification among other=20 >>traffic flows). > >Jim> yep.=20 > >>=20 >> >>The beauty of service chaining is to combine all those elements to=20 >>make something truly useful (e.g. provide a more complex Service -with=20 >>a capital 'S'- to service provider users or enterprise users). All the=20 >>use cases I've heard so far from various parties do mix edge routers,=20 >>security and application-oriented elements. >> >>So... I would not be supportive to trying to separate a form of L2/L3=20 >>chaining from a form of L4/L7 chaining. On the contrary! ;-) >> >>I would actually go as far as suggesting that we should make clearer=20 >>in the proposed charter that this is a strong goal, to deal with such=20 >>heterogeneous combos. > >Jim> any text and suggestion of where to insert into the charter? > >> >>Just my 2 cents, >>Jerome >> >>=3D=3D=3D=3D >>Totally unrelated PS for Jim: you didn't answer my question about the=20 >>control plane aspects, this may have slipped through the cracks! ;-) >> >>-----Original Message----- >>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>Sent: Wednesday, September 04, 2013 6:51 AM >>To: Ron Parker >>Cc: nsc@ietf.org; Thomas Nadeau; Thomas Narten; adrian@olddog.co.uk;=20 >>Linda Dunbar; Stewart Bryant (stbryant) >>Subject: Re: [nsc] NSC BoF Outcomes >> >>The same argument could be applied for firewalls as without them=20 >>packets would get routed instead of perhaps dropped. >> >>Sent from my iPhone >> >>On Sep 3, 2013, at 8:45 PM, "Ron Parker" >> wrote: >> >>> Hi, Linda. >>>=20 >>> With respect to: >>>=20 >>> - Layer 4 to Layer 7 service functions (or service nodes) are to=20 >>>apply actions to data packets traversing through. They don't impact=20 >>>overall network topologies/routes/restorations. >>>=20 >>> Layer 4-7 services can, indeed, impact routing decisions. For=20 >>>example, if the service is DPI analysis, then a detected protocol may=20 >>>cause the subsequent packets to be policy routed on a path different=20 >>>than the SPF path. >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>> Of Linda Dunbar >>> Sent: Tuesday, September 03, 2013 6:48 PM >>> To: Thomas Nadeau >>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten;=20 >>> adrian@olddog.co.uk; Stewart Bryant (stbryant) >>> Subject: Re: [nsc] NSC BoF Outcomes >>>=20 >>> Here are some of the reasons that chaining of Layer 2 and 3 service=20 >>>functions are different from chaining of Layer 4 to 7 service=20 >>>functions (I will add more later): >>>=20 >>>=20 >>> - Layer 4 to Layer 7 service functions (or service nodes) are to=20 >>>apply actions to data packets traversing through. They don't impact=20 >>>overall network topologies/routes/restorations. >>>=20 >>> - Layer 4-7 service functions drop, pass, consume, re-initiate=20 >>>packets, etc. They don't change network topologies, and they don't=20 >>>impact network restoration scheme (e.g. fast re-route). When you=20 >>>move a Layer 4 service module from Location A to B, the Layer 2/3=20 >>>topology is not changed, routes/restoration are not changed. >>>=20 >>> - When chaining Layer 4 to Layer 7 service functions together, like >>>S1->S2->S3->S4, they are overlaying over the underlay network. >>>=20 >>> - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to=20 >>>dynamically discover topology; forwarding paths; protection paths;=20 >>>restoration paths, etc. Today, all routers are connected together by=20 >>>links. Their topology is more like a meshed graph than chain. So when=20 >>>you chain Router-1<->Router-2<->Router-3, are you talking about=20 >>>source routing? Therefore, need a clear definition on what does it=20 >>>really mean by chaining Layer 2/3 service nodes. >>>=20 >>> Linda >>>=20 >>>> -----Original Message----- >>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>> Sent: Tuesday, September 03, 2013 5:28 PM >>>> To: Linda Dunbar >>>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant=20 >>>> (stbryant); Thomas Narten; adrian@olddog.co.uk >>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>=20 >>>>=20 >>>> On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar=20 >>>> wrote: >>>>=20 >>>>> Thomas, >>>>>=20 >>>>> Are you saying that the NSC scope includes chaining Layer 2, Layer >>>>> 3 >>>> service functions, Layer 4 to Layer 7 service functions, and=20 >>>> various combination of them? >>>>=20 >>>> I don't define the scope; thats up to the ADs. >>>>=20 >>>> Could you please answer the question below? >>>>=20 >>>> --Tom >>>>=20 >>>>>=20 >>>>> Linda >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>>> Sent: Tuesday, September 03, 2013 5:19 PM >>>>>> To: Linda Dunbar >>>>>> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org;=20 >>>>>> Thomas Narten; Stewart Bryant (stbryant) >>>>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>>>=20 >>>>>>=20 >>>>>> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar=20 >>>>>> wrote: >>>>>>=20 >>>>>>> My comments are inserted below marked by [Linda]: >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> However, it was less clear to me that there is agreement about >>>> the >>>>>>>> layer >>>>>>>>> in >>>>>>>>> which service chaining has to be solved. I felt that some=20 >>>>>>>>> people were talking about service chaining in the application=20 >>>>>>>>> layer, >>>> some >>>>>>>>> about service chaining based on flows, and some about=20 >>>>>>>>> per-packet services. The solutions are, >>>>>>>> I >>>>>>>>> think, >>>>>>>>> likely to be very different for the different problems, and it >>>>>> would >>>>>>>> be >>>>>>>>> wrong to >>>>>>>>> try to bunch them all together. >>>>>>>>=20 >>>>>>>> Jim> although there was certainly initial confusion I believe=20 >>>>>>>> Jim> this >>>>>> is >>>>>>>> becoming less and less so as we socialize the basic idea of >>>> service >>>>>>>> chaining; indeed, as we move forward we will reflect a more=20 >>>>>>>> common understanding within the problem statement. >>>>>>>=20 >>>>>>> It is still not clear which layer service functions are chained >>>>>> together. The draft-quinn-nsc-problem-statement-03 discussed >>>> chaining >>>>>> of service functions that can be a network or application based=20 >>>>>> packet treatment,..., to enable a service offered by a network >>>> operators. >>>>>>=20 >>>>>> Why do you think that matters? >>>>>>=20 >>>>>>> Today, there are many services offered by operators, e.g. L2VPN,=20 >>>>>>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining=20 >>>>>>> L2/L3 >>>>>> service functions (like proxy forwarding, or fragmentation,=20 >>>>>> etc.); You can also interpret NSC as chaining L4 (and above)=20 >>>>>> service functions; or chaining of mixed L4-L7 service functions=20 >>>>>> (i.e. with some service nodes consuming packets and reinitiate new p= ackets). >>>>>>=20 >>>>>> You can, and people actually do implement this today. >>>>>>=20 >>>>>>> Is NSC including all chaining of all those services? >>>>>>>=20 >>>>>>> Layer 2/3 service function chaining might require different=20 >>>>>>> schemes >>>>>> than Layer 4-7 service chaining. Therefore, it is more effective=20 >>>>>> to define them separately to make the discussion more focused. >>>>>>=20 >>>>>> I do not think so. I'd prefer to not make this only as >>>> complicated >>>>>> as it needs to be, and no more. There are implementations of=20 >>>>>> Layer >>>>>> 2 and 3 chaining that are all done with the same=20 >>>>>> encap/provisioning systems. >>>>>>=20 >>>>>> --Tom >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Linda Dunbar >>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>=20 >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >> >> > From christian.jacquenet@orange.com Wed Sep 4 09:03: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 EB6F721F92B9 for ; Wed, 4 Sep 2013 09:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrQk3jpLHbmN for ; Wed, 4 Sep 2013 09:03:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 614EE21F8E1F for ; Wed, 4 Sep 2013 09:02:50 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 242E52DC135; Wed, 4 Sep 2013 18:02:45 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id CEB2F35C0B9; Wed, 4 Sep 2013 18:02:44 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 4 Sep 2013 18:02:44 +0200 From: To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Date: Wed, 4 Sep 2013 18:02:43 +0200 Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1pL9ggAAo6AD///Ct8A== Message-ID: <17590_1378310565_522759A5_17590_277_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64784@PUEXCB1C.nanterre.francetelecom.fr> References: <25062_1378306821_52274B05_25062_3214_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64714@PUEXCB1C.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F67549D@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F67549D@xmb-rcd-x01.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64784PUEXCB1Cnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.90030 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 16:03:48 -0000 --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64784PUEXCB1Cnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Jim, Thanks for the clarification. [snip] Jim> no. This last sentence basically means that a service function might p= erform a specific action, the result of which may be useful to one or more = service functions further down the chain. The example given is classificati= on; the results of this classification might be passed to a downstream serv= ice function so that it need not perform said classification again but rath= er glean the results of the initial classification from the upstream servic= e function. Given this do you have any suggested text changes to make this = clearer? [CJ] I guess I would use your explanation as the illustrative sentence: "Fo= r example, the results of a classification might be passed to a downstream = function..." Cheers, Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64784PUEXCB1Cnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Jim,

 

Thanks for the clarification.

[snip]

=

Jim> n= o. This last sentence basically means that a service function might perform= a specific action, the result of which may be useful to one or more servic= e functions further down the chain. The example given is classification; th= e results of this classification might be passed to a downstream service fu= nction so that it need not perform said classification again but rather gle= an the results of the initial classification from the upstream service func= tion. Given this do you have any suggested text changes to make this cleare= r?

[CJ] I guess I would use your ex= planation as the illustrative sentence: “For example, the results of = a classification might be passed to a downstream function…”

 

Cheers,

 

Christian.

<= p class=3DMsoNormal style=3D'margin-left:36.0pt'> 

___________________________________________________=
______________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64784PUEXCB1Cnante_-- From christian.jacquenet@orange.com Wed Sep 4 09:04: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 34D3F21F8EDF for ; Wed, 4 Sep 2013 09:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 uNPgKvz5zb4W for ; Wed, 4 Sep 2013 09:04:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 5F17421F8C20 for ; Wed, 4 Sep 2013 09:04:24 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 2431B3756EA; Wed, 4 Sep 2013 18:04:23 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 0280AC812F; Wed, 4 Sep 2013 18:04:23 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.13]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 4 Sep 2013 18:04:22 +0200 From: To: "Jim Guichard (jguichar)" , Ron Parker , Jerome Moisand Date: Wed, 4 Sep 2013 18:04:21 +0200 Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: Ac6YFyk/aYEs8EPbQVuX5dlVLbZ5nAQ1EMqAAAutBgAAANR+AAAAPryAAAATX4AAALROgAAEGq4AAAqrvDYAEOzoAP//wwOAgABZ5QD//8HmAIAADuog Message-ID: <1152_1378310663_52275A07_1152_6102_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64788@PUEXCB1C.nanterre.francetelecom.fr> References: <68B171751455884590F8E38E96416F363F6754BE@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6754BE@xmb-rcd-x01.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.4.145414 Cc: "nsc@ietf.org" , Thomas Nadeau , Thomas Narten , "adrian@olddog.co.uk" , Linda Dunbar , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 16:04:32 -0000 SGkqLA0KDQpJIHN1cHBvcnQgdGhlIHB1YmxpY2F0aW9uIG9mIGEgc2luZ2xlIHJlcXVpcmVtZW50 cyBkb2N1bWVudCAoZm9yIHRoZSBzYWtlIG9mIGNvbnNpc3RlbmN5KSwgYW5kIHdoaWNoIHdvdWxk IGluY2x1ZGUgYm90aCBjb250cm9sIGFuZCBkYXRhIHBsYW5lIGNvbnNpZGVyYXRpb25zIGFtb25n IG90aGVyIHRvcGljcy4NCg0KQ2hlZXJzLA0KDQpDaHJpc3RpYW4uDQoNCi0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KRGXCoDogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91 bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0KRW52 b3nDqcKgOiBtZXJjcmVkaSA0IHNlcHRlbWJyZSAyMDEzIDE3OjU3DQrDgMKgOiBSb24gUGFya2Vy OyBKZXJvbWUgTW9pc2FuZA0KQ2PCoDogbnNjQGlldGYub3JnOyBUaG9tYXMgTmFkZWF1OyBMaW5k YSBEdW5iYXI7IGFkcmlhbkBvbGRkb2cuY28udWs7IFRob21hcyBOYXJ0ZW47IFN0ZXdhcnQgQnJ5 YW50IChzdGJyeWFudCkNCk9iamV0wqA6IFJlOiBbbnNjXSBOU0MgQm9GIE91dGNvbWVzDQoNCklz IHRoZSBzdWdnZXN0aW9uIHRoZXJlZm9yZSB0aGF0IHNlcGFyYXRlIGRhdGEgYW5kIGNvbnRyb2wg cGxhbmUgcmVxdWlyZW1lbnRzIEktRCdzIHNob3VsZCBiZSBjcmVhdGVkIHJhdGhlciB0aGFuIGFu IG92ZXJhbGwgcmVxdWlyZW1lbnRzIGRvY3VtZW50IGNvdmVyaW5nIGJvdGg/DQoNCk9uIDkvNC8x MyAxMTozOSBBTSwgIlJvbiBQYXJrZXIiIDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t PiB3cm90ZToNCg0KPkppbSwNCj4NCj5JIGFncmVlIHRoYXQgdGhlIGNoYXJ0ZXIgc2hvdWxkIG5v dCBiZSB0b28gc3BlY2lmaWMgb24gdGhlIGRlc2lnbiBvZiANCj50aGUgY29udHJvbCBwbGFuZSwg YnV0IHJhdGhlciB0byByZWNvZ25pemUgdGhhdCBvbmUgY291bGQgYmUgDQo+YWR2YW50YWdlb3Vz IChhbHRob3VnaCBub3QgbmVjZXNzYXJpbHkgcmVxdWlyZWQpIGZvciB0aGUgb3ZlcmFsbCBzZXJ2 aWNlIGNoYWluaW5nDQo+c29sdXRpb24uICAgIEEgY29udHJvbCBwbGFuZSByZXF1aXJlbWVudHMg YW5kL29yIHVzZSBjYXNlcyBkb2N1bWVudA0KPnNob3VsZCBwcmVjZWRlIGFueSBjb250cm9sIHBs YW5lIHByb3RvY29sIGRlc2lnbiBvciBzZWxlY3Rpb24uDQo+DQo+ICAgUm9uDQo+DQo+DQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBb bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCj5TZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAw NCwgMjAxMyAxMDoxNyBBTQ0KPlRvOiBKZXJvbWUgTW9pc2FuZDsgUm9uIFBhcmtlcg0KPkNjOiBu c2NAaWV0Zi5vcmc7IFRob21hcyBOYWRlYXU7IFRob21hcyBOYXJ0ZW47IGFkcmlhbkBvbGRkb2cu Y28udWs7IA0KPkxpbmRhIER1bmJhcjsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KQ0KPlN1Ympl Y3Q6IFJlOiBbbnNjXSBOU0MgQm9GIE91dGNvbWVzDQo+DQo+SGkgSmVyb21lLA0KPg0KPk15IGJh ZCAuLiBSZXNwb25kaW5nIHRvIHlvdXIgUFMgOykgxaAgUmlnaHQgbm93IHRoZSBjaGFydGVyIHN1 Z2dlc3RzIA0KPnRoYXQgdGhlIFdHIGJlIHJlc3BvbnNpYmxlIGZvciBkZWZpbmluZyB0aGUgcmVx dWlyZW1lbnRzIG9mIHRoZSBjb250cm9sIA0KPnBsYW5lIHdpdGggcmVzcGVjdCB0byBzZXJ2aWNl IGNoYWluaW5nLiBUaGUgcHJvYmxlbSBoZXJlIGlzIG9mIGNvdXJzZSANCj50aGF0IHRoZXJlIGFy ZSBtdWx0aXBsZSBjb250cm9sIHBsYW5lcy4gSW4gbXkgbWluZCBpdCBtYWtlcyBsaXR0bGUgDQo+ c2Vuc2UgdG8gdHJ5IGFuZCB0YWNrbGUgdGhlbSBhbGwgYnV0IHJhdGhlciBkZWZpbmUgd2hhdCBp cyBuZWNlc3NhcnkgDQo+Zm9yIGEgY29udHJvbCBwbGFuZSB0byBpbXBsZW1lbnQgdG8gc3VjY2Vz c2Z1bGx5IGVuYWJsZSBzZXJ2aWNlIGNoYWlucyANCj5hbmQgdGhlbiBsaWFpc2Ugd2l0aCBvdGhl ciBXRydzIG9uIHRoZSBkZXRhaWxzLg0KPg0KPlNvbWUgZnVydGhlciBjb21tZW50cyBpbmxpbmUu DQo+DQo+T24gOS80LzEzIDk6NTUgQU0sICJKZXJvbWUgTW9pc2FuZCIgPGptb2lzYW5kQGp1bmlw ZXIubmV0PiB3cm90ZToNCj4NCj4+SXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgZW50aXJlIHBvaW50 IG9mIHNlcnZpY2UgY2hhaW5pbmcgaXMgaW5kZWVkIHRvIA0KPj5jaGFpbiB0b2dldGhlciBoZXRl cm9nZW5lb3VzIHNlcnZpY2UtZW5hYmxpbmcgZWxlbWVudHMsIGFuZCBtYWtlIHRoZSANCj4+YmVz dCBvdXQgb2Ygc3VjaCBjb21iby4NCj4NCj5KaW0+IGV4YWN0bHkuIFRoZSBwb2ludCBiZWluZyBz ZXBhcmF0ZSBzZXJ2aWNlIGZ1bmN0aW9ucyBpbnRvIGEgDQo+SmltPiByZXNvdXJjZQ0KPnBvb2wg dGhhdCBjYW4gYmUgdXRpbGl6ZWQgYW5kIG5vdCBjb25zdHJhaW5lZCBiYXNlZCBvbiB0b3BvbG9n eS4NCj4NCj4+IA0KPj4NCj4+U2VydmljZSBFZGdlIHJvdXRlcnMgKGluY2x1ZGluZyBCaXotUEVz LCBCTkdzIGFuZCBNb2JpbGUgR1dzKSBlbmFibGUgDQo+PkwzIHNlcnZpY2VzLCBvbiBhIHBlciBz dWJzY3JpYmVyIGJhc2lzLiBGaXJld2FsbHMgY2FuIGFjdCBlaXRoZXIgYXQgDQo+PkwzL0w0IG9y DQo+Pkw0L0w3IChlLmcuIGFkZGluZyBzb21lIEludHJ1c2lvbiBEZXRlY3Rpb24gdG8gdGhlIG1p eCkuIERQSSBvciBIVFRQIA0KPj5Qcm94aWVzL0ZpbHRlcnMgZW5naW5lcyBhY3QgYXQgTDcuIFNl c3Npb24gQm9yZGVyIENvbnRyb2xsZXJzIGFjdCBhdCANCj4+TDcsIGFsdGhvdWdoIHRoZXkgZG8g c29tZSBMMy9MNCBwcm9jZXNzaW5nIHRvbyAoTkFUKS4gQWxsIHRob3NlIA0KPj52YXJpb3VzIGVs ZW1lbnRzIGhhdmUgdGhlaXIgb3duIHN0cmVuZ3RocyBpbiB0ZXJtcyBvZiB0cmFmZmljIA0KPj5j bGFzc2lmaWNhdGlvbiBhbmQgaW4gdGVybXMgb2YgcG9saWN5IGVuZm9yY2VtZW50LiBXaGljaCBj YW4gY29tYmluZWQgDQo+PmluIHNtYXJ0IHdheXMgKGUuZy4NCj4+dXNlIERQSSB0byBpZGVudGlm eS9jbGFzc2lmeSBhbiBhcHBsaWNhdGlvbiBmbG93LCB1c2UgYW4gZWRnZSByb3V0ZXIgDQo+PnRv IHBlcmZvcm0gZmFuY3kgcXVldWluZyBiYXNlZCBvbiBzdWNoIERQSSBjbGFzc2lmaWNhdGlvbiBh bW9uZyBvdGhlciANCj4+dHJhZmZpYyBmbG93cykuDQo+DQo+SmltPiB5ZXAuIA0KPg0KPj4gDQo+ Pg0KPj5UaGUgYmVhdXR5IG9mIHNlcnZpY2UgY2hhaW5pbmcgaXMgdG8gY29tYmluZSBhbGwgdGhv c2UgZWxlbWVudHMgdG8gDQo+Pm1ha2Ugc29tZXRoaW5nIHRydWx5IHVzZWZ1bCAoZS5nLiBwcm92 aWRlIGEgbW9yZSBjb21wbGV4IFNlcnZpY2UgLXdpdGggDQo+PmEgY2FwaXRhbCAnUyctIHRvIHNl cnZpY2UgcHJvdmlkZXIgdXNlcnMgb3IgZW50ZXJwcmlzZSB1c2VycykuIEFsbCB0aGUgDQo+PnVz ZSBjYXNlcyBJJ3ZlIGhlYXJkIHNvIGZhciBmcm9tIHZhcmlvdXMgcGFydGllcyBkbyBtaXggZWRn ZSByb3V0ZXJzLCANCj4+c2VjdXJpdHkgYW5kIGFwcGxpY2F0aW9uLW9yaWVudGVkIGVsZW1lbnRz Lg0KPj4NCj4+U28uLi4gSSB3b3VsZCBub3QgYmUgc3VwcG9ydGl2ZSB0byB0cnlpbmcgdG8gc2Vw YXJhdGUgYSBmb3JtIG9mIEwyL0wzIA0KPj5jaGFpbmluZyBmcm9tIGEgZm9ybSBvZiBMNC9MNyBj aGFpbmluZy4gT24gdGhlIGNvbnRyYXJ5ISA7LSkNCj4+DQo+Pkkgd291bGQgYWN0dWFsbHkgZ28g YXMgZmFyIGFzIHN1Z2dlc3RpbmcgdGhhdCB3ZSBzaG91bGQgbWFrZSBjbGVhcmVyIA0KPj5pbiB0 aGUgcHJvcG9zZWQgY2hhcnRlciB0aGF0IHRoaXMgaXMgYSBzdHJvbmcgZ29hbCwgdG8gZGVhbCB3 aXRoIHN1Y2ggDQo+PmhldGVyb2dlbmVvdXMgY29tYm9zLg0KPg0KPkppbT4gYW55IHRleHQgYW5k IHN1Z2dlc3Rpb24gb2Ygd2hlcmUgdG8gaW5zZXJ0IGludG8gdGhlIGNoYXJ0ZXI/DQo+DQo+Pg0K Pj5KdXN0IG15IDIgY2VudHMsDQo+Pkplcm9tZQ0KPj4NCj4+PT09PQ0KPj5Ub3RhbGx5IHVucmVs YXRlZCBQUyBmb3IgSmltOiB5b3UgZGlkbid0IGFuc3dlciBteSBxdWVzdGlvbiBhYm91dCB0aGUg DQo+PmNvbnRyb2wgcGxhbmUgYXNwZWN0cywgdGhpcyBtYXkgaGF2ZSBzbGlwcGVkIHRocm91Z2gg dGhlIGNyYWNrcyEgOy0pDQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9t OiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCj4+ U2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTMgNjo1MSBBTQ0KPj5UbzogUm9uIFBh cmtlcg0KPj5DYzogbnNjQGlldGYub3JnOyBUaG9tYXMgTmFkZWF1OyBUaG9tYXMgTmFydGVuOyBh ZHJpYW5Ab2xkZG9nLmNvLnVrOyANCj4+TGluZGEgRHVuYmFyOyBTdGV3YXJ0IEJyeWFudCAoc3Ri cnlhbnQpDQo+PlN1YmplY3Q6IFJlOiBbbnNjXSBOU0MgQm9GIE91dGNvbWVzDQo+Pg0KPj5UaGUg c2FtZSBhcmd1bWVudCBjb3VsZCBiZSBhcHBsaWVkIGZvciBmaXJld2FsbHMgYXMgd2l0aG91dCB0 aGVtIA0KPj5wYWNrZXRzIHdvdWxkIGdldCByb3V0ZWQgaW5zdGVhZCBvZiBwZXJoYXBzIGRyb3Bw ZWQuDQo+Pg0KPj5TZW50IGZyb20gbXkgaVBob25lDQo+Pg0KPj5PbiBTZXAgMywgMjAxMywgYXQg ODo0NSBQTSwgIlJvbiBQYXJrZXIiDQo+PjxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t PiB3cm90ZToNCj4+DQo+Pj4gSGksIExpbmRhLg0KPj4+IA0KPj4+IFdpdGggcmVzcGVjdCB0bzoN Cj4+PiANCj4+PiAgICAtIExheWVyIDQgdG8gTGF5ZXIgNyBzZXJ2aWNlIGZ1bmN0aW9ucyAob3Ig c2VydmljZSBub2RlcykgYXJlIHRvIA0KPj4+YXBwbHkgYWN0aW9ucyB0byBkYXRhIHBhY2tldHMg dHJhdmVyc2luZyB0aHJvdWdoLiBUaGV5IGRvbid0IGltcGFjdCANCj4+Pm92ZXJhbGwgbmV0d29y ayB0b3BvbG9naWVzL3JvdXRlcy9yZXN0b3JhdGlvbnMuDQo+Pj4gDQo+Pj4gTGF5ZXIgNC03IHNl cnZpY2VzIGNhbiwgaW5kZWVkLCBpbXBhY3Qgcm91dGluZyBkZWNpc2lvbnMuICBGb3IgDQo+Pj5l eGFtcGxlLCBpZiB0aGUgc2VydmljZSBpcyBEUEkgYW5hbHlzaXMsIHRoZW4gYSBkZXRlY3RlZCBw cm90b2NvbCBtYXkgDQo+Pj5jYXVzZSB0aGUgc3Vic2VxdWVudCBwYWNrZXRzIHRvIGJlIHBvbGlj eSByb3V0ZWQgb24gYSBwYXRoIGRpZmZlcmVudCANCj4+PnRoYW4gdGhlIFNQRiBwYXRoLg0KPj4+ IA0KPj4+ICAgUm9uDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgDQo+Pj4gT2YgTGluZGEgRHVuYmFyDQo+Pj4gU2VudDogVHVlc2RheSwg U2VwdGVtYmVyIDAzLCAyMDEzIDY6NDggUE0NCj4+PiBUbzogVGhvbWFzIE5hZGVhdQ0KPj4+IENj OiBuc2NAaWV0Zi5vcmc7IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBUaG9tYXMgTmFydGVuOyAN Cj4+PiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpDQo+Pj4g U3ViamVjdDogUmU6IFtuc2NdIE5TQyBCb0YgT3V0Y29tZXMNCj4+PiANCj4+PiBIZXJlIGFyZSBz b21lIG9mIHRoZSByZWFzb25zIHRoYXQgY2hhaW5pbmcgb2YgTGF5ZXIgMiBhbmQgMyBzZXJ2aWNl IA0KPj4+ZnVuY3Rpb25zIGFyZSBkaWZmZXJlbnQgZnJvbSBjaGFpbmluZyBvZiBMYXllciA0IHRv IDcgc2VydmljZSANCj4+PmZ1bmN0aW9ucyAoSSB3aWxsIGFkZCBtb3JlIGxhdGVyKToNCj4+PiAN Cj4+PiANCj4+PiAtIExheWVyIDQgdG8gTGF5ZXIgNyBzZXJ2aWNlIGZ1bmN0aW9ucyAob3Igc2Vy dmljZSBub2RlcykgYXJlIHRvIA0KPj4+YXBwbHkgYWN0aW9ucyB0byBkYXRhIHBhY2tldHMgdHJh dmVyc2luZyB0aHJvdWdoLiBUaGV5IGRvbid0IGltcGFjdCANCj4+Pm92ZXJhbGwgbmV0d29yayB0 b3BvbG9naWVzL3JvdXRlcy9yZXN0b3JhdGlvbnMuDQo+Pj4gDQo+Pj4gLSBMYXllciA0LTcgc2Vy dmljZSBmdW5jdGlvbnMgZHJvcCwgcGFzcywgY29uc3VtZSwgcmUtaW5pdGlhdGUgDQo+Pj5wYWNr ZXRzLCBldGMuIFRoZXkgZG9uJ3QgY2hhbmdlIG5ldHdvcmsgdG9wb2xvZ2llcywgYW5kIHRoZXkg ZG9uJ3QgDQo+Pj5pbXBhY3QgbmV0d29yayByZXN0b3JhdGlvbiBzY2hlbWUgKGUuZy4gZmFzdCBy ZS1yb3V0ZSkuICBXaGVuIHlvdSANCj4+Pm1vdmUgYSBMYXllciA0IHNlcnZpY2UgbW9kdWxlIGZy b20gTG9jYXRpb24gQSB0byBCLCB0aGUgTGF5ZXIgMi8zIA0KPj4+dG9wb2xvZ3kgaXMgbm90IGNo YW5nZWQsIHJvdXRlcy9yZXN0b3JhdGlvbiBhcmUgbm90IGNoYW5nZWQuDQo+Pj4gDQo+Pj4gLSBX aGVuIGNoYWluaW5nIExheWVyIDQgdG8gTGF5ZXIgNyBzZXJ2aWNlIGZ1bmN0aW9ucyB0b2dldGhl ciwgbGlrZQ0KPj4+UzEtPlMyLT5TMy0+UzQsIHRoZXkgYXJlIG92ZXJsYXlpbmcgb3ZlciB0aGUg dW5kZXJsYXkgbmV0d29yay4NCj4+PiANCj4+PiAtICBMYXllciAyIGFuZCBsYXllciAzIG5vZGVz IGhhdmUgY29udHJvbCBwbGFuZSAoZS5nLiBJR1AvQkdQKSB0byANCj4+PmR5bmFtaWNhbGx5IGRp c2NvdmVyIHRvcG9sb2d5OyBmb3J3YXJkaW5nIHBhdGhzOyBwcm90ZWN0aW9uIHBhdGhzOyANCj4+ PnJlc3RvcmF0aW9uIHBhdGhzLCBldGMuIFRvZGF5LCBhbGwgcm91dGVycyBhcmUgY29ubmVjdGVk IHRvZ2V0aGVyIGJ5IA0KPj4+bGlua3MuIFRoZWlyIHRvcG9sb2d5IGlzIG1vcmUgbGlrZSBhIG1l c2hlZCBncmFwaCB0aGFuIGNoYWluLiBTbyB3aGVuIA0KPj4+eW91IGNoYWluIFJvdXRlci0xPC0+ Um91dGVyLTI8LT5Sb3V0ZXItMywgYXJlIHlvdSB0YWxraW5nIGFib3V0IA0KPj4+c291cmNlIHJv dXRpbmc/IFRoZXJlZm9yZSwgbmVlZCBhIGNsZWFyIGRlZmluaXRpb24gb24gd2hhdCBkb2VzIGl0 IA0KPj4+cmVhbGx5IG1lYW4gYnkgY2hhaW5pbmcgTGF5ZXIgMi8zIHNlcnZpY2Ugbm9kZXMuDQo+ Pj4gDQo+Pj4gTGluZGENCj4+PiANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4gRnJvbTogVGhvbWFzIE5hZGVhdSBbbWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29tXQ0K Pj4+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDMsIDIwMTMgNToyOCBQTQ0KPj4+PiBUbzog TGluZGEgRHVuYmFyDQo+Pj4+IENjOiBuc2NAaWV0Zi5vcmc7IEppbSBHdWljaGFyZCAoamd1aWNo YXIpOyBTdGV3YXJ0IEJyeWFudCANCj4+Pj4gKHN0YnJ5YW50KTsgVGhvbWFzIE5hcnRlbjsgYWRy aWFuQG9sZGRvZy5jby51aw0KPj4+PiBTdWJqZWN0OiBSZTogW25zY10gTlNDIEJvRiBPdXRjb21l cw0KPj4+PiANCj4+Pj4gDQo+Pj4+IE9uIFNlcCAzLCAyMDEzOjY6MjUgUE0sIGF0IDY6MjUgUE0s IExpbmRhIER1bmJhciANCj4+Pj4gPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPiB3cm90ZToNCj4+ Pj4gDQo+Pj4+PiBUaG9tYXMsDQo+Pj4+PiANCj4+Pj4+IEFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhl IE5TQyBzY29wZSBpbmNsdWRlcyBjaGFpbmluZyBMYXllciAyLCBMYXllcg0KPj4+Pj4gMw0KPj4+ PiBzZXJ2aWNlIGZ1bmN0aW9ucywgTGF5ZXIgNCB0byBMYXllciA3IHNlcnZpY2UgZnVuY3Rpb25z LCBhbmQgDQo+Pj4+IHZhcmlvdXMgY29tYmluYXRpb24gb2YgdGhlbT8NCj4+Pj4gDQo+Pj4+ICAg IEkgZG9uJ3QgZGVmaW5lIHRoZSBzY29wZTsgdGhhdHMgdXAgdG8gdGhlIEFEcy4NCj4+Pj4gDQo+ Pj4+ICAgIENvdWxkIHlvdSBwbGVhc2UgYW5zd2VyIHRoZSBxdWVzdGlvbiBiZWxvdz8NCj4+Pj4g DQo+Pj4+ICAgIC0tVG9tDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBMaW5kYQ0KPj4+Pj4gDQo+Pj4+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBGcm9tOiBUaG9tYXMgTmFkZWF1 IFttYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb21dDQo+Pj4+Pj4gU2VudDogVHVlc2RheSwg U2VwdGVtYmVyIDAzLCAyMDEzIDU6MTkgUE0NCj4+Pj4+PiBUbzogTGluZGEgRHVuYmFyDQo+Pj4+ Pj4gQ2M6IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBuc2NA aWV0Zi5vcmc7IA0KPj4+Pj4+IFRob21hcyBOYXJ0ZW47IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFu dCkNCj4+Pj4+PiBTdWJqZWN0OiBSZTogW25zY10gTlNDIEJvRiBPdXRjb21lcw0KPj4+Pj4+IA0K Pj4+Pj4+IA0KPj4+Pj4+IE9uIFNlcCAzLCAyMDEzOjU6NTQgUE0sIGF0IDU6NTQgUE0sIExpbmRh IER1bmJhciANCj4+Pj4+PiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4+Pj4+ IA0KPj4+Pj4+PiBNeSBjb21tZW50cyBhcmUgaW5zZXJ0ZWQgYmVsb3cgbWFya2VkIGJ5IFtMaW5k YV06DQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEhvd2V2ZXIsIGl0IHdhcyBsZXNzIGNsZWFyIHRv IG1lIHRoYXQgdGhlcmUgaXMgYWdyZWVtZW50IGFib3V0DQo+Pj4+IHRoZQ0KPj4+Pj4+Pj4gbGF5 ZXINCj4+Pj4+Pj4+PiBpbg0KPj4+Pj4+Pj4+IHdoaWNoIHNlcnZpY2UgY2hhaW5pbmcgaGFzIHRv IGJlIHNvbHZlZC4gSSBmZWx0IHRoYXQgc29tZSANCj4+Pj4+Pj4+PiBwZW9wbGUgd2VyZSB0YWxr aW5nIGFib3V0IHNlcnZpY2UgY2hhaW5pbmcgaW4gdGhlIGFwcGxpY2F0aW9uIA0KPj4+Pj4+Pj4+ IGxheWVyLA0KPj4+PiBzb21lDQo+Pj4+Pj4+Pj4gYWJvdXQgc2VydmljZSBjaGFpbmluZyBiYXNl ZCBvbiBmbG93cywgYW5kIHNvbWUgYWJvdXQgDQo+Pj4+Pj4+Pj4gcGVyLXBhY2tldCBzZXJ2aWNl cy4gVGhlIHNvbHV0aW9ucyBhcmUsDQo+Pj4+Pj4+PiBJDQo+Pj4+Pj4+Pj4gdGhpbmssDQo+Pj4+ Pj4+Pj4gbGlrZWx5IHRvIGJlIHZlcnkgZGlmZmVyZW50IGZvciB0aGUgZGlmZmVyZW50IHByb2Js ZW1zLCBhbmQgaXQNCj4+Pj4+PiB3b3VsZA0KPj4+Pj4+Pj4gYmUNCj4+Pj4+Pj4+PiB3cm9uZyB0 bw0KPj4+Pj4+Pj4+IHRyeSB0byBidW5jaCB0aGVtIGFsbCB0b2dldGhlci4NCj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4gSmltPiBhbHRob3VnaCB0aGVyZSB3YXMgY2VydGFpbmx5IGluaXRpYWwgY29uZnVz aW9uIEkgYmVsaWV2ZSANCj4+Pj4+Pj4+IEppbT4gdGhpcw0KPj4+Pj4+IGlzDQo+Pj4+Pj4+PiBi ZWNvbWluZyBsZXNzIGFuZCBsZXNzIHNvIGFzIHdlIHNvY2lhbGl6ZSB0aGUgYmFzaWMgaWRlYSBv Zg0KPj4+PiBzZXJ2aWNlDQo+Pj4+Pj4+PiBjaGFpbmluZzsgaW5kZWVkLCBhcyB3ZSBtb3ZlIGZv cndhcmQgd2Ugd2lsbCByZWZsZWN0IGEgbW9yZSANCj4+Pj4+Pj4+IGNvbW1vbiB1bmRlcnN0YW5k aW5nIHdpdGhpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJdCBp cyBzdGlsbCBub3QgY2xlYXIgd2hpY2ggbGF5ZXIgc2VydmljZSBmdW5jdGlvbnMgYXJlIGNoYWlu ZWQNCj4+Pj4+PiB0b2dldGhlci4gVGhlIGRyYWZ0LXF1aW5uLW5zYy1wcm9ibGVtLXN0YXRlbWVu dC0wMyBkaXNjdXNzZWQNCj4+Pj4gY2hhaW5pbmcNCj4+Pj4+PiBvZiBzZXJ2aWNlIGZ1bmN0aW9u cyB0aGF0IGNhbiBiZSBhIG5ldHdvcmsgb3IgYXBwbGljYXRpb24gYmFzZWQgDQo+Pj4+Pj4gcGFj a2V0IHRyZWF0bWVudCwuLi4sIHRvIGVuYWJsZSBhIHNlcnZpY2Ugb2ZmZXJlZCBieSBhIG5ldHdv cmsNCj4+Pj4gb3BlcmF0b3JzLg0KPj4+Pj4+IA0KPj4+Pj4+ICAgIFdoeSBkbyB5b3UgdGhpbmsg dGhhdCBtYXR0ZXJzPw0KPj4+Pj4+IA0KPj4+Pj4+PiBUb2RheSwgdGhlcmUgYXJlIG1hbnkgc2Vy dmljZXMgb2ZmZXJlZCBieSBvcGVyYXRvcnMsIGUuZy4gTDJWUE4sIA0KPj4+Pj4+PiBMM1ZQTiwg UDJQIHBhdGhzLCBldGMuIFNvIHlvdSBjYW4gaW50ZXJwcmV0IE5TQyBhcyBjaGFpbmluZyANCj4+ Pj4+Pj4gTDIvTDMNCj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucyAobGlrZSBwcm94eSBmb3J3YXJk aW5nLCBvciBmcmFnbWVudGF0aW9uLCANCj4+Pj4+PiBldGMuKTsgWW91IGNhbiBhbHNvIGludGVy cHJldCBOU0MgYXMgY2hhaW5pbmcgTDQgIChhbmQgYWJvdmUpIA0KPj4+Pj4+IHNlcnZpY2UgZnVu Y3Rpb25zOyBvciBjaGFpbmluZyBvZiBtaXhlZCBMNC1MNyBzZXJ2aWNlIGZ1bmN0aW9ucyANCj4+ Pj4+PiAoaS5lLiB3aXRoIHNvbWUgc2VydmljZSBub2RlcyBjb25zdW1pbmcgcGFja2V0cyBhbmQg cmVpbml0aWF0ZSBuZXcgcGFja2V0cykuDQo+Pj4+Pj4gDQo+Pj4+Pj4gICAgWW91IGNhbiwgYW5k IHBlb3BsZSBhY3R1YWxseSBkbyBpbXBsZW1lbnQgdGhpcyB0b2RheS4NCj4+Pj4+PiANCj4+Pj4+ Pj4gSXMgTlNDIGluY2x1ZGluZyBhbGwgY2hhaW5pbmcgb2YgYWxsIHRob3NlIHNlcnZpY2VzPw0K Pj4+Pj4+PiANCj4+Pj4+Pj4gTGF5ZXIgMi8zIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgbWln aHQgcmVxdWlyZSBkaWZmZXJlbnQgDQo+Pj4+Pj4+IHNjaGVtZXMNCj4+Pj4+PiB0aGFuIExheWVy IDQtNyBzZXJ2aWNlIGNoYWluaW5nLiBUaGVyZWZvcmUsIGl0IGlzIG1vcmUgZWZmZWN0aXZlIA0K Pj4+Pj4+IHRvIGRlZmluZSB0aGVtIHNlcGFyYXRlbHkgdG8gbWFrZSB0aGUgZGlzY3Vzc2lvbiBt b3JlIGZvY3VzZWQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gICAgSSBkbyBub3QgdGhpbmsgc28uIEknZCBw cmVmZXIgdG8gbm90IG1ha2UgdGhpcyBvbmx5IGFzDQo+Pj4+IGNvbXBsaWNhdGVkDQo+Pj4+Pj4g YXMgaXQgbmVlZHMgdG8gYmUsIGFuZCBubyBtb3JlLiBUaGVyZSBhcmUgaW1wbGVtZW50YXRpb25z IG9mIA0KPj4+Pj4+IExheWVyDQo+Pj4+Pj4gMiBhbmQgMyBjaGFpbmluZyB0aGF0IGFyZSBhbGwg ZG9uZSB3aXRoIHRoZSBzYW1lIA0KPj4+Pj4+IGVuY2FwL3Byb3Zpc2lvbmluZyBzeXN0ZW1zLg0K Pj4+Pj4+IA0KPj4+Pj4+ICAgIC0tVG9tDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+ Pj4+PiBMaW5kYSBEdW5iYXINCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+PiBuc2MgbWFp bGluZyBsaXN0DQo+Pj4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+ Pj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbnNjDQo+Pj4+PiANCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+PiBuc2NAaWV0 Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+ Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4gbnNjQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+DQo+Pg0KPg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbnNjIG1haWxpbmcgbGlzdA0KbnNj QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4KVGhhbmsgeW91LgoK From jguichar@cisco.com Wed Sep 4 09:07: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 8AB6421E80B7 for ; Wed, 4 Sep 2013 09:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 whp4m1zLv2qp for ; Wed, 4 Sep 2013 09:07:21 -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 A7E2F21F9F26 for ; Wed, 4 Sep 2013 09:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12840; q=dns/txt; s=iport; t=1378310841; x=1379520441; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=vMYsCoytDPuVHIFRGwWRPrdX23NSO7Z1b+yC3arKcJY=; b=OX6XXcYuHOlPZb/NJpnEqa7sA/cDC8flReZQlP4P9eSkJhfhDAOzBHSB 9hnZBP4ZzQ9De+qhMB+GIoU+acOz/jaGmu4YPwIa+zsZIyM1LNzt980i7 VCQFvlkFBYrCYlfLVCr7tRbIhWZLDtdhyq/n3S6f6RXDL6s/l+VUaNNTK I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FADVaJ1KtJXHA/2dsb2JhbABagkNENVHBPIEnFnSCJAEBAQQtXgEIEQMBAgsdORQJCAIEARIIh3q5eY4XgRggGAaDF4EAA6lbgyCBcTk X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208,217";a="255514820" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 04 Sep 2013 16:06:47 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r84G6kkw021860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 16:06:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 11:06:47 -0500 From: "Jim Guichard (jguichar)" To: "christian.jacquenet@orange.com" , "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1pL9ggAAo6AD///Ct8IAAEnCA Date: Wed, 4 Sep 2013 16:06:46 +0000 Message-ID: <68B171751455884590F8E38E96416F363F675579@xmb-rcd-x01.cisco.com> In-Reply-To: <17590_1378310565_522759A5_17590_277_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64784@PUEXCB1C.nanterre.francetelecom.fr> 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.86.241.24] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F675579xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 16:07:27 -0000 --_000_68B171751455884590F8E38E96416F363F675579xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Christian, How about "For example, shared information, such as the results of a classi= fication function, may be passed to downstream service functions to enable = the offloading of service function processing or to share information that = would otherwise be hard to glean" - does that work? From: "christian.jacquenet@orange.com" > Date: Wednesday, September 4, 2013 12:02 PM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: NSC Working Group Charter Proposal Hello Jim, Thanks for the clarification. [snip] Jim> no. This last sentence basically means that a service function might p= erform a specific action, the result of which may be useful to one or more = service functions further down the chain. The example given is classificati= on; the results of this classification might be passed to a downstream serv= ice function so that it need not perform said classification again but rath= er glean the results of the initial classification from the upstream servic= e function. Given this do you have any suggested text changes to make this = clearer? [CJ] I guess I would use your explanation as the illustrative sentence: =93= For example, the results of a classification might be passed to a downstrea= m function=85=94 Cheers, Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_68B171751455884590F8E38E96416F363F675579xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6B7763E9619D434791EA5E0DA472C607@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Christian,

How about "For example,= shared information, such = as the results of a classification function, may be passed to downstream se= rvice functions to enable the offloading of service function processing or to share information that would otherwis= e be hard to glean" - does that work?

From: "christian.jacquenet@orange.com" <christian.jacquenet@orange.c= om>
Date: Wednesday, September 4, 2013 = 12:02 PM
To: Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: NSC Working Group Char= ter Proposal

Hello Jim,

 

Thanks for the clarification.

[snip]

Jim> no. Th= is last sentence basically means that a service function might perform a sp= ecific action, the result of which may be useful to one or more service functions further down the chain. The exampl= e given is classification; the results of this classification might be pass= ed to a downstream service function so that it need not perform said classi= fication again but rather glean the results of the initial classification from the upstream service functi= on. Given this do you have any suggested text changes to make this clearer?=

[CJ] I guess I would use your explanatio= n as the illustrative sentence: =93For example, the results of a classifica= tion might be passed to a downstream function=85=94

 

Cheers,

 

Christian.

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_68B171751455884590F8E38E96416F363F675579xmbrcdx01ciscoc_-- From christian.jacquenet@orange.com Wed Sep 4 09:08: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 DD88321F90A7 for ; Wed, 4 Sep 2013 09:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzzY-HKxrN-3 for ; Wed, 4 Sep 2013 09:07:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE2E21F8C93 for ; Wed, 4 Sep 2013 09:07:55 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 39D37191830; Wed, 4 Sep 2013 18:07:54 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 1B3F71800D9; Wed, 4 Sep 2013 18:07:54 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 4 Sep 2013 18:07:53 +0200 From: To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Date: Wed, 4 Sep 2013 18:07:52 +0200 Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1pL9ggAAo6AD///Ct8IAAEnCA///vgeA= Message-ID: <506_1378310874_52275ADA_506_310_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F6478B@PUEXCB1C.nanterre.francetelecom.fr> References: <17590_1378310565_522759A5_17590_277_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64784@PUEXCB1C.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F675579@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F675579@xmb-rcd-x01.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F6478BPUEXCB1Cnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 16:08:01 -0000 --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F6478BPUEXCB1Cnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes - thanks. Cheers, Christian. De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mercredi 4 septembre 2013 18:07 =C0 : JACQUENET Christian IMT/OLN; nsc@ietf.org Objet : Re: NSC Working Group Charter Proposal Hi Christian, How about "For example, shared information, such as the results of a classi= fication function, may be passed to downstream service functions to enable = the offloading of service function processing or to share information that = would otherwise be hard to glean" - does that work? From: "christian.jacquenet@orange.com" > Date: Wednesday, September 4, 2013 12:02 PM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: NSC Working Group Charter Proposal Hello Jim, Thanks for the clarification. [snip] Jim> no. This last sentence basically means that a service function might p= erform a specific action, the result of which may be useful to one or more = service functions further down the chain. The example given is classificati= on; the results of this classification might be passed to a downstream serv= ice function so that it need not perform said classification again but rath= er glean the results of the initial classification from the upstream servic= e function. Given this do you have any suggested text changes to make this = clearer? [CJ] I guess I would use your explanation as the illustrative sentence: "Fo= r example, the results of a classification might be passed to a downstream = function..." Cheers, Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F6478BPUEXCB1Cnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes – thanks= .

 

Cheers,

 

Christian.

 

De : Jim Guichard (jgui= char) [mailto:jguichar@cisco.com]
Envoy=E9 : mercredi 4 sep= tembre 2013 18:07
=C0 : JACQUENET Christian IMT/OLN; nsc@iet= f.org
Objet : Re: NSC Working Group Charter Proposal

 

Hi Christian,

 

How about "For example, shared information, such as the results of a classificati= on function, may be passed to downstream service functions to enable the of= floading of service function processing or to share information that would = otherwise be hard to glean" - does that work?=

=  

 

= He= llo Jim,

 

Thanks for the clarification.

[snip]

Jim> no. This last senten= ce basically means that a service function might perform a specific action,= the result of which may be useful to one or more service functions further= down the chain. The example given is classification; the results of this c= lassification might be passed to a downstream service function so that it n= eed not perform said classification again but rather glean the results of t= he initial classification from the upstream service function. Given this do= you have any suggested text changes to make this clearer?

[CJ] I guess I would use your explanation as the illustrative = sentence: “For example, the results of a classification might be pass= ed to a downstream function…”

&nbs= p;

Cheers,<= o:p>

 =

Christian.=

 

______=
___________________________________________________________________________=
________________________________________
 
Ce mes=
sage et ses pieces jointes peuvent contenir des informations confidentielle=
s ou privilegiees et ne doivent donc
pas etre diffuses, exploites=
 ou copies sans autorisation. Si vous avez recu ce message par erreur, veui=
llez le signaler
<=
span style=3D'color:black'>a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, defo=
rme ou falsifie. Merci.
 
This message and its at=
tachments may contain confidential or privileged information that may be pr=
otected by law;
they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, pl=
ease notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
Thank you.
________________________________________________=
_________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F6478BPUEXCB1Cnante_-- From kgray@juniper.net Wed Sep 4 09:15: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 001D121E80FD for ; Wed, 4 Sep 2013 09:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_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 OpFwTgmhzDnE for ; Wed, 4 Sep 2013 09:15:30 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id D0AB221E80B7 for ; Wed, 4 Sep 2013 09:15:26 -0700 (PDT) Received: from mail205-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE040.bigfish.com (10.243.66.105) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 16:15:23 +0000 Received: from mail205-co1 (localhost [127.0.0.1]) by mail205-co1-R.bigfish.com (Postfix) with ESMTP id 8BDE5D800DD; Wed, 4 Sep 2013 16:15:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -74 X-BigFish: VPS-74(zzbb2dI98dI9371Ic89bh936eI1454I148cI542I1432I15caKJa706lzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail205-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(377454003)(377424004)(52604005)(51704005)(24454002)(13464003)(52044002)(189002)(199002)(55784002)(80976001)(79102001)(76786001)(76796001)(77096001)(56816003)(83506001)(46102001)(74366001)(63696002)(36756003)(76176001)(80022001)(47976001)(50986001)(47736001)(77982001)(59766001)(54356001)(81542001)(65816001)(31966008)(56776001)(74662001)(51856001)(15975445006)(54316002)(81342001)(47446002)(76482001)(74502001)(69226001)(15202345003)(81686001)(83072001)(74706001)(74876001)(19580405001)(4396001)(49866001)(19580395003)(53806001)(83322001)(81816001)(427584002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB083; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail205-co1 (localhost.localdomain [127.0.0.1]) by mail205-co1 (MessageSwitch) id 13783113211420_1423; Wed, 4 Sep 2013 16:15:20 +0000 (UTC) Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.236]) by mail205-co1.bigfish.com (Postfix) with ESMTP id ED1CD5C0041; Wed, 4 Sep 2013 16:15:20 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 16:15:18 +0000 Received: from BL2PR05MB083.namprd05.prod.outlook.com (10.255.232.26) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 4 Sep 2013 16:15:03 +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.745.25; Wed, 4 Sep 2013 16:15:02 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 16:15:02 +0000 From: Ken Gray To: Ron Parker , "mohamed.boucadair@orange.com" , "nsc@ietf.org" Thread-Topic: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt Thread-Index: Ac6fMhIAzIOqddliRk+cqJ/CnVKw9ADv8zVgAZrASQAACgW9EP//xs+A Date: Wed, 4 Sep 2013 16:15:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 095972DF2F Content-Type: text/plain; charset="iso-8859-1" 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% Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.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, 04 Sep 2013 16:15:40 -0000 We're bouncing around my point, though you actually bring up an ancillary thing of interest.=20 Assuming that an element performs multiple functions (either as multiple virtual machines or as part of it's physical/logical architecture as a non-virtual device), then there is an interesting question about how we represent this in service discovery - particularly if we cannot manipulate the order or isolate an order (that's the part I think is new and interesting in your response). I think we're agreeing that the work of the NSC workgroup will ignore the mechanics of such chaining as implementation details and thus not describe how they are chained - keeping us out of the IPC/RPC bailywick and focusing only on the description of/standardization of externally chained services (though, as I mentioned above, representation of that combined service IS relevant to NSC work). Yes? If so, we should make this clear in #2? On 9/4/13 11:47 AM, "Ron Parker" wrote: >Hi, Ken. > >Responding to your comment on REQ #2, from my perspective... > >A particular network element (physical or virtual) can definitely support >multiple service functions simultaneously. Any particular chain may >invoke any of them in any order. However, I feel that it is an >implementation specific design issue whether hops between these >co-resident services literally follow the exact service chaining >procedures that we ultimately define or simply behave as if they were >exactly followed (i.e., external-service A to internal-service B to >internal-service C to external-service D -- only the external A to >internal B and the internal C to external D are externally observable). > > Ron > > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ken >Gray >Sent: Wednesday, September 04, 2013 10:53 AM >To: mohamed.boucadair@orange.com; nsc@ietf.org >Subject: Re: [nsc] TR: I-D Action: >draft-boucadair-chaining-requirements-01.txt > >Heya, Med. > >I gave it a quick read. I have the following questions/observations: > >REQ#2 - The document doesn't specifically say whether we're constraining >our focus on chains that require an "externality" for each link (that is, >ARE we assuming that each "link" will pass through a network/networked >element e.g. Hypervisor switch) - and are thus excluding from discussion >IPC (or RPC) mechanisms between service elements on the same device >(which are much harder to detect, monitor, standardize). > >REQ#13 is putting a constraint on the header discussion. Is this the >right place to put that, particularly since the requirements there >haven't been fully defined (yet)? > >REQ#15 - while I fully appreciate your desire to avoid another 80+ part >email thread on whether MPLS is an overlay, I think you make your point >well enough in the main assertion and part "b" is actually redundant. 8^) > >REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22 has >to be a MUST (I think the need for downstream reclassification can be a >normal outcome of the function of an individual service element as it >potentially transforms a header - unless your argument is that we should >avoid this wherever possible by imbedding a clue in the header - in which >case we run into issues with "non-speakers" or legacy devices). > >REQ#23 seems to obviate the use of simple route NH manipulation to create >a chain (this is destination address based). So, to be inclusive, I >think that has to be a SHOULD. > >REQ#25 seems to be difficult to require if you don't dictate how the >chain is formed (how the forwarding is instantiated) and should be worded >more like REQ#29, IMO. > >REQ#30 I think you're trying to say that static definition/topology of >service functions SHOULD be supported but dynamic MUST (not that every >element has to support dynamic discovery but that the overall goal of the >ongoing architecture should be dynamic with static augmentation for >corner/legacy cases) ...which would be more in alignment with the tenor >of REQ#32. > >Thanks for kicking it off and reading this drivel ... > > > > > > >On 8/27/13 2:58 AM, "mohamed.boucadair@orange.com" > wrote: > >>Dear all, >> >>A new version of the requirements draft is now available online. The >>main changes in this new version are as follows: >> >>* Enrich the document with inputs from >>draft-li-service-chaining-requirements >>* Welcome authors of draft-li-service-chaining-requirements as >>co-authors >>* Add new security-related requirements. >>* Re-order the requirements >> >>A more detailed diff is available at: >>http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirement >>s-0 >>1.txt >> >>Feel free to share your comments, suggestions and text contributions on >>the list or direct them to the authors. >> >>Cheers, >>Med >> >>-----Message d'origine----- >>De : i-d-announce-bounces@ietf.org >>[mailto:i-d-announce-bounces@ietf.org] >>De la part de internet-drafts@ietf.org >>Envoy=E9 : jeudi 22 ao=FBt 2013 14:21 >>=C0 : i-d-announce@ietf.org >>Objet : I-D Action: draft-boucadair-chaining-requirements-01.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : Requirements for Service Function Chaining >> Author(s) : Mohamed Boucadair >> Christian Jacquenet >> Yuanlong Jiang >> Hongyu Li >> Ron Parker >> Filename : draft-boucadair-chaining-requirements-01.txt >> Pages : 10 >> Date : 2013-08-22 >> >>Abstract: >> This document identifies the requirements for the Service Function >> Chaining. >> >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirements >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-boucadair-chaining-requirements-01 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirements- >>01 >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html or >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>_______________________________________________ >>nsc mailing 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 Sep 4 09:17: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 AF85821E80E8 for ; Wed, 4 Sep 2013 09:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[AWL=0.201, 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 6oXsVJ0XDDfO for ; Wed, 4 Sep 2013 09:17:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B552221E80C9 for ; Wed, 4 Sep 2013 09:17:16 -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.5-GA FastPath queued) with ESMTP id AWX15125; Wed, 04 Sep 2013 16:17:15 +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; Wed, 4 Sep 2013 17:16:55 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 17:17:11 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 09:17:07 -0700 From: Linda Dunbar To: Ron Parker , Thomas Nadeau Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqOMaexl2TK45oEebqJb9MjX0ypm0iPEwgACBtAD//4uI4IAAdwmA//+LeYCAAJr/AIAAjMgA Date: Wed, 4 Sep 2013 16:17:07 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9D19E@dfweml509-mbx.china.huawei.com> References: <03bd01ce9817$346a3b10$9d3eb130$@olddog.co.uk> <68B171751455884590F8E38E96416F363F672CBC@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C8F1@dfweml509-mbx.china.huawei.com> <85C48C97-5F2D-4159-997E-A572E996D886@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C961@dfweml509-mbx.china.huawei.com> <5F1E64BA-FA49-489B-982F-BAFF64FD9CC9@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645B9C99F@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.192.11.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Stewart Bryant \(stbryant\)" , "adrian@olddog.co.uk" , Thomas Narten Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 16:17:22 -0000 Ron,=20 My comments are inserted below:=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Tuesday, September 03, 2013 7:46 PM > To: Linda Dunbar; Thomas Nadeau > Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; > adrian@olddog.co.uk; Stewart Bryant (stbryant) > Subject: RE: [nsc] NSC BoF Outcomes >=20 > Hi, Linda. >=20 > With respect to: >=20 > - Layer 4 to Layer 7 service functions (or service nodes) are to > apply actions to data packets traversing through. They don't impact > overall network topologies/routes/restorations. >=20 > Layer 4-7 services can, indeed, impact routing decisions. For example, > if the service is DPI analysis, then a detected protocol may cause the > subsequent packets to be policy routed on a path different than the SPF > path. [Linda] Do you call this "DPI" function that re-direct data frames to a dif= ferent target (that is not the Destination of the data frame) "Layer 3" ser= vice? When those "DPI" functions re-direct traffic, do they add another Destinati= on address to the data frames (i.e. create a tunnel)? Or do they not touch = the destination addresses in the existing data frames and expect all the no= des along the way to know how to forward the data frames?=20 Bottom line, those services need to be distinguished from traditional Laye= r 3 services, and be distinguished from routers/switches that dynamically e= stablish topology, establish routes, and restoration paths.=20 =20 =20 Linda >=20 > Ron >=20 >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Linda Dunbar > Sent: Tuesday, September 03, 2013 6:48 PM > To: Thomas Nadeau > Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; > adrian@olddog.co.uk; Stewart Bryant (stbryant) > Subject: Re: [nsc] NSC BoF Outcomes >=20 > Here are some of the reasons that chaining of Layer 2 and 3 service > functions are different from chaining of Layer 4 to 7 service functions > (I will add more later): >=20 >=20 > - Layer 4 to Layer 7 service functions (or service nodes) are to apply > actions to data packets traversing through. They don't impact overall > network topologies/routes/restorations. >=20 > - Layer 4-7 service functions drop, pass, consume, re-initiate packets, > etc. They don't change network topologies, and they don't impact > network restoration scheme (e.g. fast re-route). When you move a Layer > 4 service module from Location A to B, the Layer 2/3 topology is not > changed, routes/restoration are not changed. >=20 > - When chaining Layer 4 to Layer 7 service functions together, like S1- > >S2->S3->S4, they are overlaying over the underlay network. >=20 > - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to > dynamically discover topology; forwarding paths; protection paths; > restoration paths, etc. Today, all routers are connected together by > links. Their topology is more like a meshed graph than chain. So when > you chain Router-1<->Router-2<->Router-3, are you talking about source > routing? Therefore, need a clear definition on what does it really mean > by chaining Layer 2/3 service nodes. >=20 > Linda >=20 > > -----Original Message----- > > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > > Sent: Tuesday, September 03, 2013 5:28 PM > > To: Linda Dunbar > > Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant (stbryant); > > Thomas Narten; adrian@olddog.co.uk > > Subject: Re: [nsc] NSC BoF Outcomes > > > > > > On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar > > wrote: > > > > > Thomas, > > > > > > Are you saying that the NSC scope includes chaining Layer 2, Layer > 3 > > service functions, Layer 4 to Layer 7 service functions, and various > > combination of them? > > > > I don't define the scope; thats up to the ADs. > > > > Could you please answer the question below? > > > > --Tom > > > > > > > > Linda > > > > > >> -----Original Message----- > > >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > > >> Sent: Tuesday, September 03, 2013 5:19 PM > > >> To: Linda Dunbar > > >> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org; > > >> Thomas Narten; Stewart Bryant (stbryant) > > >> Subject: Re: [nsc] NSC BoF Outcomes > > >> > > >> > > >> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar > > >> wrote: > > >> > > >>> My comments are inserted below marked by [Linda]: > > >>> > > >>>> -----Original Message----- > > >>>> > > >>>>> > > >>>>> However, it was less clear to me that there is agreement about > > the > > >>>> layer > > >>>>> in > > >>>>> which service chaining has to be solved. I felt that some > people > > >>>>> were talking about service chaining in the application layer, > > some > > >>>>> about service chaining based on flows, and some about per- > packet > > >>>>> services. The solutions are, > > >>>> I > > >>>>> think, > > >>>>> likely to be very different for the different problems, and it > > >> would > > >>>> be > > >>>>> wrong to > > >>>>> try to bunch them all together. > > >>>> > > >>>> Jim> although there was certainly initial confusion I believe > > >>>> Jim> this > > >> is > > >>>> becoming less and less so as we socialize the basic idea of > > service > > >>>> chaining; indeed, as we move forward we will reflect a more > > >>>> common understanding within the problem statement. > > >>> > > >>> It is still not clear which layer service functions are chained > > >> together. The draft-quinn-nsc-problem-statement-03 discussed > > chaining > > >> of service functions that can be a network or application based > > >> packet treatment,..., to enable a service offered by a network > > operators. > > >> > > >> Why do you think that matters? > > >> > > >>> Today, there are many services offered by operators, e.g. L2VPN, > > >>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 > > >> service functions (like proxy forwarding, or fragmentation, etc.); > > >> You can also interpret NSC as chaining L4 (and above) service > > >> functions; or chaining of mixed L4-L7 service functions (i.e. with > > >> some service nodes consuming packets and reinitiate new packets). > > >> > > >> You can, and people actually do implement this today. > > >> > > >>> Is NSC including all chaining of all those services? > > >>> > > >>> Layer 2/3 service function chaining might require different > > >>> schemes > > >> than Layer 4-7 service chaining. Therefore, it is more effective > to > > >> define them separately to make the discussion more focused. > > >> > > >> I do not think so. I'd prefer to not make this only as > > complicated > > >> as it needs to be, and no more. There are implementations of Layer > > >> 2 and 3 chaining that are all done with the same > encap/provisioning > > >> systems. > > >> > > >> --Tom > > >> > > >> > > >>> > > >>> Linda Dunbar > > >>> > > >>>> > > >>>> _______________________________________________ > > >>>> nsc mailing list > > >>>> nsc@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/nsc > > >>> _______________________________________________ > > >>> nsc mailing list > > >>> nsc@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/nsc > > >>> > > > > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc > > > >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From jmoisand@juniper.net Wed Sep 4 09:18:45 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305AF21E80E4 for ; Wed, 4 Sep 2013 09:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 1-8d++bHXmsr for ; Wed, 4 Sep 2013 09:18:40 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id B5E3111E80DE for ; Wed, 4 Sep 2013 09:18:39 -0700 (PDT) Received: from mail19-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 16:18:38 +0000 Received: from mail19-ch1 (localhost [127.0.0.1]) by mail19-ch1-R.bigfish.com (Postfix) with ESMTP id 664302E0073; Wed, 4 Sep 2013 16:18:38 +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: -73 X-BigFish: VPS-73(zzbb2dI98dI9371Ic89bh542I1432I15caKJzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail19-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:(24454002)(51704005)(189002)(199002)(13464003)(55784002)(377454003)(479174003)(31966008)(80976001)(74316001)(74876001)(56816003)(19580405001)(54356001)(83322001)(19580395003)(53806001)(47446002)(74502001)(74662001)(77982001)(77096001)(59766001)(83072001)(54316002)(56776001)(76482001)(33646001)(66066001)(81816001)(69226001)(63696002)(51856001)(81686001)(81342001)(65816001)(80022001)(74706001)(15975445006)(74366001)(47976001)(81542001)(76576001)(50986001)(49866001)(79102001)(47736001)(76796001)(46102001)(76786001)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB252; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail19-ch1 (localhost.localdomain [127.0.0.1]) by mail19-ch1 (MessageSwitch) id 137831151428821_1658; Wed, 4 Sep 2013 16:18:34 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail19-ch1.bigfish.com (Postfix) with ESMTP id 01EB4601B3; Wed, 4 Sep 2013 16:18:34 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 16:18:33 +0000 Received: from BN1PR05MB252.namprd05.prod.outlook.com (10.255.206.12) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 4 Sep 2013 16:18:33 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BN1PR05MB252.namprd05.prod.outlook.com (10.255.206.12) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 4 Sep 2013 16:18:32 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.242]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.242]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 16:18:31 +0000 From: Jerome Moisand To: "christian.jacquenet@orange.com" , "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqVy6Z9mmIGq2k0KPvTqkQ6aemJm1lc+wgAAKbICAABbVAIAABPkAgAACEoCAAALS4A== Date: Wed, 4 Sep 2013 16:18:30 +0000 Message-ID: <22e3d4546f5140e8a7ac9ff20246c143@BN1PR05MB251.namprd05.prod.outlook.com> References: <68B171751455884590F8E38E96416F363F6754BE@xmb-rcd-x01.cisco.com> <1152_1378310663_52275A07_1152_6102_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64788@PUEXCB1C.nanterre.francetelecom.fr> In-Reply-To: <1152_1378310663_52275A07_1152_6102_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F64788@PUEXCB1C.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 095972DF2F Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nsc@ietf.org" , Thomas Nadeau , Thomas Narten , "adrian@olddog.co.uk" , Linda Dunbar , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 16:18:45 -0000 SSB3b3VsZCB0ZW5kIHRvIGFncmVlIHdpdGggQ2hyaXN0aWFuLCByZXF1aXJlbWVudHMgc2hvdWxk IGJlIGFib3V0IHRoZSBvdmVyYWxsIHByb2JsZW0gdG8gc29sdmUuIFBsdXMgYSBjb250cm9sIHBs YW5lIHRlbmRzIHRvIGNvbnRyb2wuLi4gdGhlIGRhdGEgcGxhbmUhIFNvIGJldHRlciB3b3JrIG9u IHJlcXVpcmVtZW50cyB3aGljaCB3b3VsZCBiZSBjb25zaXN0ZW50IGVub3VnaCB0byBhY2tub3ds ZWRnZSBzdWNoIHJlbGF0aW9uc2hpcC4NCg0KTm93LCBJIGFsc28gYWdyZWUgd2l0aCBSb24gdGhh dCBhIGNvbnRyb2wgcGxhbmUgbWF5IG5vdCBiZSByZXF1aXJlZCBpbiBhbGwgY2FzZXMuIFRoaXMg c2hvdWxkIHByb2JhYmx5IGJlIGEgcmVxdWlyZW1lbnQsIGFjdHVhbGx5LCB0byBub3QgbWFuZGF0 ZSBhIGNvbnRyb2wgcGxhbmUgaW4gYWxsIGNhc2VzISANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGNocmlzdGlhbi5qYWNxdWVuZXRAb3JhbmdlLmNvbSBbbWFpbHRvOmNocmlz dGlhbi5qYWNxdWVuZXRAb3JhbmdlLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAw NCwgMjAxMyAxMjowNCBQTQ0KVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBSb24gUGFya2Vy OyBKZXJvbWUgTW9pc2FuZA0KQ2M6IG5zY0BpZXRmLm9yZzsgVGhvbWFzIE5hZGVhdTsgTGluZGEg RHVuYmFyOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBUaG9tYXMgTmFydGVuOyBTdGV3YXJ0IEJyeWFu dCAoc3RicnlhbnQpDQpTdWJqZWN0OiBSRTogW25zY10gTlNDIEJvRiBPdXRjb21lcw0KDQpIaSos DQoNCkkgc3VwcG9ydCB0aGUgcHVibGljYXRpb24gb2YgYSBzaW5nbGUgcmVxdWlyZW1lbnRzIGRv Y3VtZW50IChmb3IgdGhlIHNha2Ugb2YgY29uc2lzdGVuY3kpLCBhbmQgd2hpY2ggd291bGQgaW5j bHVkZSBib3RoIGNvbnRyb2wgYW5kIGRhdGEgcGxhbmUgY29uc2lkZXJhdGlvbnMgYW1vbmcgb3Ro ZXIgdG9waWNzLg0KDQpDaGVlcnMsDQoNCkNocmlzdGlhbi4NCg0KLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQpEZcKgOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEppbSBHdWljaGFyZCAoamd1aWNoYXIpIEVudm95w6nC oDogbWVyY3JlZGkgNCBzZXB0ZW1icmUgMjAxMyAxNzo1NyDDgMKgOiBSb24gUGFya2VyOyBKZXJv bWUgTW9pc2FuZCBDY8KgOiBuc2NAaWV0Zi5vcmc7IFRob21hcyBOYWRlYXU7IExpbmRhIER1bmJh cjsgYWRyaWFuQG9sZGRvZy5jby51azsgVGhvbWFzIE5hcnRlbjsgU3Rld2FydCBCcnlhbnQgKHN0 YnJ5YW50KSBPYmpldMKgOiBSZTogW25zY10gTlNDIEJvRiBPdXRjb21lcw0KDQpJcyB0aGUgc3Vn Z2VzdGlvbiB0aGVyZWZvcmUgdGhhdCBzZXBhcmF0ZSBkYXRhIGFuZCBjb250cm9sIHBsYW5lIHJl cXVpcmVtZW50cyBJLUQncyBzaG91bGQgYmUgY3JlYXRlZCByYXRoZXIgdGhhbiBhbiBvdmVyYWxs IHJlcXVpcmVtZW50cyBkb2N1bWVudCBjb3ZlcmluZyBib3RoPw0KDQpPbiA5LzQvMTMgMTE6Mzkg QU0sICJSb24gUGFya2VyIiA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4gd3JvdGU6 DQoNCj5KaW0sDQo+DQo+SSBhZ3JlZSB0aGF0IHRoZSBjaGFydGVyIHNob3VsZCBub3QgYmUgdG9v IHNwZWNpZmljIG9uIHRoZSBkZXNpZ24gb2YgDQo+dGhlIGNvbnRyb2wgcGxhbmUsIGJ1dCByYXRo ZXIgdG8gcmVjb2duaXplIHRoYXQgb25lIGNvdWxkIGJlIA0KPmFkdmFudGFnZW91cyAoYWx0aG91 Z2ggbm90IG5lY2Vzc2FyaWx5IHJlcXVpcmVkKSBmb3IgdGhlIG92ZXJhbGwgc2VydmljZSBjaGFp bmluZw0KPnNvbHV0aW9uLiAgICBBIGNvbnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzIGFuZC9vciB1 c2UgY2FzZXMgZG9jdW1lbnQNCj5zaG91bGQgcHJlY2VkZSBhbnkgY29udHJvbCBwbGFuZSBwcm90 b2NvbCBkZXNpZ24gb3Igc2VsZWN0aW9uLg0KPg0KPiAgIFJvbg0KPg0KPg0KPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpq Z3VpY2hhckBjaXNjby5jb21dDQo+U2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTMg MTA6MTcgQU0NCj5UbzogSmVyb21lIE1vaXNhbmQ7IFJvbiBQYXJrZXINCj5DYzogbnNjQGlldGYu b3JnOyBUaG9tYXMgTmFkZWF1OyBUaG9tYXMgTmFydGVuOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyAN Cj5MaW5kYSBEdW5iYXI7IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFudCkNCj5TdWJqZWN0OiBSZTog W25zY10gTlNDIEJvRiBPdXRjb21lcw0KPg0KPkhpIEplcm9tZSwNCj4NCj5NeSBiYWQgLi4gUmVz cG9uZGluZyB0byB5b3VyIFBTIDspIMWgIFJpZ2h0IG5vdyB0aGUgY2hhcnRlciBzdWdnZXN0cyAN Cj50aGF0IHRoZSBXRyBiZSByZXNwb25zaWJsZSBmb3IgZGVmaW5pbmcgdGhlIHJlcXVpcmVtZW50 cyBvZiB0aGUgY29udHJvbCANCj5wbGFuZSB3aXRoIHJlc3BlY3QgdG8gc2VydmljZSBjaGFpbmlu Zy4gVGhlIHByb2JsZW0gaGVyZSBpcyBvZiBjb3Vyc2UgDQo+dGhhdCB0aGVyZSBhcmUgbXVsdGlw bGUgY29udHJvbCBwbGFuZXMuIEluIG15IG1pbmQgaXQgbWFrZXMgbGl0dGxlIA0KPnNlbnNlIHRv IHRyeSBhbmQgdGFja2xlIHRoZW0gYWxsIGJ1dCByYXRoZXIgZGVmaW5lIHdoYXQgaXMgbmVjZXNz YXJ5IA0KPmZvciBhIGNvbnRyb2wgcGxhbmUgdG8gaW1wbGVtZW50IHRvIHN1Y2Nlc3NmdWxseSBl bmFibGUgc2VydmljZSBjaGFpbnMgDQo+YW5kIHRoZW4gbGlhaXNlIHdpdGggb3RoZXIgV0cncyBv biB0aGUgZGV0YWlscy4NCj4NCj5Tb21lIGZ1cnRoZXIgY29tbWVudHMgaW5saW5lLg0KPg0KPk9u IDkvNC8xMyA5OjU1IEFNLCAiSmVyb21lIE1vaXNhbmQiIDxqbW9pc2FuZEBqdW5pcGVyLm5ldD4g d3JvdGU6DQo+DQo+Pkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGVudGlyZSBwb2ludCBvZiBzZXJ2 aWNlIGNoYWluaW5nIGlzIGluZGVlZCB0byANCj4+Y2hhaW4gdG9nZXRoZXIgaGV0ZXJvZ2VuZW91 cyBzZXJ2aWNlLWVuYWJsaW5nIGVsZW1lbnRzLCBhbmQgbWFrZSB0aGUgDQo+PmJlc3Qgb3V0IG9m IHN1Y2ggY29tYm8uDQo+DQo+SmltPiBleGFjdGx5LiBUaGUgcG9pbnQgYmVpbmcgc2VwYXJhdGUg c2VydmljZSBmdW5jdGlvbnMgaW50byBhIA0KPkppbT4gcmVzb3VyY2UNCj5wb29sIHRoYXQgY2Fu IGJlIHV0aWxpemVkIGFuZCBub3QgY29uc3RyYWluZWQgYmFzZWQgb24gdG9wb2xvZ3kuDQo+DQo+ PiANCj4+DQo+PlNlcnZpY2UgRWRnZSByb3V0ZXJzIChpbmNsdWRpbmcgQml6LVBFcywgQk5HcyBh bmQgTW9iaWxlIEdXcykgZW5hYmxlDQo+PkwzIHNlcnZpY2VzLCBvbiBhIHBlciBzdWJzY3JpYmVy IGJhc2lzLiBGaXJld2FsbHMgY2FuIGFjdCBlaXRoZXIgYXQNCj4+TDMvTDQgb3INCj4+TDQvTDcg KGUuZy4gYWRkaW5nIHNvbWUgSW50cnVzaW9uIERldGVjdGlvbiB0byB0aGUgbWl4KS4gRFBJIG9y IEhUVFAgDQo+PlByb3hpZXMvRmlsdGVycyBlbmdpbmVzIGFjdCBhdCBMNy4gU2Vzc2lvbiBCb3Jk ZXIgQ29udHJvbGxlcnMgYWN0IGF0IA0KPj5MNywgYWx0aG91Z2ggdGhleSBkbyBzb21lIEwzL0w0 IHByb2Nlc3NpbmcgdG9vIChOQVQpLiBBbGwgdGhvc2UgDQo+PnZhcmlvdXMgZWxlbWVudHMgaGF2 ZSB0aGVpciBvd24gc3RyZW5ndGhzIGluIHRlcm1zIG9mIHRyYWZmaWMgDQo+PmNsYXNzaWZpY2F0 aW9uIGFuZCBpbiB0ZXJtcyBvZiBwb2xpY3kgZW5mb3JjZW1lbnQuIFdoaWNoIGNhbiBjb21iaW5l ZCANCj4+aW4gc21hcnQgd2F5cyAoZS5nLg0KPj51c2UgRFBJIHRvIGlkZW50aWZ5L2NsYXNzaWZ5 IGFuIGFwcGxpY2F0aW9uIGZsb3csIHVzZSBhbiBlZGdlIHJvdXRlciANCj4+dG8gcGVyZm9ybSBm YW5jeSBxdWV1aW5nIGJhc2VkIG9uIHN1Y2ggRFBJIGNsYXNzaWZpY2F0aW9uIGFtb25nIG90aGVy IA0KPj50cmFmZmljIGZsb3dzKS4NCj4NCj5KaW0+IHllcC4gDQo+DQo+PiANCj4+DQo+PlRoZSBi ZWF1dHkgb2Ygc2VydmljZSBjaGFpbmluZyBpcyB0byBjb21iaW5lIGFsbCB0aG9zZSBlbGVtZW50 cyB0byANCj4+bWFrZSBzb21ldGhpbmcgdHJ1bHkgdXNlZnVsIChlLmcuIHByb3ZpZGUgYSBtb3Jl IGNvbXBsZXggU2VydmljZSAtd2l0aCANCj4+YSBjYXBpdGFsICdTJy0gdG8gc2VydmljZSBwcm92 aWRlciB1c2VycyBvciBlbnRlcnByaXNlIHVzZXJzKS4gQWxsIHRoZSANCj4+dXNlIGNhc2VzIEkn dmUgaGVhcmQgc28gZmFyIGZyb20gdmFyaW91cyBwYXJ0aWVzIGRvIG1peCBlZGdlIHJvdXRlcnMs IA0KPj5zZWN1cml0eSBhbmQgYXBwbGljYXRpb24tb3JpZW50ZWQgZWxlbWVudHMuDQo+Pg0KPj5T by4uLiBJIHdvdWxkIG5vdCBiZSBzdXBwb3J0aXZlIHRvIHRyeWluZyB0byBzZXBhcmF0ZSBhIGZv cm0gb2YgTDIvTDMgDQo+PmNoYWluaW5nIGZyb20gYSBmb3JtIG9mIEw0L0w3IGNoYWluaW5nLiBP biB0aGUgY29udHJhcnkhIDstKQ0KPj4NCj4+SSB3b3VsZCBhY3R1YWxseSBnbyBhcyBmYXIgYXMg c3VnZ2VzdGluZyB0aGF0IHdlIHNob3VsZCBtYWtlIGNsZWFyZXIgDQo+PmluIHRoZSBwcm9wb3Nl ZCBjaGFydGVyIHRoYXQgdGhpcyBpcyBhIHN0cm9uZyBnb2FsLCB0byBkZWFsIHdpdGggc3VjaCAN Cj4+aGV0ZXJvZ2VuZW91cyBjb21ib3MuDQo+DQo+SmltPiBhbnkgdGV4dCBhbmQgc3VnZ2VzdGlv biBvZiB3aGVyZSB0byBpbnNlcnQgaW50byB0aGUgY2hhcnRlcj8NCj4NCj4+DQo+Pkp1c3QgbXkg MiBjZW50cywNCj4+SmVyb21lDQo+Pg0KPj49PT09DQo+PlRvdGFsbHkgdW5yZWxhdGVkIFBTIGZv ciBKaW06IHlvdSBkaWRuJ3QgYW5zd2VyIG15IHF1ZXN0aW9uIGFib3V0IHRoZSANCj4+Y29udHJv bCBwbGFuZSBhc3BlY3RzLCB0aGlzIG1heSBoYXZlIHNsaXBwZWQgdGhyb3VnaCB0aGUgY3JhY2tz ISA7LSkNCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IEppbSBHdWlj aGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0KPj5TZW50OiBXZWRu ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMyA2OjUxIEFNDQo+PlRvOiBSb24gUGFya2VyDQo+PkNj OiBuc2NAaWV0Zi5vcmc7IFRob21hcyBOYWRlYXU7IFRob21hcyBOYXJ0ZW47IGFkcmlhbkBvbGRk b2cuY28udWs7IA0KPj5MaW5kYSBEdW5iYXI7IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFudCkNCj4+ U3ViamVjdDogUmU6IFtuc2NdIE5TQyBCb0YgT3V0Y29tZXMNCj4+DQo+PlRoZSBzYW1lIGFyZ3Vt ZW50IGNvdWxkIGJlIGFwcGxpZWQgZm9yIGZpcmV3YWxscyBhcyB3aXRob3V0IHRoZW0gDQo+PnBh Y2tldHMgd291bGQgZ2V0IHJvdXRlZCBpbnN0ZWFkIG9mIHBlcmhhcHMgZHJvcHBlZC4NCj4+DQo+ PlNlbnQgZnJvbSBteSBpUGhvbmUNCj4+DQo+Pk9uIFNlcCAzLCAyMDEzLCBhdCA4OjQ1IFBNLCAi Um9uIFBhcmtlciINCj4+PFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+IHdyb3RlOg0K Pj4NCj4+PiBIaSwgTGluZGEuDQo+Pj4gDQo+Pj4gV2l0aCByZXNwZWN0IHRvOg0KPj4+IA0KPj4+ ICAgIC0gTGF5ZXIgNCB0byBMYXllciA3IHNlcnZpY2UgZnVuY3Rpb25zIChvciBzZXJ2aWNlIG5v ZGVzKSBhcmUgdG8gDQo+Pj5hcHBseSBhY3Rpb25zIHRvIGRhdGEgcGFja2V0cyB0cmF2ZXJzaW5n IHRocm91Z2guIFRoZXkgZG9uJ3QgaW1wYWN0IA0KPj4+b3ZlcmFsbCBuZXR3b3JrIHRvcG9sb2dp ZXMvcm91dGVzL3Jlc3RvcmF0aW9ucy4NCj4+PiANCj4+PiBMYXllciA0LTcgc2VydmljZXMgY2Fu LCBpbmRlZWQsIGltcGFjdCByb3V0aW5nIGRlY2lzaW9ucy4gIEZvciANCj4+PmV4YW1wbGUsIGlm IHRoZSBzZXJ2aWNlIGlzIERQSSBhbmFseXNpcywgdGhlbiBhIGRldGVjdGVkIHByb3RvY29sIG1h eSANCj4+PmNhdXNlIHRoZSBzdWJzZXF1ZW50IHBhY2tldHMgdG8gYmUgcG9saWN5IHJvdXRlZCBv biBhIHBhdGggZGlmZmVyZW50IA0KPj4+dGhhbiB0aGUgU1BGIHBhdGguDQo+Pj4gDQo+Pj4gICBS b24NCj4+PiANCj4+PiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206 IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiANCj4+PiBPZiBMaW5kYSBEdW5iYXINCj4+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIg MDMsIDIwMTMgNjo0OCBQTQ0KPj4+IFRvOiBUaG9tYXMgTmFkZWF1DQo+Pj4gQ2M6IG5zY0BpZXRm Lm9yZzsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IFRob21hcyBOYXJ0ZW47IA0KPj4+IGFkcmlh bkBvbGRkb2cuY28udWs7IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFudCkNCj4+PiBTdWJqZWN0OiBS ZTogW25zY10gTlNDIEJvRiBPdXRjb21lcw0KPj4+IA0KPj4+IEhlcmUgYXJlIHNvbWUgb2YgdGhl IHJlYXNvbnMgdGhhdCBjaGFpbmluZyBvZiBMYXllciAyIGFuZCAzIHNlcnZpY2UgDQo+Pj5mdW5j dGlvbnMgYXJlIGRpZmZlcmVudCBmcm9tIGNoYWluaW5nIG9mIExheWVyIDQgdG8gNyBzZXJ2aWNl IA0KPj4+ZnVuY3Rpb25zIChJIHdpbGwgYWRkIG1vcmUgbGF0ZXIpOg0KPj4+IA0KPj4+IA0KPj4+ IC0gTGF5ZXIgNCB0byBMYXllciA3IHNlcnZpY2UgZnVuY3Rpb25zIChvciBzZXJ2aWNlIG5vZGVz KSBhcmUgdG8gDQo+Pj5hcHBseSBhY3Rpb25zIHRvIGRhdGEgcGFja2V0cyB0cmF2ZXJzaW5nIHRo cm91Z2guIFRoZXkgZG9uJ3QgaW1wYWN0IA0KPj4+b3ZlcmFsbCBuZXR3b3JrIHRvcG9sb2dpZXMv cm91dGVzL3Jlc3RvcmF0aW9ucy4NCj4+PiANCj4+PiAtIExheWVyIDQtNyBzZXJ2aWNlIGZ1bmN0 aW9ucyBkcm9wLCBwYXNzLCBjb25zdW1lLCByZS1pbml0aWF0ZSANCj4+PnBhY2tldHMsIGV0Yy4g VGhleSBkb24ndCBjaGFuZ2UgbmV0d29yayB0b3BvbG9naWVzLCBhbmQgdGhleSBkb24ndCANCj4+ PmltcGFjdCBuZXR3b3JrIHJlc3RvcmF0aW9uIHNjaGVtZSAoZS5nLiBmYXN0IHJlLXJvdXRlKS4g IFdoZW4geW91IA0KPj4+bW92ZSBhIExheWVyIDQgc2VydmljZSBtb2R1bGUgZnJvbSBMb2NhdGlv biBBIHRvIEIsIHRoZSBMYXllciAyLzMgDQo+Pj50b3BvbG9neSBpcyBub3QgY2hhbmdlZCwgcm91 dGVzL3Jlc3RvcmF0aW9uIGFyZSBub3QgY2hhbmdlZC4NCj4+PiANCj4+PiAtIFdoZW4gY2hhaW5p bmcgTGF5ZXIgNCB0byBMYXllciA3IHNlcnZpY2UgZnVuY3Rpb25zIHRvZ2V0aGVyLCBsaWtlDQo+ Pj5TMS0+UzItPlMzLT5TNCwgdGhleSBhcmUgb3ZlcmxheWluZyBvdmVyIHRoZSB1bmRlcmxheSBu ZXR3b3JrLg0KPj4+IA0KPj4+IC0gIExheWVyIDIgYW5kIGxheWVyIDMgbm9kZXMgaGF2ZSBjb250 cm9sIHBsYW5lIChlLmcuIElHUC9CR1ApIHRvIA0KPj4+ZHluYW1pY2FsbHkgZGlzY292ZXIgdG9w b2xvZ3k7IGZvcndhcmRpbmcgcGF0aHM7IHByb3RlY3Rpb24gcGF0aHM7IA0KPj4+cmVzdG9yYXRp b24gcGF0aHMsIGV0Yy4gVG9kYXksIGFsbCByb3V0ZXJzIGFyZSBjb25uZWN0ZWQgdG9nZXRoZXIg YnkgDQo+Pj5saW5rcy4gVGhlaXIgdG9wb2xvZ3kgaXMgbW9yZSBsaWtlIGEgbWVzaGVkIGdyYXBo IHRoYW4gY2hhaW4uIFNvIHdoZW4gDQo+Pj55b3UgY2hhaW4gUm91dGVyLTE8LT5Sb3V0ZXItMjwt PlJvdXRlci0zLCBhcmUgeW91IHRhbGtpbmcgYWJvdXQgDQo+Pj5zb3VyY2Ugcm91dGluZz8gVGhl cmVmb3JlLCBuZWVkIGEgY2xlYXIgZGVmaW5pdGlvbiBvbiB3aGF0IGRvZXMgaXQgDQo+Pj5yZWFs bHkgbWVhbiBieSBjaGFpbmluZyBMYXllciAyLzMgc2VydmljZSBub2Rlcy4NCj4+PiANCj4+PiBM aW5kYQ0KPj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBU aG9tYXMgTmFkZWF1IFttYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb21dDQo+Pj4+IFNlbnQ6 IFR1ZXNkYXksIFNlcHRlbWJlciAwMywgMjAxMyA1OjI4IFBNDQo+Pj4+IFRvOiBMaW5kYSBEdW5i YXINCj4+Pj4gQ2M6IG5zY0BpZXRmLm9yZzsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IFN0ZXdh cnQgQnJ5YW50IA0KPj4+PiAoc3RicnlhbnQpOyBUaG9tYXMgTmFydGVuOyBhZHJpYW5Ab2xkZG9n LmNvLnVrDQo+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBOU0MgQm9GIE91dGNvbWVzDQo+Pj4+IA0K Pj4+PiANCj4+Pj4gT24gU2VwIDMsIDIwMTM6NjoyNSBQTSwgYXQgNjoyNSBQTSwgTGluZGEgRHVu YmFyIA0KPj4+PiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4+ IFRob21hcywNCj4+Pj4+IA0KPj4+Pj4gQXJlIHlvdSBzYXlpbmcgdGhhdCB0aGUgTlNDIHNjb3Bl IGluY2x1ZGVzIGNoYWluaW5nIExheWVyIDIsIExheWVyDQo+Pj4+PiAzDQo+Pj4+IHNlcnZpY2Ug ZnVuY3Rpb25zLCBMYXllciA0IHRvIExheWVyIDcgc2VydmljZSBmdW5jdGlvbnMsIGFuZCANCj4+ Pj4gdmFyaW91cyBjb21iaW5hdGlvbiBvZiB0aGVtPw0KPj4+PiANCj4+Pj4gICAgSSBkb24ndCBk ZWZpbmUgdGhlIHNjb3BlOyB0aGF0cyB1cCB0byB0aGUgQURzLg0KPj4+PiANCj4+Pj4gICAgQ291 bGQgeW91IHBsZWFzZSBhbnN3ZXIgdGhlIHF1ZXN0aW9uIGJlbG93Pw0KPj4+PiANCj4+Pj4gICAg LS1Ub20NCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IExpbmRhDQo+Pj4+PiANCj4+Pj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IFRob21hcyBOYWRlYXUgW21haWx0bzp0 bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbV0NCj4+Pj4+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIg MDMsIDIwMTMgNToxOSBQTQ0KPj4+Pj4+IFRvOiBMaW5kYSBEdW5iYXINCj4+Pj4+PiBDYzogSmlt IEd1aWNoYXJkIChqZ3VpY2hhcik7IGFkcmlhbkBvbGRkb2cuY28udWs7IG5zY0BpZXRmLm9yZzsg DQo+Pj4+Pj4gVGhvbWFzIE5hcnRlbjsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KQ0KPj4+Pj4+ IFN1YmplY3Q6IFJlOiBbbnNjXSBOU0MgQm9GIE91dGNvbWVzDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+ Pj4+Pj4gT24gU2VwIDMsIDIwMTM6NTo1NCBQTSwgYXQgNTo1NCBQTSwgTGluZGEgRHVuYmFyIA0K Pj4+Pj4+IDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4+ IE15IGNvbW1lbnRzIGFyZSBpbnNlcnRlZCBiZWxvdyBtYXJrZWQgYnkgW0xpbmRhXToNCj4+Pj4+ Pj4gDQo+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gSG93ZXZlciwgaXQgd2FzIGxlc3MgY2xlYXIgdG8gbWUgdGhhdCB0 aGVyZSBpcyBhZ3JlZW1lbnQgYWJvdXQNCj4+Pj4gdGhlDQo+Pj4+Pj4+PiBsYXllcg0KPj4+Pj4+ Pj4+IGluDQo+Pj4+Pj4+Pj4gd2hpY2ggc2VydmljZSBjaGFpbmluZyBoYXMgdG8gYmUgc29sdmVk LiBJIGZlbHQgdGhhdCBzb21lIA0KPj4+Pj4+Pj4+IHBlb3BsZSB3ZXJlIHRhbGtpbmcgYWJvdXQg c2VydmljZSBjaGFpbmluZyBpbiB0aGUgYXBwbGljYXRpb24gDQo+Pj4+Pj4+Pj4gbGF5ZXIsDQo+ Pj4+IHNvbWUNCj4+Pj4+Pj4+PiBhYm91dCBzZXJ2aWNlIGNoYWluaW5nIGJhc2VkIG9uIGZsb3dz LCBhbmQgc29tZSBhYm91dCANCj4+Pj4+Pj4+PiBwZXItcGFja2V0IHNlcnZpY2VzLiBUaGUgc29s dXRpb25zIGFyZSwNCj4+Pj4+Pj4+IEkNCj4+Pj4+Pj4+PiB0aGluaywNCj4+Pj4+Pj4+PiBsaWtl bHkgdG8gYmUgdmVyeSBkaWZmZXJlbnQgZm9yIHRoZSBkaWZmZXJlbnQgcHJvYmxlbXMsIGFuZCBp dA0KPj4+Pj4+IHdvdWxkDQo+Pj4+Pj4+PiBiZQ0KPj4+Pj4+Pj4+IHdyb25nIHRvDQo+Pj4+Pj4+ Pj4gdHJ5IHRvIGJ1bmNoIHRoZW0gYWxsIHRvZ2V0aGVyLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBK aW0+IGFsdGhvdWdoIHRoZXJlIHdhcyBjZXJ0YWlubHkgaW5pdGlhbCBjb25mdXNpb24gSSBiZWxp ZXZlIA0KPj4+Pj4+Pj4gSmltPiB0aGlzDQo+Pj4+Pj4gaXMNCj4+Pj4+Pj4+IGJlY29taW5nIGxl c3MgYW5kIGxlc3Mgc28gYXMgd2Ugc29jaWFsaXplIHRoZSBiYXNpYyBpZGVhIG9mDQo+Pj4+IHNl cnZpY2UNCj4+Pj4+Pj4+IGNoYWluaW5nOyBpbmRlZWQsIGFzIHdlIG1vdmUgZm9yd2FyZCB3ZSB3 aWxsIHJlZmxlY3QgYSBtb3JlIA0KPj4+Pj4+Pj4gY29tbW9uIHVuZGVyc3RhbmRpbmcgd2l0aGlu IHRoZSBwcm9ibGVtIHN0YXRlbWVudC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEl0IGlzIHN0aWxsIG5v dCBjbGVhciB3aGljaCBsYXllciBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgY2hhaW5lZA0KPj4+Pj4+ IHRvZ2V0aGVyLiBUaGUgZHJhZnQtcXVpbm4tbnNjLXByb2JsZW0tc3RhdGVtZW50LTAzIGRpc2N1 c3NlZA0KPj4+PiBjaGFpbmluZw0KPj4+Pj4+IG9mIHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgY2Fu IGJlIGEgbmV0d29yayBvciBhcHBsaWNhdGlvbiBiYXNlZCANCj4+Pj4+PiBwYWNrZXQgdHJlYXRt ZW50LC4uLiwgdG8gZW5hYmxlIGEgc2VydmljZSBvZmZlcmVkIGJ5IGEgbmV0d29yaw0KPj4+PiBv cGVyYXRvcnMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gICAgV2h5IGRvIHlvdSB0aGluayB0aGF0IG1hdHRl cnM/DQo+Pj4+Pj4gDQo+Pj4+Pj4+IFRvZGF5LCB0aGVyZSBhcmUgbWFueSBzZXJ2aWNlcyBvZmZl cmVkIGJ5IG9wZXJhdG9ycywgZS5nLiBMMlZQTiwgDQo+Pj4+Pj4+IEwzVlBOLCBQMlAgcGF0aHMs IGV0Yy4gU28geW91IGNhbiBpbnRlcnByZXQgTlNDIGFzIGNoYWluaW5nDQo+Pj4+Pj4+IEwyL0wz DQo+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMgKGxpa2UgcHJveHkgZm9yd2FyZGluZywgb3IgZnJh Z21lbnRhdGlvbiwgDQo+Pj4+Pj4gZXRjLik7IFlvdSBjYW4gYWxzbyBpbnRlcnByZXQgTlNDIGFz IGNoYWluaW5nIEw0ICAoYW5kIGFib3ZlKSANCj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9uczsgb3Ig Y2hhaW5pbmcgb2YgbWl4ZWQgTDQtTDcgc2VydmljZSBmdW5jdGlvbnMgDQo+Pj4+Pj4gKGkuZS4g d2l0aCBzb21lIHNlcnZpY2Ugbm9kZXMgY29uc3VtaW5nIHBhY2tldHMgYW5kIHJlaW5pdGlhdGUg bmV3IHBhY2tldHMpLg0KPj4+Pj4+IA0KPj4+Pj4+ICAgIFlvdSBjYW4sIGFuZCBwZW9wbGUgYWN0 dWFsbHkgZG8gaW1wbGVtZW50IHRoaXMgdG9kYXkuDQo+Pj4+Pj4gDQo+Pj4+Pj4+IElzIE5TQyBp bmNsdWRpbmcgYWxsIGNoYWluaW5nIG9mIGFsbCB0aG9zZSBzZXJ2aWNlcz8NCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IExheWVyIDIvMyBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIG1pZ2h0IHJlcXVpcmUg ZGlmZmVyZW50IA0KPj4+Pj4+PiBzY2hlbWVzDQo+Pj4+Pj4gdGhhbiBMYXllciA0LTcgc2Vydmlj ZSBjaGFpbmluZy4gVGhlcmVmb3JlLCBpdCBpcyBtb3JlIGVmZmVjdGl2ZSANCj4+Pj4+PiB0byBk ZWZpbmUgdGhlbSBzZXBhcmF0ZWx5IHRvIG1ha2UgdGhlIGRpc2N1c3Npb24gbW9yZSBmb2N1c2Vk Lg0KPj4+Pj4+IA0KPj4+Pj4+ICAgIEkgZG8gbm90IHRoaW5rIHNvLiBJJ2QgcHJlZmVyIHRvIG5v dCBtYWtlIHRoaXMgb25seSBhcw0KPj4+PiBjb21wbGljYXRlZA0KPj4+Pj4+IGFzIGl0IG5lZWRz IHRvIGJlLCBhbmQgbm8gbW9yZS4gVGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyBvZiANCj4+Pj4+ PiBMYXllcg0KPj4+Pj4+IDIgYW5kIDMgY2hhaW5pbmcgdGhhdCBhcmUgYWxsIGRvbmUgd2l0aCB0 aGUgc2FtZSANCj4+Pj4+PiBlbmNhcC9wcm92aXNpb25pbmcgc3lzdGVtcy4NCj4+Pj4+PiANCj4+ Pj4+PiAgICAtLVRvbQ0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gTGluZGEg RHVuYmFyDQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0K Pj4+Pj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25zYw0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IG5zY0Bp ZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25z Yw0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4+IA0KPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbnNjIG1h aWxpbmcgbGlzdA0KPj4+IG5zY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbnNjDQo+Pg0KPj4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCm5zYyBtYWlsaW5nIGxpc3QNCm5zY0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KVGhhbmsgeW91Lg0KDQo= From jguichar@cisco.com Wed Sep 4 10:20:02 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE5321E80EF for ; Wed, 4 Sep 2013 10:20:02 -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.300, 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 lvc7qD9B9E7M for ; Wed, 4 Sep 2013 10:19:57 -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 80D7611E80F3 for ; Wed, 4 Sep 2013 10:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19230; q=dns/txt; s=iport; t=1378315197; x=1379524797; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qTenqHdU6otIkmp/p6LQzvm85sxsIB0wMJChsZtA2UA=; b=DZ4lBamtPxKoQixpreQfn2cT8m+9T26FeySoh/+fBtdysT7IWKeQ4drU j1k8w2b2a9bNxK5pqO3R4MPECwEHSBiZCCpq+2RPln642JJ6cLXWWTCTf vsWYHS0OeNXuI0xdNRK7DjJbg1pIuSXcNnQwnonMClmI8HpLscTpWtWiP E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFABprJ1KtJXG8/2dsb2JhbABQCoMHNVGDKL4cF4ERFnSCJAEBAQQBAQEgBA06BAcMBgEIDgMEAQEBAgIGHQMCBCULFAEICAIEAQ0FCBOHZwyoKZF2BIEpjG4GgRIGEBsHAgICgmM0gQADqVuDIIFxOQ X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208";a="255592825" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 04 Sep 2013 17:19:56 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r84HJu38021438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 17:19:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 12:19:56 -0500 From: "Jim Guichard (jguichar)" To: Jerome Moisand , "christian.jacquenet@orange.com" , Ron Parker Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: Ac6YFyk/aYEs8EPbQVuX5dlVLbZ5nAQ1EMqAAAutBgAAANR+AAAAPryAAAATX4AAALROgAAEGq4AAAqrvDYAEOzoAP//wwOAgABZ5QD//8HmAIAADuoggAA6MAD//84YgA== Date: Wed, 4 Sep 2013 17:19:55 +0000 Message-ID: <68B171751455884590F8E38E96416F363F675803@xmb-rcd-x01.cisco.com> In-Reply-To: <22e3d4546f5140e8a7ac9ff20246c143@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.82.249.237] Content-Type: text/plain; charset="utf-8" Content-ID: <2AF0A53B62677049BCAFD6873445C879@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nsc@ietf.org" , Thomas Nadeau , Thomas Narten , "adrian@olddog.co.uk" , Linda Dunbar , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 17:20:02 -0000 TGV0IG1lIHN1Z2dlc3QgdGhhdCB3ZSBrZWVwIGEgc2luZ2xlIHJlcXVpcmVtZW50cyBkb2N1bWVu dCBmb3Igbm93IGFuZA0KcGVyaGFwcyBzcGxpdCBpbnRvIHNlcGFyYXRlIGRhdGEgYW5kIGNvbnRy b2wgcGxhbmUgZG9jdW1lbnRzIHNob3VsZCB0aGF0DQpiZWNvbWUgbmVjZXNzYXJ5IGFzIHRoZSBz aW5nbGUgZG9jdW1lbnQgZXZvbHZlcy4NCg0KT24gOS80LzEzIDEyOjE4IFBNLCAiSmVyb21lIE1v aXNhbmQiIDxqbW9pc2FuZEBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj5JIHdvdWxkIHRlbmQgdG8g YWdyZWUgd2l0aCBDaHJpc3RpYW4sIHJlcXVpcmVtZW50cyBzaG91bGQgYmUgYWJvdXQgdGhlDQo+ b3ZlcmFsbCBwcm9ibGVtIHRvIHNvbHZlLiBQbHVzIGEgY29udHJvbCBwbGFuZSB0ZW5kcyB0byBj b250cm9sLi4uIHRoZQ0KPmRhdGEgcGxhbmUhIFNvIGJldHRlciB3b3JrIG9uIHJlcXVpcmVtZW50 cyB3aGljaCB3b3VsZCBiZSBjb25zaXN0ZW50DQo+ZW5vdWdoIHRvIGFja25vd2xlZGdlIHN1Y2gg cmVsYXRpb25zaGlwLg0KPg0KPk5vdywgSSBhbHNvIGFncmVlIHdpdGggUm9uIHRoYXQgYSBjb250 cm9sIHBsYW5lIG1heSBub3QgYmUgcmVxdWlyZWQgaW4NCj5hbGwgY2FzZXMuIFRoaXMgc2hvdWxk IHByb2JhYmx5IGJlIGEgcmVxdWlyZW1lbnQsIGFjdHVhbGx5LCB0byBub3QNCj5tYW5kYXRlIGEg Y29udHJvbCBwbGFuZSBpbiBhbGwgY2FzZXMhDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj5Gcm9tOiBjaHJpc3RpYW4uamFjcXVlbmV0QG9yYW5nZS5jb20NCj5bbWFpbHRvOmNocmlz dGlhbi5qYWNxdWVuZXRAb3JhbmdlLmNvbV0NCj5TZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAw NCwgMjAxMyAxMjowNCBQTQ0KPlRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgUm9uIFBhcmtl cjsgSmVyb21lIE1vaXNhbmQNCj5DYzogbnNjQGlldGYub3JnOyBUaG9tYXMgTmFkZWF1OyBMaW5k YSBEdW5iYXI7IGFkcmlhbkBvbGRkb2cuY28udWs7DQo+VGhvbWFzIE5hcnRlbjsgU3Rld2FydCBC cnlhbnQgKHN0YnJ5YW50KQ0KPlN1YmplY3Q6IFJFOiBbbnNjXSBOU0MgQm9GIE91dGNvbWVzDQo+ DQo+SGkqLA0KPg0KPkkgc3VwcG9ydCB0aGUgcHVibGljYXRpb24gb2YgYSBzaW5nbGUgcmVxdWly ZW1lbnRzIGRvY3VtZW50IChmb3IgdGhlIHNha2UNCj5vZiBjb25zaXN0ZW5jeSksIGFuZCB3aGlj aCB3b3VsZCBpbmNsdWRlIGJvdGggY29udHJvbCBhbmQgZGF0YSBwbGFuZQ0KPmNvbnNpZGVyYXRp b25zIGFtb25nIG90aGVyIHRvcGljcy4NCj4NCj5DaGVlcnMsDQo+DQo+Q2hyaXN0aWFuLg0KPg0K Pi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPkRlIDogbnNjLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKaW0NCj5HdWljaGFy ZCAoamd1aWNoYXIpIEVudm95w6kgOiBtZXJjcmVkaSA0IHNlcHRlbWJyZSAyMDEzIDE3OjU3IMOA IDogUm9uDQo+UGFya2VyOyBKZXJvbWUgTW9pc2FuZCBDYyA6IG5zY0BpZXRmLm9yZzsgVGhvbWFz IE5hZGVhdTsgTGluZGEgRHVuYmFyOw0KPmFkcmlhbkBvbGRkb2cuY28udWs7IFRob21hcyBOYXJ0 ZW47IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFudCkgT2JqZXQgOiBSZToNCj5bbnNjXSBOU0MgQm9G IE91dGNvbWVzDQo+DQo+SXMgdGhlIHN1Z2dlc3Rpb24gdGhlcmVmb3JlIHRoYXQgc2VwYXJhdGUg ZGF0YSBhbmQgY29udHJvbCBwbGFuZQ0KPnJlcXVpcmVtZW50cyBJLUQncyBzaG91bGQgYmUgY3Jl YXRlZCByYXRoZXIgdGhhbiBhbiBvdmVyYWxsIHJlcXVpcmVtZW50cw0KPmRvY3VtZW50IGNvdmVy aW5nIGJvdGg/DQo+DQo+T24gOS80LzEzIDExOjM5IEFNLCAiUm9uIFBhcmtlciIgPFJvbl9QYXJr ZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+IHdyb3RlOg0KPg0KPj5KaW0sDQo+Pg0KPj5JIGFncmVl IHRoYXQgdGhlIGNoYXJ0ZXIgc2hvdWxkIG5vdCBiZSB0b28gc3BlY2lmaWMgb24gdGhlIGRlc2ln biBvZg0KPj50aGUgY29udHJvbCBwbGFuZSwgYnV0IHJhdGhlciB0byByZWNvZ25pemUgdGhhdCBv bmUgY291bGQgYmUNCj4+YWR2YW50YWdlb3VzIChhbHRob3VnaCBub3QgbmVjZXNzYXJpbHkgcmVx dWlyZWQpIGZvciB0aGUgb3ZlcmFsbCBzZXJ2aWNlDQo+PmNoYWluaW5nDQo+PnNvbHV0aW9uLiAg ICBBIGNvbnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzIGFuZC9vciB1c2UgY2FzZXMgZG9jdW1lbnQN Cj4+c2hvdWxkIHByZWNlZGUgYW55IGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wgZGVzaWduIG9yIHNl bGVjdGlvbi4NCj4+DQo+PiAgIFJvbg0KPj4NCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PkZyb206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lz Y28uY29tXQ0KPj5TZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMyAxMDoxNyBBTQ0K Pj5UbzogSmVyb21lIE1vaXNhbmQ7IFJvbiBQYXJrZXINCj4+Q2M6IG5zY0BpZXRmLm9yZzsgVGhv bWFzIE5hZGVhdTsgVGhvbWFzIE5hcnRlbjsgYWRyaWFuQG9sZGRvZy5jby51azsNCj4+TGluZGEg RHVuYmFyOyBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpDQo+PlN1YmplY3Q6IFJlOiBbbnNjXSBO U0MgQm9GIE91dGNvbWVzDQo+Pg0KPj5IaSBKZXJvbWUsDQo+Pg0KPj5NeSBiYWQgLi4gUmVzcG9u ZGluZyB0byB5b3VyIFBTIDspIMWgIFJpZ2h0IG5vdyB0aGUgY2hhcnRlciBzdWdnZXN0cw0KPj50 aGF0IHRoZSBXRyBiZSByZXNwb25zaWJsZSBmb3IgZGVmaW5pbmcgdGhlIHJlcXVpcmVtZW50cyBv ZiB0aGUgY29udHJvbA0KPj5wbGFuZSB3aXRoIHJlc3BlY3QgdG8gc2VydmljZSBjaGFpbmluZy4g VGhlIHByb2JsZW0gaGVyZSBpcyBvZiBjb3Vyc2UNCj4+dGhhdCB0aGVyZSBhcmUgbXVsdGlwbGUg Y29udHJvbCBwbGFuZXMuIEluIG15IG1pbmQgaXQgbWFrZXMgbGl0dGxlDQo+PnNlbnNlIHRvIHRy eSBhbmQgdGFja2xlIHRoZW0gYWxsIGJ1dCByYXRoZXIgZGVmaW5lIHdoYXQgaXMgbmVjZXNzYXJ5 DQo+PmZvciBhIGNvbnRyb2wgcGxhbmUgdG8gaW1wbGVtZW50IHRvIHN1Y2Nlc3NmdWxseSBlbmFi bGUgc2VydmljZSBjaGFpbnMNCj4+YW5kIHRoZW4gbGlhaXNlIHdpdGggb3RoZXIgV0cncyBvbiB0 aGUgZGV0YWlscy4NCj4+DQo+PlNvbWUgZnVydGhlciBjb21tZW50cyBpbmxpbmUuDQo+Pg0KPj5P biA5LzQvMTMgOTo1NSBBTSwgIkplcm9tZSBNb2lzYW5kIiA8am1vaXNhbmRAanVuaXBlci5uZXQ+ IHdyb3RlOg0KPj4NCj4+Pkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGVudGlyZSBwb2ludCBvZiBz ZXJ2aWNlIGNoYWluaW5nIGlzIGluZGVlZCB0bw0KPj4+Y2hhaW4gdG9nZXRoZXIgaGV0ZXJvZ2Vu ZW91cyBzZXJ2aWNlLWVuYWJsaW5nIGVsZW1lbnRzLCBhbmQgbWFrZSB0aGUNCj4+PmJlc3Qgb3V0 IG9mIHN1Y2ggY29tYm8uDQo+Pg0KPj5KaW0+IGV4YWN0bHkuIFRoZSBwb2ludCBiZWluZyBzZXBh cmF0ZSBzZXJ2aWNlIGZ1bmN0aW9ucyBpbnRvIGENCj4+SmltPiByZXNvdXJjZQ0KPj5wb29sIHRo YXQgY2FuIGJlIHV0aWxpemVkIGFuZCBub3QgY29uc3RyYWluZWQgYmFzZWQgb24gdG9wb2xvZ3ku DQo+Pg0KPj4+IA0KPj4+DQo+Pj5TZXJ2aWNlIEVkZ2Ugcm91dGVycyAoaW5jbHVkaW5nIEJpei1Q RXMsIEJOR3MgYW5kIE1vYmlsZSBHV3MpIGVuYWJsZQ0KPj4+TDMgc2VydmljZXMsIG9uIGEgcGVy IHN1YnNjcmliZXIgYmFzaXMuIEZpcmV3YWxscyBjYW4gYWN0IGVpdGhlciBhdA0KPj4+TDMvTDQg b3INCj4+Pkw0L0w3IChlLmcuIGFkZGluZyBzb21lIEludHJ1c2lvbiBEZXRlY3Rpb24gdG8gdGhl IG1peCkuIERQSSBvciBIVFRQDQo+Pj5Qcm94aWVzL0ZpbHRlcnMgZW5naW5lcyBhY3QgYXQgTDcu IFNlc3Npb24gQm9yZGVyIENvbnRyb2xsZXJzIGFjdCBhdA0KPj4+TDcsIGFsdGhvdWdoIHRoZXkg ZG8gc29tZSBMMy9MNCBwcm9jZXNzaW5nIHRvbyAoTkFUKS4gQWxsIHRob3NlDQo+Pj52YXJpb3Vz IGVsZW1lbnRzIGhhdmUgdGhlaXIgb3duIHN0cmVuZ3RocyBpbiB0ZXJtcyBvZiB0cmFmZmljDQo+ Pj5jbGFzc2lmaWNhdGlvbiBhbmQgaW4gdGVybXMgb2YgcG9saWN5IGVuZm9yY2VtZW50LiBXaGlj aCBjYW4gY29tYmluZWQNCj4+PmluIHNtYXJ0IHdheXMgKGUuZy4NCj4+PnVzZSBEUEkgdG8gaWRl bnRpZnkvY2xhc3NpZnkgYW4gYXBwbGljYXRpb24gZmxvdywgdXNlIGFuIGVkZ2Ugcm91dGVyDQo+ Pj50byBwZXJmb3JtIGZhbmN5IHF1ZXVpbmcgYmFzZWQgb24gc3VjaCBEUEkgY2xhc3NpZmljYXRp b24gYW1vbmcgb3RoZXINCj4+PnRyYWZmaWMgZmxvd3MpLg0KPj4NCj4+SmltPiB5ZXAuIA0KPj4N Cj4+PiANCj4+Pg0KPj4+VGhlIGJlYXV0eSBvZiBzZXJ2aWNlIGNoYWluaW5nIGlzIHRvIGNvbWJp bmUgYWxsIHRob3NlIGVsZW1lbnRzIHRvDQo+Pj5tYWtlIHNvbWV0aGluZyB0cnVseSB1c2VmdWwg KGUuZy4gcHJvdmlkZSBhIG1vcmUgY29tcGxleCBTZXJ2aWNlIC13aXRoDQo+Pj5hIGNhcGl0YWwg J1MnLSB0byBzZXJ2aWNlIHByb3ZpZGVyIHVzZXJzIG9yIGVudGVycHJpc2UgdXNlcnMpLiBBbGwg dGhlDQo+Pj51c2UgY2FzZXMgSSd2ZSBoZWFyZCBzbyBmYXIgZnJvbSB2YXJpb3VzIHBhcnRpZXMg ZG8gbWl4IGVkZ2Ugcm91dGVycywNCj4+PnNlY3VyaXR5IGFuZCBhcHBsaWNhdGlvbi1vcmllbnRl ZCBlbGVtZW50cy4NCj4+Pg0KPj4+U28uLi4gSSB3b3VsZCBub3QgYmUgc3VwcG9ydGl2ZSB0byB0 cnlpbmcgdG8gc2VwYXJhdGUgYSBmb3JtIG9mIEwyL0wzDQo+Pj5jaGFpbmluZyBmcm9tIGEgZm9y bSBvZiBMNC9MNyBjaGFpbmluZy4gT24gdGhlIGNvbnRyYXJ5ISA7LSkNCj4+Pg0KPj4+SSB3b3Vs ZCBhY3R1YWxseSBnbyBhcyBmYXIgYXMgc3VnZ2VzdGluZyB0aGF0IHdlIHNob3VsZCBtYWtlIGNs ZWFyZXINCj4+PmluIHRoZSBwcm9wb3NlZCBjaGFydGVyIHRoYXQgdGhpcyBpcyBhIHN0cm9uZyBn b2FsLCB0byBkZWFsIHdpdGggc3VjaA0KPj4+aGV0ZXJvZ2VuZW91cyBjb21ib3MuDQo+Pg0KPj5K aW0+IGFueSB0ZXh0IGFuZCBzdWdnZXN0aW9uIG9mIHdoZXJlIHRvIGluc2VydCBpbnRvIHRoZSBj aGFydGVyPw0KPj4NCj4+Pg0KPj4+SnVzdCBteSAyIGNlbnRzLA0KPj4+SmVyb21lDQo+Pj4NCj4+ Pj09PT0NCj4+PlRvdGFsbHkgdW5yZWxhdGVkIFBTIGZvciBKaW06IHlvdSBkaWRuJ3QgYW5zd2Vy IG15IHF1ZXN0aW9uIGFib3V0IHRoZQ0KPj4+Y29udHJvbCBwbGFuZSBhc3BlY3RzLCB0aGlzIG1h eSBoYXZlIHNsaXBwZWQgdGhyb3VnaCB0aGUgY3JhY2tzISA7LSkNCj4+Pg0KPj4+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWls dG86amd1aWNoYXJAY2lzY28uY29tXQ0KPj4+U2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDQs IDIwMTMgNjo1MSBBTQ0KPj4+VG86IFJvbiBQYXJrZXINCj4+PkNjOiBuc2NAaWV0Zi5vcmc7IFRo b21hcyBOYWRlYXU7IFRob21hcyBOYXJ0ZW47IGFkcmlhbkBvbGRkb2cuY28udWs7DQo+Pj5MaW5k YSBEdW5iYXI7IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFudCkNCj4+PlN1YmplY3Q6IFJlOiBbbnNj XSBOU0MgQm9GIE91dGNvbWVzDQo+Pj4NCj4+PlRoZSBzYW1lIGFyZ3VtZW50IGNvdWxkIGJlIGFw cGxpZWQgZm9yIGZpcmV3YWxscyBhcyB3aXRob3V0IHRoZW0NCj4+PnBhY2tldHMgd291bGQgZ2V0 IHJvdXRlZCBpbnN0ZWFkIG9mIHBlcmhhcHMgZHJvcHBlZC4NCj4+Pg0KPj4+U2VudCBmcm9tIG15 IGlQaG9uZQ0KPj4+DQo+Pj5PbiBTZXAgMywgMjAxMywgYXQgODo0NSBQTSwgIlJvbiBQYXJrZXIi DQo+Pj48Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj4g SGksIExpbmRhLg0KPj4+PiANCj4+Pj4gV2l0aCByZXNwZWN0IHRvOg0KPj4+PiANCj4+Pj4gICAg LSBMYXllciA0IHRvIExheWVyIDcgc2VydmljZSBmdW5jdGlvbnMgKG9yIHNlcnZpY2Ugbm9kZXMp IGFyZSB0bw0KPj4+PmFwcGx5IGFjdGlvbnMgdG8gZGF0YSBwYWNrZXRzIHRyYXZlcnNpbmcgdGhy b3VnaC4gVGhleSBkb24ndCBpbXBhY3QNCj4+Pj5vdmVyYWxsIG5ldHdvcmsgdG9wb2xvZ2llcy9y b3V0ZXMvcmVzdG9yYXRpb25zLg0KPj4+PiANCj4+Pj4gTGF5ZXIgNC03IHNlcnZpY2VzIGNhbiwg aW5kZWVkLCBpbXBhY3Qgcm91dGluZyBkZWNpc2lvbnMuICBGb3INCj4+Pj5leGFtcGxlLCBpZiB0 aGUgc2VydmljZSBpcyBEUEkgYW5hbHlzaXMsIHRoZW4gYSBkZXRlY3RlZCBwcm90b2NvbCBtYXkN Cj4+Pj5jYXVzZSB0aGUgc3Vic2VxdWVudCBwYWNrZXRzIHRvIGJlIHBvbGljeSByb3V0ZWQgb24g YSBwYXRoIGRpZmZlcmVudA0KPj4+PnRoYW4gdGhlIFNQRiBwYXRoLg0KPj4+PiANCj4+Pj4gICBS b24NCj4+Pj4gDQo+Pj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBG cm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYNCj4+Pj4gT2YgTGluZGEgRHVuYmFyDQo+Pj4+IFNlbnQ6IFR1ZXNkYXksIFNlcHRl bWJlciAwMywgMjAxMyA2OjQ4IFBNDQo+Pj4+IFRvOiBUaG9tYXMgTmFkZWF1DQo+Pj4+IENjOiBu c2NAaWV0Zi5vcmc7IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBUaG9tYXMgTmFydGVuOw0KPj4+ PiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpDQo+Pj4+IFN1 YmplY3Q6IFJlOiBbbnNjXSBOU0MgQm9GIE91dGNvbWVzDQo+Pj4+IA0KPj4+PiBIZXJlIGFyZSBz b21lIG9mIHRoZSByZWFzb25zIHRoYXQgY2hhaW5pbmcgb2YgTGF5ZXIgMiBhbmQgMyBzZXJ2aWNl DQo+Pj4+ZnVuY3Rpb25zIGFyZSBkaWZmZXJlbnQgZnJvbSBjaGFpbmluZyBvZiBMYXllciA0IHRv IDcgc2VydmljZQ0KPj4+PmZ1bmN0aW9ucyAoSSB3aWxsIGFkZCBtb3JlIGxhdGVyKToNCj4+Pj4g DQo+Pj4+IA0KPj4+PiAtIExheWVyIDQgdG8gTGF5ZXIgNyBzZXJ2aWNlIGZ1bmN0aW9ucyAob3Ig c2VydmljZSBub2RlcykgYXJlIHRvDQo+Pj4+YXBwbHkgYWN0aW9ucyB0byBkYXRhIHBhY2tldHMg dHJhdmVyc2luZyB0aHJvdWdoLiBUaGV5IGRvbid0IGltcGFjdA0KPj4+Pm92ZXJhbGwgbmV0d29y ayB0b3BvbG9naWVzL3JvdXRlcy9yZXN0b3JhdGlvbnMuDQo+Pj4+IA0KPj4+PiAtIExheWVyIDQt NyBzZXJ2aWNlIGZ1bmN0aW9ucyBkcm9wLCBwYXNzLCBjb25zdW1lLCByZS1pbml0aWF0ZQ0KPj4+ PnBhY2tldHMsIGV0Yy4gVGhleSBkb24ndCBjaGFuZ2UgbmV0d29yayB0b3BvbG9naWVzLCBhbmQg dGhleSBkb24ndA0KPj4+PmltcGFjdCBuZXR3b3JrIHJlc3RvcmF0aW9uIHNjaGVtZSAoZS5nLiBm YXN0IHJlLXJvdXRlKS4gIFdoZW4geW91DQo+Pj4+bW92ZSBhIExheWVyIDQgc2VydmljZSBtb2R1 bGUgZnJvbSBMb2NhdGlvbiBBIHRvIEIsIHRoZSBMYXllciAyLzMNCj4+Pj50b3BvbG9neSBpcyBu b3QgY2hhbmdlZCwgcm91dGVzL3Jlc3RvcmF0aW9uIGFyZSBub3QgY2hhbmdlZC4NCj4+Pj4gDQo+ Pj4+IC0gV2hlbiBjaGFpbmluZyBMYXllciA0IHRvIExheWVyIDcgc2VydmljZSBmdW5jdGlvbnMg dG9nZXRoZXIsIGxpa2UNCj4+Pj5TMS0+UzItPlMzLT5TNCwgdGhleSBhcmUgb3ZlcmxheWluZyBv dmVyIHRoZSB1bmRlcmxheSBuZXR3b3JrLg0KPj4+PiANCj4+Pj4gLSAgTGF5ZXIgMiBhbmQgbGF5 ZXIgMyBub2RlcyBoYXZlIGNvbnRyb2wgcGxhbmUgKGUuZy4gSUdQL0JHUCkgdG8NCj4+Pj5keW5h bWljYWxseSBkaXNjb3ZlciB0b3BvbG9neTsgZm9yd2FyZGluZyBwYXRoczsgcHJvdGVjdGlvbiBw YXRoczsNCj4+Pj5yZXN0b3JhdGlvbiBwYXRocywgZXRjLiBUb2RheSwgYWxsIHJvdXRlcnMgYXJl IGNvbm5lY3RlZCB0b2dldGhlciBieQ0KPj4+PmxpbmtzLiBUaGVpciB0b3BvbG9neSBpcyBtb3Jl IGxpa2UgYSBtZXNoZWQgZ3JhcGggdGhhbiBjaGFpbi4gU28gd2hlbg0KPj4+PnlvdSBjaGFpbiBS b3V0ZXItMTwtPlJvdXRlci0yPC0+Um91dGVyLTMsIGFyZSB5b3UgdGFsa2luZyBhYm91dA0KPj4+ PnNvdXJjZSByb3V0aW5nPyBUaGVyZWZvcmUsIG5lZWQgYSBjbGVhciBkZWZpbml0aW9uIG9uIHdo YXQgZG9lcyBpdA0KPj4+PnJlYWxseSBtZWFuIGJ5IGNoYWluaW5nIExheWVyIDIvMyBzZXJ2aWNl IG5vZGVzLg0KPj4+PiANCj4+Pj4gTGluZGENCj4+Pj4gDQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogVGhvbWFzIE5hZGVhdSBbbWFpbHRvOnRuYWRlYXVAbHVj aWR2aXNpb24uY29tXQ0KPj4+Pj4gU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDAzLCAyMDEzIDU6 MjggUE0NCj4+Pj4+IFRvOiBMaW5kYSBEdW5iYXINCj4+Pj4+IENjOiBuc2NAaWV0Zi5vcmc7IEpp bSBHdWljaGFyZCAoamd1aWNoYXIpOyBTdGV3YXJ0IEJyeWFudA0KPj4+Pj4gKHN0YnJ5YW50KTsg VGhvbWFzIE5hcnRlbjsgYWRyaWFuQG9sZGRvZy5jby51aw0KPj4+Pj4gU3ViamVjdDogUmU6IFtu c2NdIE5TQyBCb0YgT3V0Y29tZXMNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBPbiBTZXAgMywgMjAx Mzo2OjI1IFBNLCBhdCA2OjI1IFBNLCBMaW5kYSBEdW5iYXINCj4+Pj4+IDxsaW5kYS5kdW5iYXJA aHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+PiBUaG9tYXMsDQo+Pj4+Pj4gDQo+Pj4+ Pj4gQXJlIHlvdSBzYXlpbmcgdGhhdCB0aGUgTlNDIHNjb3BlIGluY2x1ZGVzIGNoYWluaW5nIExh eWVyIDIsIExheWVyDQo+Pj4+Pj4gMw0KPj4+Pj4gc2VydmljZSBmdW5jdGlvbnMsIExheWVyIDQg dG8gTGF5ZXIgNyBzZXJ2aWNlIGZ1bmN0aW9ucywgYW5kDQo+Pj4+PiB2YXJpb3VzIGNvbWJpbmF0 aW9uIG9mIHRoZW0/DQo+Pj4+PiANCj4+Pj4+ICAgIEkgZG9uJ3QgZGVmaW5lIHRoZSBzY29wZTsg dGhhdHMgdXAgdG8gdGhlIEFEcy4NCj4+Pj4+IA0KPj4+Pj4gICAgQ291bGQgeW91IHBsZWFzZSBh bnN3ZXIgdGhlIHF1ZXN0aW9uIGJlbG93Pw0KPj4+Pj4gDQo+Pj4+PiAgICAtLVRvbQ0KPj4+Pj4g DQo+Pj4+Pj4gDQo+Pj4+Pj4gTGluZGENCj4+Pj4+PiANCj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+Pj4+Pj4gRnJvbTogVGhvbWFzIE5hZGVhdSBbbWFpbHRvOnRuYWRlYXVA bHVjaWR2aXNpb24uY29tXQ0KPj4+Pj4+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDMsIDIw MTMgNToxOSBQTQ0KPj4+Pj4+PiBUbzogTGluZGEgRHVuYmFyDQo+Pj4+Pj4+IENjOiBKaW0gR3Vp Y2hhcmQgKGpndWljaGFyKTsgYWRyaWFuQG9sZGRvZy5jby51azsgbnNjQGlldGYub3JnOw0KPj4+ Pj4+PiBUaG9tYXMgTmFydGVuOyBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpDQo+Pj4+Pj4+IFN1 YmplY3Q6IFJlOiBbbnNjXSBOU0MgQm9GIE91dGNvbWVzDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+ Pj4+Pj4gT24gU2VwIDMsIDIwMTM6NTo1NCBQTSwgYXQgNTo1NCBQTSwgTGluZGEgRHVuYmFyDQo+ Pj4+Pj4+IDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4+Pj4+IA0KPj4+Pj4+ Pj4gTXkgY29tbWVudHMgYXJlIGluc2VydGVkIGJlbG93IG1hcmtlZCBieSBbTGluZGFdOg0KPj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IEhvd2V2ZXIsIGl0IHdhcyBsZXNzIGNsZWFyIHRvIG1l IHRoYXQgdGhlcmUgaXMgYWdyZWVtZW50IGFib3V0DQo+Pj4+PiB0aGUNCj4+Pj4+Pj4+PiBsYXll cg0KPj4+Pj4+Pj4+PiBpbg0KPj4+Pj4+Pj4+PiB3aGljaCBzZXJ2aWNlIGNoYWluaW5nIGhhcyB0 byBiZSBzb2x2ZWQuIEkgZmVsdCB0aGF0IHNvbWUNCj4+Pj4+Pj4+Pj4gcGVvcGxlIHdlcmUgdGFs a2luZyBhYm91dCBzZXJ2aWNlIGNoYWluaW5nIGluIHRoZSBhcHBsaWNhdGlvbg0KPj4+Pj4+Pj4+ PiBsYXllciwNCj4+Pj4+IHNvbWUNCj4+Pj4+Pj4+Pj4gYWJvdXQgc2VydmljZSBjaGFpbmluZyBi YXNlZCBvbiBmbG93cywgYW5kIHNvbWUgYWJvdXQNCj4+Pj4+Pj4+Pj4gcGVyLXBhY2tldCBzZXJ2 aWNlcy4gVGhlIHNvbHV0aW9ucyBhcmUsDQo+Pj4+Pj4+Pj4gSQ0KPj4+Pj4+Pj4+PiB0aGluaywN Cj4+Pj4+Pj4+Pj4gbGlrZWx5IHRvIGJlIHZlcnkgZGlmZmVyZW50IGZvciB0aGUgZGlmZmVyZW50 IHByb2JsZW1zLCBhbmQgaXQNCj4+Pj4+Pj4gd291bGQNCj4+Pj4+Pj4+PiBiZQ0KPj4+Pj4+Pj4+ PiB3cm9uZyB0bw0KPj4+Pj4+Pj4+PiB0cnkgdG8gYnVuY2ggdGhlbSBhbGwgdG9nZXRoZXIuDQo+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gSmltPiBhbHRob3VnaCB0aGVyZSB3YXMgY2VydGFpbmx5IGlu aXRpYWwgY29uZnVzaW9uIEkgYmVsaWV2ZQ0KPj4+Pj4+Pj4+IEppbT4gdGhpcw0KPj4+Pj4+PiBp cw0KPj4+Pj4+Pj4+IGJlY29taW5nIGxlc3MgYW5kIGxlc3Mgc28gYXMgd2Ugc29jaWFsaXplIHRo ZSBiYXNpYyBpZGVhIG9mDQo+Pj4+PiBzZXJ2aWNlDQo+Pj4+Pj4+Pj4gY2hhaW5pbmc7IGluZGVl ZCwgYXMgd2UgbW92ZSBmb3J3YXJkIHdlIHdpbGwgcmVmbGVjdCBhIG1vcmUNCj4+Pj4+Pj4+PiBj b21tb24gdW5kZXJzdGFuZGluZyB3aXRoaW4gdGhlIHByb2JsZW0gc3RhdGVtZW50Lg0KPj4+Pj4+ Pj4gDQo+Pj4+Pj4+PiBJdCBpcyBzdGlsbCBub3QgY2xlYXIgd2hpY2ggbGF5ZXIgc2VydmljZSBm dW5jdGlvbnMgYXJlIGNoYWluZWQNCj4+Pj4+Pj4gdG9nZXRoZXIuIFRoZSBkcmFmdC1xdWlubi1u c2MtcHJvYmxlbS1zdGF0ZW1lbnQtMDMgZGlzY3Vzc2VkDQo+Pj4+PiBjaGFpbmluZw0KPj4+Pj4+ PiBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IGNhbiBiZSBhIG5ldHdvcmsgb3IgYXBwbGljYXRp b24gYmFzZWQNCj4+Pj4+Pj4gcGFja2V0IHRyZWF0bWVudCwuLi4sIHRvIGVuYWJsZSBhIHNlcnZp Y2Ugb2ZmZXJlZCBieSBhIG5ldHdvcmsNCj4+Pj4+IG9wZXJhdG9ycy4NCj4+Pj4+Pj4gDQo+Pj4+ Pj4+ICAgIFdoeSBkbyB5b3UgdGhpbmsgdGhhdCBtYXR0ZXJzPw0KPj4+Pj4+PiANCj4+Pj4+Pj4+ IFRvZGF5LCB0aGVyZSBhcmUgbWFueSBzZXJ2aWNlcyBvZmZlcmVkIGJ5IG9wZXJhdG9ycywgZS5n LiBMMlZQTiwNCj4+Pj4+Pj4+IEwzVlBOLCBQMlAgcGF0aHMsIGV0Yy4gU28geW91IGNhbiBpbnRl cnByZXQgTlNDIGFzIGNoYWluaW5nDQo+Pj4+Pj4+PiBMMi9MMw0KPj4+Pj4+PiBzZXJ2aWNlIGZ1 bmN0aW9ucyAobGlrZSBwcm94eSBmb3J3YXJkaW5nLCBvciBmcmFnbWVudGF0aW9uLA0KPj4+Pj4+ PiBldGMuKTsgWW91IGNhbiBhbHNvIGludGVycHJldCBOU0MgYXMgY2hhaW5pbmcgTDQgIChhbmQg YWJvdmUpDQo+Pj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zOyBvciBjaGFpbmluZyBvZiBtaXhlZCBM NC1MNyBzZXJ2aWNlIGZ1bmN0aW9ucw0KPj4+Pj4+PiAoaS5lLiB3aXRoIHNvbWUgc2VydmljZSBu b2RlcyBjb25zdW1pbmcgcGFja2V0cyBhbmQgcmVpbml0aWF0ZSBuZXcNCj4+Pj4+Pj5wYWNrZXRz KS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICAgIFlvdSBjYW4sIGFuZCBwZW9wbGUgYWN0dWFsbHkgZG8g aW1wbGVtZW50IHRoaXMgdG9kYXkuDQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gSXMgTlNDIGluY2x1ZGlu ZyBhbGwgY2hhaW5pbmcgb2YgYWxsIHRob3NlIHNlcnZpY2VzPw0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBMYXllciAyLzMgc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBtaWdodCByZXF1aXJlIGRpZmZl cmVudA0KPj4+Pj4+Pj4gc2NoZW1lcw0KPj4+Pj4+PiB0aGFuIExheWVyIDQtNyBzZXJ2aWNlIGNo YWluaW5nLiBUaGVyZWZvcmUsIGl0IGlzIG1vcmUgZWZmZWN0aXZlDQo+Pj4+Pj4+IHRvIGRlZmlu ZSB0aGVtIHNlcGFyYXRlbHkgdG8gbWFrZSB0aGUgZGlzY3Vzc2lvbiBtb3JlIGZvY3VzZWQuDQo+ Pj4+Pj4+IA0KPj4+Pj4+PiAgICBJIGRvIG5vdCB0aGluayBzby4gSSdkIHByZWZlciB0byBub3Qg bWFrZSB0aGlzIG9ubHkgYXMNCj4+Pj4+IGNvbXBsaWNhdGVkDQo+Pj4+Pj4+IGFzIGl0IG5lZWRz IHRvIGJlLCBhbmQgbm8gbW9yZS4gVGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyBvZg0KPj4+Pj4+ PiBMYXllcg0KPj4+Pj4+PiAyIGFuZCAzIGNoYWluaW5nIHRoYXQgYXJlIGFsbCBkb25lIHdpdGgg dGhlIHNhbWUNCj4+Pj4+Pj4gZW5jYXAvcHJvdmlzaW9uaW5nIHN5c3RlbXMuDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiAgICAtLVRvbQ0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ IExpbmRhIER1bmJhcg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+PiBuc2MgbWFp bGluZyBsaXN0DQo+Pj4+Pj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0 DQo+Pj4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+Pj4gDQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+ Pj4gbnNjQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uc2MNCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+Pj4gbnNjQGlldGYub3JnDQo+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4NCj4+Pg0K Pj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pm5zYyBtYWlsaW5nIGxpc3QNCj5uc2NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25zYw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj5DZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj5jb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBk aWZmdXNlcywNCj5leHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhcg0KPmVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIg YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcw0KPnBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMNCj5kJ2Fs dGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUNCj5hbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPg0KPlRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw cml2aWxlZ2VkDQo+aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhl eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLA0KPnVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4NCj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kDQo+ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLg0KPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZQ0KPmJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLg0KPlRoYW5rIHlvdS4NCj4NCg0K From Ron_Parker@affirmednetworks.com Wed Sep 4 10: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 B76D211E81CD for ; Wed, 4 Sep 2013 10:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 3YukLA1Cm3gV for ; Wed, 4 Sep 2013 10:31:25 -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 EEBB611E80F6 for ; Wed, 4 Sep 2013 10:31:24 -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; Wed, 4 Sep 2013 10:31:24 -0700 From: Ron Parker To: Ken Gray , "mohamed.boucadair@orange.com" , "nsc@ietf.org" Thread-Topic: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt Thread-Index: Ac6fMhIAzIOqddliRk+cqJ/CnVKw9ADv8zVgAZrASQAACgW9EP//xs+A//+qjJA= Date: Wed, 4 Sep 2013 17:31:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.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, 04 Sep 2013 17:31:30 -0000 Hi, Ken. In some of the I'D's we do touch on the logical network function concept, b= ut we may need to consolidate and strengthen the requirements around that. = Not only can multiple disparate network functions co-reside at the same= managed network element, but even multiple instances of the same type of n= etwork function where these instance imply differentiated behaviors. For = example, the same managed network element may support 'firewall-strict', 'f= irewall-loose', 'content-filter-adult', 'content-filter-child', 'dpi-analyt= ics'. A useful service chain may, for example, select 'firewall-strict' = and 'content-filter-child' plus other service functions that happen to resi= de in other managed network elements. In draft-boucadair-service-chaining-framework, section 9.3, On Service Func= tion Profiles (a.k.a., Contexts), we point out that logical service functio= ns can imply differentiated behavior (policy). In the same I-D, section 5.5, SF Node, we have the text: In case several SFs are co-located in the same node, the packet is processed by all SFs indicated in the SF Map. Once the packet is successfully handled by local SF(s), the packet is forwarded to the next SF Node in the list or to an intermediate node (if the local SFC Node is the last element in the SF Map). Thanks. Ron -----Original Message----- From: Ken Gray [mailto:kgray@juniper.net]=20 Sent: Wednesday, September 04, 2013 12:15 PM To: Ron Parker; mohamed.boucadair@orange.com; nsc@ietf.org Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01= .txt We're bouncing around my point, though you actually bring up an ancillary t= hing of interest.=20 Assuming that an element performs multiple functions (either as multiple vi= rtual machines or as part of it's physical/logical architecture as a non-vi= rtual device), then there is an interesting question about how we represent= this in service discovery - particularly if we cannot manipulate the order= or isolate an order (that's the part I think is new and interesting in you= r response). I think we're agreeing that the work of the NSC workgroup will ignore the m= echanics of such chaining as implementation details and thus not describe h= ow they are chained - keeping us out of the IPC/RPC bailywick and focusing = only on the description of/standardization of externally chained services (= though, as I mentioned above, representation of that combined service IS re= levant to NSC work). Yes? If so, we should make this clear in #2? On 9/4/13 11:47 AM, "Ron Parker" wrote: >Hi, Ken. > >Responding to your comment on REQ #2, from my perspective... > >A particular network element (physical or virtual) can definitely support >multiple service functions simultaneously. Any particular chain may >invoke any of them in any order. However, I feel that it is an >implementation specific design issue whether hops between these=20 >co-resident services literally follow the exact service chaining=20 >procedures that we ultimately define or simply behave as if they were=20 >exactly followed (i.e., external-service A to internal-service B to=20 >internal-service C to external-service D -- only the external A to=20 >internal B and the internal C to external D are externally observable). > > Ron > > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >Ken Gray >Sent: Wednesday, September 04, 2013 10:53 AM >To: mohamed.boucadair@orange.com; nsc@ietf.org >Subject: Re: [nsc] TR: I-D Action: >draft-boucadair-chaining-requirements-01.txt > >Heya, Med. > >I gave it a quick read. I have the following questions/observations: > >REQ#2 - The document doesn't specifically say whether we're=20 >constraining our focus on chains that require an "externality" for each=20 >link (that is, ARE we assuming that each "link" will pass through a=20 >network/networked element e.g. Hypervisor switch) - and are thus=20 >excluding from discussion IPC (or RPC) mechanisms between service=20 >elements on the same device (which are much harder to detect, monitor, sta= ndardize). > >REQ#13 is putting a constraint on the header discussion. Is this the=20 >right place to put that, particularly since the requirements there=20 >haven't been fully defined (yet)? > >REQ#15 - while I fully appreciate your desire to avoid another 80+ part=20 >email thread on whether MPLS is an overlay, I think you make your point=20 >well enough in the main assertion and part "b" is actually redundant. =20 >8^) > >REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22=20 >has to be a MUST (I think the need for downstream reclassification can=20 >be a normal outcome of the function of an individual service element as=20 >it potentially transforms a header - unless your argument is that we=20 >should avoid this wherever possible by imbedding a clue in the header -=20 >in which case we run into issues with "non-speakers" or legacy devices). > >REQ#23 seems to obviate the use of simple route NH manipulation to=20 >create a chain (this is destination address based). So, to be=20 >inclusive, I think that has to be a SHOULD. > >REQ#25 seems to be difficult to require if you don't dictate how the=20 >chain is formed (how the forwarding is instantiated) and should be=20 >worded more like REQ#29, IMO. > >REQ#30 I think you're trying to say that static definition/topology of=20 >service functions SHOULD be supported but dynamic MUST (not that every=20 >element has to support dynamic discovery but that the overall goal of=20 >the ongoing architecture should be dynamic with static augmentation for=20 >corner/legacy cases) ...which would be more in alignment with the tenor=20 >of REQ#32. > >Thanks for kicking it off and reading this drivel ... > > > > > > >On 8/27/13 2:58 AM, "mohamed.boucadair@orange.com" > wrote: > >>Dear all, >> >>A new version of the requirements draft is now available online. The=20 >>main changes in this new version are as follows: >> >>* Enrich the document with inputs from=20 >>draft-li-service-chaining-requirements >>* Welcome authors of draft-li-service-chaining-requirements as=20 >>co-authors >>* Add new security-related requirements. >>* Re-order the requirements >> >>A more detailed diff is available at: >>http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requiremen >>t >>s-0 >>1.txt >> >>Feel free to share your comments, suggestions and text contributions=20 >>on the list or direct them to the authors. >> >>Cheers, >>Med >> >>-----Message d'origine----- >>De : i-d-announce-bounces@ietf.org >>[mailto:i-d-announce-bounces@ietf.org] >>De la part de internet-drafts@ietf.org Envoy=E9 : jeudi 22 ao=FBt 2013=20 >>14:21 =C0 : i-d-announce@ietf.org Objet : I-D Action:=20 >>draft-boucadair-chaining-requirements-01.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts=20 >>directories. >> >> >> Title : Requirements for Service Function Chaining >> Author(s) : Mohamed Boucadair >> Christian Jacquenet >> Yuanlong Jiang >> Hongyu Li >> Ron Parker >> Filename : draft-boucadair-chaining-requirements-01.txt >> Pages : 10 >> Date : 2013-08-22 >> >>Abstract: >> This document identifies the requirements for the Service Function >> Chaining. >> >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirements >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-boucadair-chaining-requirements-01 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirements >>- >>01 >> >> >>Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc >> >> > > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > > From Ron_Parker@affirmednetworks.com Wed Sep 4 10:34: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 C825121E80EF for ; Wed, 4 Sep 2013 10:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 aDweyp9GIcT8 for ; Wed, 4 Sep 2013 10:34:10 -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 0904B21E8153 for ; Wed, 4 Sep 2013 10:34:08 -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; Wed, 4 Sep 2013 10:34:07 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , Jerome Moisand , "christian.jacquenet@orange.com" Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqOMRqGNOUrYckkyTmJK+S7Yz7pm1BAEAgAAGpACAAAH2gIAAAJuAgAAFo4D//6rY8IABHywAgAAzlgCAAAYUgP//oOrAgAB65ACAAAISgIAAA/QAgAARKYD//43sIA== Date: Wed, 4 Sep 2013 17:34:07 +0000 Message-ID: References: <22e3d4546f5140e8a7ac9ff20246c143@BN1PR05MB251.namprd05.prod.outlook.com> <68B171751455884590F8E38E96416F363F675803@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F675803@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nsc@ietf.org" , Thomas Nadeau , Thomas Narten , "adrian@olddog.co.uk" , Linda Dunbar , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 17:34:14 -0000 SmltLA0KDQpUaGF0IHNvdW5kcyBmaW5lIHRvIG1lLiAgIEkgd2FudGVkIHRvIGVtcGhhc2l6ZSB0 aGUgaWRlYSB0aGF0IGNvbnRyb2wgcGxhbmUgc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIG1hbmRh dG9yeSB0byByZWFsaXplIGEgbmV0d29yayBzZXJ2aWNlIGNoYWluaW5nIGRlcGxveW1lbnQsIGFu ZCBJIGZlZWwgdGhhdCB0aGF0IGNvbmNlcHQgaXMgbm93IG9uIHRoZSB0YWJsZS4NCg0KVGhhbmtz Lg0KDQogICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEppbSBH dWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXSANClNlbnQ6IFdl ZG5lc2RheSwgU2VwdGVtYmVyIDA0LCAyMDEzIDE6MjAgUE0NClRvOiBKZXJvbWUgTW9pc2FuZDsg Y2hyaXN0aWFuLmphY3F1ZW5ldEBvcmFuZ2UuY29tOyBSb24gUGFya2VyDQpDYzogbnNjQGlldGYu b3JnOyBUaG9tYXMgTmFkZWF1OyBMaW5kYSBEdW5iYXI7IGFkcmlhbkBvbGRkb2cuY28udWs7IFRo b21hcyBOYXJ0ZW47IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFudCkNClN1YmplY3Q6IFJlOiBbbnNj XSBOU0MgQm9GIE91dGNvbWVzDQoNCkxldCBtZSBzdWdnZXN0IHRoYXQgd2Uga2VlcCBhIHNpbmds ZSByZXF1aXJlbWVudHMgZG9jdW1lbnQgZm9yIG5vdyBhbmQgcGVyaGFwcyBzcGxpdCBpbnRvIHNl cGFyYXRlIGRhdGEgYW5kIGNvbnRyb2wgcGxhbmUgZG9jdW1lbnRzIHNob3VsZCB0aGF0IGJlY29t ZSBuZWNlc3NhcnkgYXMgdGhlIHNpbmdsZSBkb2N1bWVudCBldm9sdmVzLg0KDQpPbiA5LzQvMTMg MTI6MTggUE0sICJKZXJvbWUgTW9pc2FuZCIgPGptb2lzYW5kQGp1bmlwZXIubmV0PiB3cm90ZToN Cg0KPkkgd291bGQgdGVuZCB0byBhZ3JlZSB3aXRoIENocmlzdGlhbiwgcmVxdWlyZW1lbnRzIHNo b3VsZCBiZSBhYm91dCB0aGUgDQo+b3ZlcmFsbCBwcm9ibGVtIHRvIHNvbHZlLiBQbHVzIGEgY29u dHJvbCBwbGFuZSB0ZW5kcyB0byBjb250cm9sLi4uIHRoZSANCj5kYXRhIHBsYW5lISBTbyBiZXR0 ZXIgd29yayBvbiByZXF1aXJlbWVudHMgd2hpY2ggd291bGQgYmUgY29uc2lzdGVudCANCj5lbm91 Z2ggdG8gYWNrbm93bGVkZ2Ugc3VjaCByZWxhdGlvbnNoaXAuDQo+DQo+Tm93LCBJIGFsc28gYWdy ZWUgd2l0aCBSb24gdGhhdCBhIGNvbnRyb2wgcGxhbmUgbWF5IG5vdCBiZSByZXF1aXJlZCBpbiAN Cj5hbGwgY2FzZXMuIFRoaXMgc2hvdWxkIHByb2JhYmx5IGJlIGEgcmVxdWlyZW1lbnQsIGFjdHVh bGx5LCB0byBub3QgDQo+bWFuZGF0ZSBhIGNvbnRyb2wgcGxhbmUgaW4gYWxsIGNhc2VzIQ0KPg0K Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogY2hyaXN0aWFuLmphY3F1ZW5ldEBv cmFuZ2UuY29tDQo+W21haWx0bzpjaHJpc3RpYW4uamFjcXVlbmV0QG9yYW5nZS5jb21dDQo+U2Vu dDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTMgMTI6MDQgUE0NCj5UbzogSmltIEd1aWNo YXJkIChqZ3VpY2hhcik7IFJvbiBQYXJrZXI7IEplcm9tZSBNb2lzYW5kDQo+Q2M6IG5zY0BpZXRm Lm9yZzsgVGhvbWFzIE5hZGVhdTsgTGluZGEgRHVuYmFyOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyAN Cj5UaG9tYXMgTmFydGVuOyBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpDQo+U3ViamVjdDogUkU6 IFtuc2NdIE5TQyBCb0YgT3V0Y29tZXMNCj4NCj5IaSosDQo+DQo+SSBzdXBwb3J0IHRoZSBwdWJs aWNhdGlvbiBvZiBhIHNpbmdsZSByZXF1aXJlbWVudHMgZG9jdW1lbnQgKGZvciB0aGUgDQo+c2Fr ZSBvZiBjb25zaXN0ZW5jeSksIGFuZCB3aGljaCB3b3VsZCBpbmNsdWRlIGJvdGggY29udHJvbCBh bmQgZGF0YSANCj5wbGFuZSBjb25zaWRlcmF0aW9ucyBhbW9uZyBvdGhlciB0b3BpY3MuDQo+DQo+ Q2hlZXJzLA0KPg0KPkNocmlzdGlhbi4NCj4NCj4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj5EZSA6IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmdd IERlIGxhIHBhcnQgZGUgDQo+SmltIEd1aWNoYXJkIChqZ3VpY2hhcikgRW52b3nDqSA6IG1lcmNy ZWRpIDQgc2VwdGVtYnJlIDIwMTMgMTc6NTcgw4AgOiANCj5Sb24gUGFya2VyOyBKZXJvbWUgTW9p c2FuZCBDYyA6IG5zY0BpZXRmLm9yZzsgVGhvbWFzIE5hZGVhdTsgTGluZGEgDQo+RHVuYmFyOyBh ZHJpYW5Ab2xkZG9nLmNvLnVrOyBUaG9tYXMgTmFydGVuOyBTdGV3YXJ0IEJyeWFudCAoc3Ricnlh bnQpIE9iamV0IDogUmU6DQo+W25zY10gTlNDIEJvRiBPdXRjb21lcw0KPg0KPklzIHRoZSBzdWdn ZXN0aW9uIHRoZXJlZm9yZSB0aGF0IHNlcGFyYXRlIGRhdGEgYW5kIGNvbnRyb2wgcGxhbmUgDQo+ cmVxdWlyZW1lbnRzIEktRCdzIHNob3VsZCBiZSBjcmVhdGVkIHJhdGhlciB0aGFuIGFuIG92ZXJh bGwgDQo+cmVxdWlyZW1lbnRzIGRvY3VtZW50IGNvdmVyaW5nIGJvdGg/DQo+DQo+T24gOS80LzEz IDExOjM5IEFNLCAiUm9uIFBhcmtlciIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+ IHdyb3RlOg0KPg0KPj5KaW0sDQo+Pg0KPj5JIGFncmVlIHRoYXQgdGhlIGNoYXJ0ZXIgc2hvdWxk IG5vdCBiZSB0b28gc3BlY2lmaWMgb24gdGhlIGRlc2lnbiBvZiANCj4+dGhlIGNvbnRyb2wgcGxh bmUsIGJ1dCByYXRoZXIgdG8gcmVjb2duaXplIHRoYXQgb25lIGNvdWxkIGJlIA0KPj5hZHZhbnRh Z2VvdXMgKGFsdGhvdWdoIG5vdCBuZWNlc3NhcmlseSByZXF1aXJlZCkgZm9yIHRoZSBvdmVyYWxs IA0KPj5zZXJ2aWNlIGNoYWluaW5nDQo+PnNvbHV0aW9uLiAgICBBIGNvbnRyb2wgcGxhbmUgcmVx dWlyZW1lbnRzIGFuZC9vciB1c2UgY2FzZXMgZG9jdW1lbnQNCj4+c2hvdWxkIHByZWNlZGUgYW55 IGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wgZGVzaWduIG9yIHNlbGVjdGlvbi4NCj4+DQo+PiAgIFJv bg0KPj4NCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IEppbSBHdWlj aGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0KPj5TZW50OiBXZWRu ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMyAxMDoxNyBBTQ0KPj5UbzogSmVyb21lIE1vaXNhbmQ7 IFJvbiBQYXJrZXINCj4+Q2M6IG5zY0BpZXRmLm9yZzsgVGhvbWFzIE5hZGVhdTsgVGhvbWFzIE5h cnRlbjsgYWRyaWFuQG9sZGRvZy5jby51azsgDQo+PkxpbmRhIER1bmJhcjsgU3Rld2FydCBCcnlh bnQgKHN0YnJ5YW50KQ0KPj5TdWJqZWN0OiBSZTogW25zY10gTlNDIEJvRiBPdXRjb21lcw0KPj4N Cj4+SGkgSmVyb21lLA0KPj4NCj4+TXkgYmFkIC4uIFJlc3BvbmRpbmcgdG8geW91ciBQUyA7KSDF oCBSaWdodCBub3cgdGhlIGNoYXJ0ZXIgc3VnZ2VzdHMgDQo+PnRoYXQgdGhlIFdHIGJlIHJlc3Bv bnNpYmxlIGZvciBkZWZpbmluZyB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSANCj4+Y29udHJvbCBw bGFuZSB3aXRoIHJlc3BlY3QgdG8gc2VydmljZSBjaGFpbmluZy4gVGhlIHByb2JsZW0gaGVyZSBp cyBvZiANCj4+Y291cnNlIHRoYXQgdGhlcmUgYXJlIG11bHRpcGxlIGNvbnRyb2wgcGxhbmVzLiBJ biBteSBtaW5kIGl0IG1ha2VzIA0KPj5saXR0bGUgc2Vuc2UgdG8gdHJ5IGFuZCB0YWNrbGUgdGhl bSBhbGwgYnV0IHJhdGhlciBkZWZpbmUgd2hhdCBpcyANCj4+bmVjZXNzYXJ5IGZvciBhIGNvbnRy b2wgcGxhbmUgdG8gaW1wbGVtZW50IHRvIHN1Y2Nlc3NmdWxseSBlbmFibGUgDQo+PnNlcnZpY2Ug Y2hhaW5zIGFuZCB0aGVuIGxpYWlzZSB3aXRoIG90aGVyIFdHJ3Mgb24gdGhlIGRldGFpbHMuDQo+ Pg0KPj5Tb21lIGZ1cnRoZXIgY29tbWVudHMgaW5saW5lLg0KPj4NCj4+T24gOS80LzEzIDk6NTUg QU0sICJKZXJvbWUgTW9pc2FuZCIgPGptb2lzYW5kQGp1bmlwZXIubmV0PiB3cm90ZToNCj4+DQo+ Pj5JdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBlbnRpcmUgcG9pbnQgb2Ygc2VydmljZSBjaGFpbmlu ZyBpcyBpbmRlZWQgdG8gDQo+Pj5jaGFpbiB0b2dldGhlciBoZXRlcm9nZW5lb3VzIHNlcnZpY2Ut ZW5hYmxpbmcgZWxlbWVudHMsIGFuZCBtYWtlIHRoZSANCj4+PmJlc3Qgb3V0IG9mIHN1Y2ggY29t Ym8uDQo+Pg0KPj5KaW0+IGV4YWN0bHkuIFRoZSBwb2ludCBiZWluZyBzZXBhcmF0ZSBzZXJ2aWNl IGZ1bmN0aW9ucyBpbnRvIGEgDQo+PkppbT4gcmVzb3VyY2UNCj4+cG9vbCB0aGF0IGNhbiBiZSB1 dGlsaXplZCBhbmQgbm90IGNvbnN0cmFpbmVkIGJhc2VkIG9uIHRvcG9sb2d5Lg0KPj4NCj4+PiAN Cj4+Pg0KPj4+U2VydmljZSBFZGdlIHJvdXRlcnMgKGluY2x1ZGluZyBCaXotUEVzLCBCTkdzIGFu ZCBNb2JpbGUgR1dzKSBlbmFibGUNCj4+PkwzIHNlcnZpY2VzLCBvbiBhIHBlciBzdWJzY3JpYmVy IGJhc2lzLiBGaXJld2FsbHMgY2FuIGFjdCBlaXRoZXIgYXQNCj4+PkwzL0w0IG9yDQo+Pj5MNC9M NyAoZS5nLiBhZGRpbmcgc29tZSBJbnRydXNpb24gRGV0ZWN0aW9uIHRvIHRoZSBtaXgpLiBEUEkg b3IgSFRUUCANCj4+PlByb3hpZXMvRmlsdGVycyBlbmdpbmVzIGFjdCBhdCBMNy4gU2Vzc2lvbiBC b3JkZXIgQ29udHJvbGxlcnMgYWN0IGF0IA0KPj4+TDcsIGFsdGhvdWdoIHRoZXkgZG8gc29tZSBM My9MNCBwcm9jZXNzaW5nIHRvbyAoTkFUKS4gQWxsIHRob3NlIA0KPj4+dmFyaW91cyBlbGVtZW50 cyBoYXZlIHRoZWlyIG93biBzdHJlbmd0aHMgaW4gdGVybXMgb2YgdHJhZmZpYyANCj4+PmNsYXNz aWZpY2F0aW9uIGFuZCBpbiB0ZXJtcyBvZiBwb2xpY3kgZW5mb3JjZW1lbnQuIFdoaWNoIGNhbiBj b21iaW5lZCANCj4+PmluIHNtYXJ0IHdheXMgKGUuZy4NCj4+PnVzZSBEUEkgdG8gaWRlbnRpZnkv Y2xhc3NpZnkgYW4gYXBwbGljYXRpb24gZmxvdywgdXNlIGFuIGVkZ2Ugcm91dGVyIA0KPj4+dG8g cGVyZm9ybSBmYW5jeSBxdWV1aW5nIGJhc2VkIG9uIHN1Y2ggRFBJIGNsYXNzaWZpY2F0aW9uIGFt b25nIG90aGVyIA0KPj4+dHJhZmZpYyBmbG93cykuDQo+Pg0KPj5KaW0+IHllcC4gDQo+Pg0KPj4+ IA0KPj4+DQo+Pj5UaGUgYmVhdXR5IG9mIHNlcnZpY2UgY2hhaW5pbmcgaXMgdG8gY29tYmluZSBh bGwgdGhvc2UgZWxlbWVudHMgdG8gDQo+Pj5tYWtlIHNvbWV0aGluZyB0cnVseSB1c2VmdWwgKGUu Zy4gcHJvdmlkZSBhIG1vcmUgY29tcGxleCBTZXJ2aWNlIA0KPj4+LXdpdGggYSBjYXBpdGFsICdT Jy0gdG8gc2VydmljZSBwcm92aWRlciB1c2VycyBvciBlbnRlcnByaXNlIHVzZXJzKS4gDQo+Pj5B bGwgdGhlIHVzZSBjYXNlcyBJJ3ZlIGhlYXJkIHNvIGZhciBmcm9tIHZhcmlvdXMgcGFydGllcyBk byBtaXggZWRnZSANCj4+PnJvdXRlcnMsIHNlY3VyaXR5IGFuZCBhcHBsaWNhdGlvbi1vcmllbnRl ZCBlbGVtZW50cy4NCj4+Pg0KPj4+U28uLi4gSSB3b3VsZCBub3QgYmUgc3VwcG9ydGl2ZSB0byB0 cnlpbmcgdG8gc2VwYXJhdGUgYSBmb3JtIG9mIEwyL0wzIA0KPj4+Y2hhaW5pbmcgZnJvbSBhIGZv cm0gb2YgTDQvTDcgY2hhaW5pbmcuIE9uIHRoZSBjb250cmFyeSEgOy0pDQo+Pj4NCj4+Pkkgd291 bGQgYWN0dWFsbHkgZ28gYXMgZmFyIGFzIHN1Z2dlc3RpbmcgdGhhdCB3ZSBzaG91bGQgbWFrZSBj bGVhcmVyIA0KPj4+aW4gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGhhdCB0aGlzIGlzIGEgc3Ryb25n IGdvYWwsIHRvIGRlYWwgd2l0aCBzdWNoIA0KPj4+aGV0ZXJvZ2VuZW91cyBjb21ib3MuDQo+Pg0K Pj5KaW0+IGFueSB0ZXh0IGFuZCBzdWdnZXN0aW9uIG9mIHdoZXJlIHRvIGluc2VydCBpbnRvIHRo ZSBjaGFydGVyPw0KPj4NCj4+Pg0KPj4+SnVzdCBteSAyIGNlbnRzLA0KPj4+SmVyb21lDQo+Pj4N Cj4+Pj09PT0NCj4+PlRvdGFsbHkgdW5yZWxhdGVkIFBTIGZvciBKaW06IHlvdSBkaWRuJ3QgYW5z d2VyIG15IHF1ZXN0aW9uIGFib3V0IHRoZSANCj4+PmNvbnRyb2wgcGxhbmUgYXNwZWN0cywgdGhp cyBtYXkgaGF2ZSBzbGlwcGVkIHRocm91Z2ggdGhlIGNyYWNrcyEgOy0pDQo+Pj4NCj4+Pi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBb bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCj4+PlNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVy IDA0LCAyMDEzIDY6NTEgQU0NCj4+PlRvOiBSb24gUGFya2VyDQo+Pj5DYzogbnNjQGlldGYub3Jn OyBUaG9tYXMgTmFkZWF1OyBUaG9tYXMgTmFydGVuOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyANCj4+ PkxpbmRhIER1bmJhcjsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KQ0KPj4+U3ViamVjdDogUmU6 IFtuc2NdIE5TQyBCb0YgT3V0Y29tZXMNCj4+Pg0KPj4+VGhlIHNhbWUgYXJndW1lbnQgY291bGQg YmUgYXBwbGllZCBmb3IgZmlyZXdhbGxzIGFzIHdpdGhvdXQgdGhlbSANCj4+PnBhY2tldHMgd291 bGQgZ2V0IHJvdXRlZCBpbnN0ZWFkIG9mIHBlcmhhcHMgZHJvcHBlZC4NCj4+Pg0KPj4+U2VudCBm cm9tIG15IGlQaG9uZQ0KPj4+DQo+Pj5PbiBTZXAgMywgMjAxMywgYXQgODo0NSBQTSwgIlJvbiBQ YXJrZXIiDQo+Pj48Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4gd3JvdGU6DQo+Pj4N Cj4+Pj4gSGksIExpbmRhLg0KPj4+PiANCj4+Pj4gV2l0aCByZXNwZWN0IHRvOg0KPj4+PiANCj4+ Pj4gICAgLSBMYXllciA0IHRvIExheWVyIDcgc2VydmljZSBmdW5jdGlvbnMgKG9yIHNlcnZpY2Ug bm9kZXMpIGFyZSB0byANCj4+Pj5hcHBseSBhY3Rpb25zIHRvIGRhdGEgcGFja2V0cyB0cmF2ZXJz aW5nIHRocm91Z2guIFRoZXkgZG9uJ3QgaW1wYWN0IA0KPj4+Pm92ZXJhbGwgbmV0d29yayB0b3Bv bG9naWVzL3JvdXRlcy9yZXN0b3JhdGlvbnMuDQo+Pj4+IA0KPj4+PiBMYXllciA0LTcgc2Vydmlj ZXMgY2FuLCBpbmRlZWQsIGltcGFjdCByb3V0aW5nIGRlY2lzaW9ucy4gIEZvciANCj4+Pj5leGFt cGxlLCBpZiB0aGUgc2VydmljZSBpcyBEUEkgYW5hbHlzaXMsIHRoZW4gYSBkZXRlY3RlZCBwcm90 b2NvbCANCj4+Pj5tYXkgY2F1c2UgdGhlIHN1YnNlcXVlbnQgcGFja2V0cyB0byBiZSBwb2xpY3kg cm91dGVkIG9uIGEgcGF0aCANCj4+Pj5kaWZmZXJlbnQgdGhhbiB0aGUgU1BGIHBhdGguDQo+Pj4+ IA0KPj4+PiAgIFJvbg0KPj4+PiANCj4+Pj4gDQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiANCj4+Pj4gT2YgTGluZGEgRHVuYmFyDQo+Pj4+IFNlbnQ6IFR1 ZXNkYXksIFNlcHRlbWJlciAwMywgMjAxMyA2OjQ4IFBNDQo+Pj4+IFRvOiBUaG9tYXMgTmFkZWF1 DQo+Pj4+IENjOiBuc2NAaWV0Zi5vcmc7IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBUaG9tYXMg TmFydGVuOyANCj4+Pj4gYWRyaWFuQG9sZGRvZy5jby51azsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5 YW50KQ0KPj4+PiBTdWJqZWN0OiBSZTogW25zY10gTlNDIEJvRiBPdXRjb21lcw0KPj4+PiANCj4+ Pj4gSGVyZSBhcmUgc29tZSBvZiB0aGUgcmVhc29ucyB0aGF0IGNoYWluaW5nIG9mIExheWVyIDIg YW5kIDMgc2VydmljZSANCj4+Pj5mdW5jdGlvbnMgYXJlIGRpZmZlcmVudCBmcm9tIGNoYWluaW5n IG9mIExheWVyIDQgdG8gNyBzZXJ2aWNlIA0KPj4+PmZ1bmN0aW9ucyAoSSB3aWxsIGFkZCBtb3Jl IGxhdGVyKToNCj4+Pj4gDQo+Pj4+IA0KPj4+PiAtIExheWVyIDQgdG8gTGF5ZXIgNyBzZXJ2aWNl IGZ1bmN0aW9ucyAob3Igc2VydmljZSBub2RlcykgYXJlIHRvIA0KPj4+PmFwcGx5IGFjdGlvbnMg dG8gZGF0YSBwYWNrZXRzIHRyYXZlcnNpbmcgdGhyb3VnaC4gVGhleSBkb24ndCBpbXBhY3QgDQo+ Pj4+b3ZlcmFsbCBuZXR3b3JrIHRvcG9sb2dpZXMvcm91dGVzL3Jlc3RvcmF0aW9ucy4NCj4+Pj4g DQo+Pj4+IC0gTGF5ZXIgNC03IHNlcnZpY2UgZnVuY3Rpb25zIGRyb3AsIHBhc3MsIGNvbnN1bWUs IHJlLWluaXRpYXRlIA0KPj4+PnBhY2tldHMsIGV0Yy4gVGhleSBkb24ndCBjaGFuZ2UgbmV0d29y ayB0b3BvbG9naWVzLCBhbmQgdGhleSBkb24ndCANCj4+Pj5pbXBhY3QgbmV0d29yayByZXN0b3Jh dGlvbiBzY2hlbWUgKGUuZy4gZmFzdCByZS1yb3V0ZSkuICBXaGVuIHlvdSANCj4+Pj5tb3ZlIGEg TGF5ZXIgNCBzZXJ2aWNlIG1vZHVsZSBmcm9tIExvY2F0aW9uIEEgdG8gQiwgdGhlIExheWVyIDIv MyANCj4+Pj50b3BvbG9neSBpcyBub3QgY2hhbmdlZCwgcm91dGVzL3Jlc3RvcmF0aW9uIGFyZSBu b3QgY2hhbmdlZC4NCj4+Pj4gDQo+Pj4+IC0gV2hlbiBjaGFpbmluZyBMYXllciA0IHRvIExheWVy IDcgc2VydmljZSBmdW5jdGlvbnMgdG9nZXRoZXIsIGxpa2UNCj4+Pj5TMS0+UzItPlMzLT5TNCwg dGhleSBhcmUgb3ZlcmxheWluZyBvdmVyIHRoZSB1bmRlcmxheSBuZXR3b3JrLg0KPj4+PiANCj4+ Pj4gLSAgTGF5ZXIgMiBhbmQgbGF5ZXIgMyBub2RlcyBoYXZlIGNvbnRyb2wgcGxhbmUgKGUuZy4g SUdQL0JHUCkgdG8gDQo+Pj4+ZHluYW1pY2FsbHkgZGlzY292ZXIgdG9wb2xvZ3k7IGZvcndhcmRp bmcgcGF0aHM7IHByb3RlY3Rpb24gcGF0aHM7IA0KPj4+PnJlc3RvcmF0aW9uIHBhdGhzLCBldGMu IFRvZGF5LCBhbGwgcm91dGVycyBhcmUgY29ubmVjdGVkIHRvZ2V0aGVyIGJ5IA0KPj4+Pmxpbmtz LiBUaGVpciB0b3BvbG9neSBpcyBtb3JlIGxpa2UgYSBtZXNoZWQgZ3JhcGggdGhhbiBjaGFpbi4g U28gDQo+Pj4+d2hlbiB5b3UgY2hhaW4gUm91dGVyLTE8LT5Sb3V0ZXItMjwtPlJvdXRlci0zLCBh cmUgeW91IHRhbGtpbmcgYWJvdXQgDQo+Pj4+c291cmNlIHJvdXRpbmc/IFRoZXJlZm9yZSwgbmVl ZCBhIGNsZWFyIGRlZmluaXRpb24gb24gd2hhdCBkb2VzIGl0IA0KPj4+PnJlYWxseSBtZWFuIGJ5 IGNoYWluaW5nIExheWVyIDIvMyBzZXJ2aWNlIG5vZGVzLg0KPj4+PiANCj4+Pj4gTGluZGENCj4+ Pj4gDQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogVGhvbWFz IE5hZGVhdSBbbWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29tXQ0KPj4+Pj4gU2VudDogVHVl c2RheSwgU2VwdGVtYmVyIDAzLCAyMDEzIDU6MjggUE0NCj4+Pj4+IFRvOiBMaW5kYSBEdW5iYXIN Cj4+Pj4+IENjOiBuc2NAaWV0Zi5vcmc7IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBTdGV3YXJ0 IEJyeWFudCANCj4+Pj4+IChzdGJyeWFudCk7IFRob21hcyBOYXJ0ZW47IGFkcmlhbkBvbGRkb2cu Y28udWsNCj4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBOU0MgQm9GIE91dGNvbWVzDQo+Pj4+PiAN Cj4+Pj4+IA0KPj4+Pj4gT24gU2VwIDMsIDIwMTM6NjoyNSBQTSwgYXQgNjoyNSBQTSwgTGluZGEg RHVuYmFyIA0KPj4+Pj4gPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4+IA0K Pj4+Pj4+IFRob21hcywNCj4+Pj4+PiANCj4+Pj4+PiBBcmUgeW91IHNheWluZyB0aGF0IHRoZSBO U0Mgc2NvcGUgaW5jbHVkZXMgY2hhaW5pbmcgTGF5ZXIgMiwgDQo+Pj4+Pj4gTGF5ZXINCj4+Pj4+ PiAzDQo+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucywgTGF5ZXIgNCB0byBMYXllciA3IHNlcnZpY2Ug ZnVuY3Rpb25zLCBhbmQgDQo+Pj4+PiB2YXJpb3VzIGNvbWJpbmF0aW9uIG9mIHRoZW0/DQo+Pj4+ PiANCj4+Pj4+ICAgIEkgZG9uJ3QgZGVmaW5lIHRoZSBzY29wZTsgdGhhdHMgdXAgdG8gdGhlIEFE cy4NCj4+Pj4+IA0KPj4+Pj4gICAgQ291bGQgeW91IHBsZWFzZSBhbnN3ZXIgdGhlIHF1ZXN0aW9u IGJlbG93Pw0KPj4+Pj4gDQo+Pj4+PiAgICAtLVRvbQ0KPj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4g TGluZGENCj4+Pj4+PiANCj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+ Pj4gRnJvbTogVGhvbWFzIE5hZGVhdSBbbWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29tXQ0K Pj4+Pj4+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDMsIDIwMTMgNToxOSBQTQ0KPj4+Pj4+ PiBUbzogTGluZGEgRHVuYmFyDQo+Pj4+Pj4+IENjOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsg YWRyaWFuQG9sZGRvZy5jby51azsgbnNjQGlldGYub3JnOyANCj4+Pj4+Pj4gVGhvbWFzIE5hcnRl bjsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KQ0KPj4+Pj4+PiBTdWJqZWN0OiBSZTogW25zY10g TlNDIEJvRiBPdXRjb21lcw0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IE9uIFNlcCAzLCAy MDEzOjU6NTQgUE0sIGF0IDU6NTQgUE0sIExpbmRhIER1bmJhciANCj4+Pj4+Pj4gPGxpbmRhLmR1 bmJhckBodWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBNeSBjb21tZW50cyBh cmUgaW5zZXJ0ZWQgYmVsb3cgbWFya2VkIGJ5IFtMaW5kYV06DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+Pj4gSG93ZXZlciwgaXQgd2FzIGxlc3MgY2xlYXIgdG8gbWUgdGhhdCB0aGVyZSBpcyBh Z3JlZW1lbnQgDQo+Pj4+Pj4+Pj4+IGFib3V0DQo+Pj4+PiB0aGUNCj4+Pj4+Pj4+PiBsYXllcg0K Pj4+Pj4+Pj4+PiBpbg0KPj4+Pj4+Pj4+PiB3aGljaCBzZXJ2aWNlIGNoYWluaW5nIGhhcyB0byBi ZSBzb2x2ZWQuIEkgZmVsdCB0aGF0IHNvbWUgDQo+Pj4+Pj4+Pj4+IHBlb3BsZSB3ZXJlIHRhbGtp bmcgYWJvdXQgc2VydmljZSBjaGFpbmluZyBpbiB0aGUgYXBwbGljYXRpb24gDQo+Pj4+Pj4+Pj4+ IGxheWVyLA0KPj4+Pj4gc29tZQ0KPj4+Pj4+Pj4+PiBhYm91dCBzZXJ2aWNlIGNoYWluaW5nIGJh c2VkIG9uIGZsb3dzLCBhbmQgc29tZSBhYm91dCANCj4+Pj4+Pj4+Pj4gcGVyLXBhY2tldCBzZXJ2 aWNlcy4gVGhlIHNvbHV0aW9ucyBhcmUsDQo+Pj4+Pj4+Pj4gSQ0KPj4+Pj4+Pj4+PiB0aGluaywN Cj4+Pj4+Pj4+Pj4gbGlrZWx5IHRvIGJlIHZlcnkgZGlmZmVyZW50IGZvciB0aGUgZGlmZmVyZW50 IHByb2JsZW1zLCBhbmQgDQo+Pj4+Pj4+Pj4+IGl0DQo+Pj4+Pj4+IHdvdWxkDQo+Pj4+Pj4+Pj4g YmUNCj4+Pj4+Pj4+Pj4gd3JvbmcgdG8NCj4+Pj4+Pj4+Pj4gdHJ5IHRvIGJ1bmNoIHRoZW0gYWxs IHRvZ2V0aGVyLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEppbT4gYWx0aG91Z2ggdGhlcmUgd2Fz IGNlcnRhaW5seSBpbml0aWFsIGNvbmZ1c2lvbiBJIGJlbGlldmUgDQo+Pj4+Pj4+Pj4gSmltPiB0 aGlzDQo+Pj4+Pj4+IGlzDQo+Pj4+Pj4+Pj4gYmVjb21pbmcgbGVzcyBhbmQgbGVzcyBzbyBhcyB3 ZSBzb2NpYWxpemUgdGhlIGJhc2ljIGlkZWEgb2YNCj4+Pj4+IHNlcnZpY2UNCj4+Pj4+Pj4+PiBj aGFpbmluZzsgaW5kZWVkLCBhcyB3ZSBtb3ZlIGZvcndhcmQgd2Ugd2lsbCByZWZsZWN0IGEgbW9y ZSANCj4+Pj4+Pj4+PiBjb21tb24gdW5kZXJzdGFuZGluZyB3aXRoaW4gdGhlIHByb2JsZW0gc3Rh dGVtZW50Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBJdCBpcyBzdGlsbCBub3QgY2xlYXIgd2hpY2gg bGF5ZXIgc2VydmljZSBmdW5jdGlvbnMgYXJlIGNoYWluZWQNCj4+Pj4+Pj4gdG9nZXRoZXIuIFRo ZSBkcmFmdC1xdWlubi1uc2MtcHJvYmxlbS1zdGF0ZW1lbnQtMDMgZGlzY3Vzc2VkDQo+Pj4+PiBj aGFpbmluZw0KPj4+Pj4+PiBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IGNhbiBiZSBhIG5ldHdv cmsgb3IgYXBwbGljYXRpb24gYmFzZWQgDQo+Pj4+Pj4+IHBhY2tldCB0cmVhdG1lbnQsLi4uLCB0 byBlbmFibGUgYSBzZXJ2aWNlIG9mZmVyZWQgYnkgYSBuZXR3b3JrDQo+Pj4+PiBvcGVyYXRvcnMu DQo+Pj4+Pj4+IA0KPj4+Pj4+PiAgICBXaHkgZG8geW91IHRoaW5rIHRoYXQgbWF0dGVycz8NCj4+ Pj4+Pj4gDQo+Pj4+Pj4+PiBUb2RheSwgdGhlcmUgYXJlIG1hbnkgc2VydmljZXMgb2ZmZXJlZCBi eSBvcGVyYXRvcnMsIGUuZy4gDQo+Pj4+Pj4+PiBMMlZQTiwgTDNWUE4sIFAyUCBwYXRocywgZXRj LiBTbyB5b3UgY2FuIGludGVycHJldCBOU0MgYXMgDQo+Pj4+Pj4+PiBjaGFpbmluZw0KPj4+Pj4+ Pj4gTDIvTDMNCj4+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMgKGxpa2UgcHJveHkgZm9yd2FyZGlu Zywgb3IgZnJhZ21lbnRhdGlvbiwgIA0KPj4+Pj4+PmV0Yy4pOyBZb3UgY2FuIGFsc28gaW50ZXJw cmV0IE5TQyBhcyBjaGFpbmluZyBMNCAgKGFuZCBhYm92ZSkgIA0KPj4+Pj4+PnNlcnZpY2UgZnVu Y3Rpb25zOyBvciBjaGFpbmluZyBvZiBtaXhlZCBMNC1MNyBzZXJ2aWNlIGZ1bmN0aW9ucyAgDQo+ Pj4+Pj4+KGkuZS4gd2l0aCBzb21lIHNlcnZpY2Ugbm9kZXMgY29uc3VtaW5nIHBhY2tldHMgYW5k IHJlaW5pdGlhdGUgDQo+Pj4+Pj4+bmV3IHBhY2tldHMpLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gICAg WW91IGNhbiwgYW5kIHBlb3BsZSBhY3R1YWxseSBkbyBpbXBsZW1lbnQgdGhpcyB0b2RheS4NCj4+ Pj4+Pj4gDQo+Pj4+Pj4+PiBJcyBOU0MgaW5jbHVkaW5nIGFsbCBjaGFpbmluZyBvZiBhbGwgdGhv c2Ugc2VydmljZXM/DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IExheWVyIDIvMyBzZXJ2aWNlIGZ1bmN0 aW9uIGNoYWluaW5nIG1pZ2h0IHJlcXVpcmUgZGlmZmVyZW50IA0KPj4+Pj4+Pj4gc2NoZW1lcw0K Pj4+Pj4+PiB0aGFuIExheWVyIDQtNyBzZXJ2aWNlIGNoYWluaW5nLiBUaGVyZWZvcmUsIGl0IGlz IG1vcmUgZWZmZWN0aXZlIA0KPj4+Pj4+PiB0byBkZWZpbmUgdGhlbSBzZXBhcmF0ZWx5IHRvIG1h a2UgdGhlIGRpc2N1c3Npb24gbW9yZSBmb2N1c2VkLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gICAgSSBk byBub3QgdGhpbmsgc28uIEknZCBwcmVmZXIgdG8gbm90IG1ha2UgdGhpcyBvbmx5IGFzDQo+Pj4+ PiBjb21wbGljYXRlZA0KPj4+Pj4+PiBhcyBpdCBuZWVkcyB0byBiZSwgYW5kIG5vIG1vcmUuIFRo ZXJlIGFyZSBpbXBsZW1lbnRhdGlvbnMgb2YgDQo+Pj4+Pj4+IExheWVyDQo+Pj4+Pj4+IDIgYW5k IDMgY2hhaW5pbmcgdGhhdCBhcmUgYWxsIGRvbmUgd2l0aCB0aGUgc2FtZSANCj4+Pj4+Pj4gZW5j YXAvcHJvdmlzaW9uaW5nIHN5c3RlbXMuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAgICAtLVRvbQ0KPj4+ Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IExpbmRhIER1bmJhcg0KPj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4g bnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uc2MNCj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBuc2NAaWV0Zi5v cmcNCj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+ Pj4+Pj4gDQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4gDQo+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG5z YyBtYWlsaW5nIGxpc3QNCj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4NCj4+Pg0KPj4NCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5zYyBtYWlsaW5nIGxpc3QNCj5u c2NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0K Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+X19fIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+DQo+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIA0KPmNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCANCj5leHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciANCj5lcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSANCj5sZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyANCj5kJ2FsdGVyYXRpb24sIE9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgDQo+YWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4NCj5UaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCANCj5p bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3Qg YmUgDQo+ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4N Cj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIA0KPmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4NCj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgDQo+YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu DQo+VGhhbmsgeW91Lg0KPg0KDQo= From jguichar@cisco.com Wed Sep 4 10:37:16 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 4CFC211E81D1 for ; Wed, 4 Sep 2013 10:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 sCWLkucfAOxp for ; Wed, 4 Sep 2013 10:37:10 -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 0C14411E80F6 for ; Wed, 4 Sep 2013 10:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32479; q=dns/txt; s=iport; t=1378316230; x=1379525830; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=G+y5ot120aLFrF59/1YWyeDMEpGPf+Cm4gahE7/PwzM=; b=NIUEA9e9QwH/Z9WtOKkI++YFutbpkFIEALnLtXMX54zE1ujDZmDYCIz5 fKMm8mY6pl0T8uu2kV7j0bW7ccNDracuFP3FFuXXXu4GZrwFpyypNvC+S ifRG7Y+vxdOqA+8c17FtQGkFb18XJkhhwxgK4MReLhTXY0izG0ph8v81K 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAFNvJ1KtJXHA/2dsb2JhbABagkNENVHBRIEoFnSCJAEBAQQtQQQCFwEIEQECAQILCwsBBjkUAwYIAgQBEggTh2e6N44tgQIZBxcBCoMTgQADlBuVQIMggWlB X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208,217";a="255385024" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 04 Sep 2013 17:37:03 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r84Hb2r2022691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 17:37:02 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 12:37:02 -0500 From: "Jim Guichard (jguichar)" To: "mohamed.boucadair@orange.com" , "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1Ee0QgADYD4A= Date: Wed, 4 Sep 2013 17:37:01 +0000 Message-ID: <68B171751455884590F8E38E96416F363F675870@xmb-rcd-x01.cisco.com> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.249.237] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F675870xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 17:37:16 -0000 --_000_68B171751455884590F8E38E96416F363F675870xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Med, Comment inline .. From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Wednesday, September 4, 2013 10:05 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: NSC Working Group Charter Proposal Hi Jim, Thank you for preparing the text. I fully agree that, for the sake of interoperability, one standard track so= lution must be specified by the working group. I=92m fully supportive to me= ntion this in the charter and avoid that during the lifetime of the working= group multiple solutions are envisaged. I have some comments about the proposed deliverables and the proposed timin= g: (1) I don=92t think it is a good idea to split the requirements into multip= le documents. For the sake of consistency and also to have the big picture,= I suggest only one single document be chartered to record the requirements= . The requirements document should include functional requirements, managea= bility requirements (as per RFC5706) and security requirements. The full se= t of requirements should be taken into account during the design phase. (2) The specification effort should start once the requirements are almost = stable, not before. (3) I would remove the word =93metadata=94 from the milestones. Jim> this wording is directly associated to REQ#24 of draft-boucadair-chain= ing-requirements so would a replacement of "metadata" with "context data" w= ork for you? If not please suggest an alternative, other than removal ;-). (4) I personally don=92t see a value to add dedicated items for detailed us= e cases. There is already an undergoing effort in other fora; no need to ha= ve redundant effort in this space. Having an abstract description level in = the Problem Statement is sufficient IMHO. (5) I suggest to add a =93Analysis and Design Choices=94 document: Details = rated to design motivations and justifications will be recorded in the anal= ysis document while the specification document(s) focuses exclusively on th= e specification part. Past experience has shown that some questions are rai= sed multiple times during the lifetime of the wg and it is not sometimes ob= vious to find where the decision was made and for what reason. This kind of= details are hard (sometime) to find: either you need to check mailing list= archives, or contact the authors. I see the design analysis document as a = formal tool to record the consensus on controversial design issues. The doc= ument can also answer to =93why not my favourite solution=94 solve the prob= lem(s). (6) We don=92t know at this stage how many specification documents will be = needed. Perhaps only one Standard Track document will be required. I sugges= t we leave the decision on the exact number of Standard Track documents ope= n. To sum up: my suggestion is to go for this set of deliverables: (a) Problem Statement document (b) Framework document (terminology, functional elements, architecture, and= overall procedure) (c) Requirements document (d) Design Analysis document (e) Specification document(s) I wouldn=92t object if the first charter of the future WG covers only items= (a) to (d). An updated charter can be envisaged once the future WG has mor= e visibility on the detailed set of specification documents. Cheers, Med De : nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] De la part de Jim Guichard (jguichar) Envoy=E9 : mardi 3 septembre 2013 18:01 =C0 : nsc@ietf.org Objet : [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_68B171751455884590F8E38E96416F363F675870xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9557BA476ED24844911F49844F18D640@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Med,

Comment inline ..

From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com&g= t;
Date: Wednesday, September 4, 2013 = 10:05 AM
To: Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: NSC Working Group Char= ter Proposal

Hi Jim,

 

Thank you for preparing the text.

 

I fully agree that, for the sake of inte= roperability, one standard track solution must be specified by the working = group. I=92m fully supportive to mention this in the charter and avoid that during the lifetime of the working grou= p multiple solutions are envisaged.

 

I have some comments about the proposed = deliverables and the proposed timing:

 

(1) I don=92t think it is a good idea to= split the requirements into multiple documents. For the sake of consistenc= y and also to have the big picture, I suggest only one single document be chartered to record the requirements. = The requirements document should include functional requirements, manageabi= lity requirements (as per RFC5706) and security requirements. The full set = of requirements should be taken into account during the design phase.

 

(2) The specification effort should star= t once the requirements are almost stable, not before.

 

(3) I would remove the word =93metadata= =94 from the milestones.

Jim> this wordin= g is directly associated to REQ#24 of draft-boucadair-chaining-requirements= so would a replacement of "metadata" with "context data&quo= t; work for you? If not please suggest an alternative, other than removal ;-).

 

(4) I personally don=92t see a value to = add dedicated items for detailed use cases. There is already an undergoing = effort in other fora; no need to have redundant effort in this space. Having an abstract description level in th= e Problem Statement is sufficient IMHO.

 

(5) I suggest to add a =93Analysis and D= esign Choices=94 document: Details rated to design motivations and justific= ations will be recorded in the analysis document while the specification document(s) focuses exclusively on the sp= ecification part. Past experience has shown that some questions are raised = multiple times during the lifetime of the wg and it is not sometimes obviou= s to find where the decision was made and for what reason. This kind of details are hard (sometime) to find= : either you need to check mailing list archives, or contact the authors. I= see the design analysis document as a formal tool to record the consensus = on controversial design issues. The document can also answer to =93why not my favourite solution=94 solve = the problem(s).

 

(6) We don=92t know at this stage how ma= ny specification documents will be needed. Perhaps only one Standard Track = document will be required. I suggest we leave the decision on the exact number of Standard Track documents open. <= o:p>

 

To sum up: my suggestion is to go for th= is set of deliverables:

 

(a) Problem Statement document

(b) Framework document (terminology, fun= ctional elements, architecture, and overall procedure)

(c) Requirements document

(d) Design Analysis document=

(e) Specification document(s= )

 

I wouldn=92t object if the first charter= of the future WG covers only items (a) to (d). An updated charter can be e= nvisaged once the future WG has more visibility on the detailed set of specification documents.

 

Cheers,

Med

 

 

De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoy=E9 : mardi 3 septembre 2013 18:01
=C0 : nsc@ietf.org
Objet : [nsc] NSC Working Group Charter Proposal

 

Greetings,

 

As we look forward to the formation of a wo= rking group that will focus on network service chaining, I would like to pr= opose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing = area AD's. The following is a first draft of the charter and I invite you t= o actively participate and provide inputs into this process.

 

Proposed NSC WG Charter 

Existing service insertion and deployment t= echniques have not evolved to meet modern network architectures and do not = reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks,= servers, storage, and applications, have all undergone significant change = in recent years: virtualization, network overlays, and orchestration are in= creasingly the norm. All of these have profound effects on network and services design.

 

Today, deploying new services, or making ch= anges to existing services, often requires network topology changes. Adding= and removing service functions is a complex, risky task, that is tied to operationalizing topological changes = leading to mostly-static service definitions. New service insertion and dep= loyment techniques must enable the concept of service functions as shared r= esources, and enable the linkage of these resources using service chains that represent the abstracted view= of the required service functions, and define the order in which they shou= ld be applied. When a service chain is instantiated in a network, specific = instances of service functions are selected, and a service topology is created and used for forwarding packet= s through the service chain.

 

A basic service chain might simply utilize = an existing overlay technology to force traffic through the necessary servi= ce functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chaining (NSC) working = group focuses on new approaches to service insertion and deployment, provid= ing a framework for the construction of services built using service chains. The WG focuses on the necessary pr= otocols for the creation of service chains, and the passing of metadata fro= m the network to service functions, and between service functions. When pos= sible, the WG will extend existing protocols to provide service chaining functionality, and any protocol exte= nsions will be reviewed by both the Network Service Chaining WG and by the = WG responsible for the protocol being extended.  

 

Specifically, the Network Service Chaining = WG is chartered to deliver the following work items: 

 

1) Problem Statement: this document will pr= ovide a summary of the problem space to be addressed by the Network Service= Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclatur= e and definitions for Network Service Chaining.

 

2) System Architecture: this set of documen= ts will provide a description of the architecture building blocks and their= relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Plane: this docume= nt will describe on the wire data plane encapsulation in support of (2). &n= bsp;A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this document will addres= s service chaining operation, monitoring and troubleshooting including rele= vant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they ar= e realized.

 

Proposed Milestones:

 

Dec 2013 Request publication of an Informat= ional document defining the Network Service Chaining problem statement to t= he IESG

 

Mar 2014 Request publication of information= al documents defining the system architecture including protocol requiremen= ts and framework to the IESG

 

May 2014 Request publication of a Standards= Track document specifying the data-plane (including metadata) for Service = Chaining to IESG

 

May 2014 Request publication of an informat= ional document specifying Service Chaining Control Plane requirements to IE= SG

 

Dec 2014 Request publication of information= al documents defining Service Chaining manageability requirements including= MIBs, OAM, and information models to IESG 

 

 

 --_000_68B171751455884590F8E38E96416F363F675870xmbrcdx01ciscoc_-- From jguichar@cisco.com Wed Sep 4 10:38: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 3D6AB21E80E2 for ; Wed, 4 Sep 2013 10:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 rWj7bOxzx1rw for ; Wed, 4 Sep 2013 10:38:32 -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 9E70121E804D for ; Wed, 4 Sep 2013 10:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21044; q=dns/txt; s=iport; t=1378316311; x=1379525911; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GpXMiJow2V2RptJBb7/TotSPxE0soE40PnOGCbsk/pw=; b=hwyGajnNWLW+oagGAvC3RvV+mA8mBBTuJAbHmWQ+3XKy1SOaRHW4qvWV u58fK0RdrAFTGZm9udhaR/T/7WVMZHSIvU7l1PLKLlzjrlG61wJ2NbA1d GqGqwVcYa9gfDU2W3q2Rt7J4csX5DvA3ibLXqU0aezWVAgpeO/Xt9wErg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAFNvJ1KtJXHA/2dsb2JhbABQCoMHNVGDKL4cF4ERFnSCJAEBAQQBAQEgBA06BAcMBgEIEQQBAQECAgYdAwIEJQsUAQgIAgQBDQUIE4dnDKgxkXYEgSmMbgaBEAIGEBsHAgICgmM0gQADqVuDIIFxOQ X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208";a="255552420" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 04 Sep 2013 17:38:29 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r84HcSHx024453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 17:38:28 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 12:38:28 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker , Jerome Moisand , "christian.jacquenet@orange.com" Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: Ac6YFyk/aYEs8EPbQVuX5dlVLbZ5nAQ1EMqAAAutBgAAANR+AAAAPryAAAATX4AAALROgAAEGq4AAAqrvDYAEOzoAP//wwOAgABZ5QD//8HmAIAADuoggAA6MAD//84YgIAARwiA//++JoA= Date: Wed, 4 Sep 2013 17:38:27 +0000 Message-ID: <68B171751455884590F8E38E96416F363F675893@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.82.249.237] Content-Type: text/plain; charset="utf-8" Content-ID: <6E5895A09164CC4AA2FB3F8CC95E2E9C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nsc@ietf.org" , Thomas Nadeau , Thomas Narten , "adrian@olddog.co.uk" , Linda Dunbar , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 17:38:37 -0000 QWdyZWVkIFJvbi4gQWxzbywgcGVyc29uYWxseSBJIHRoaW5rIHdlIHdpbGwgZmluZCB0aGF0IHRo ZSBudW1iZXIgb2YNCnJlcXVpcmVtZW50cyBmb3IgYm90aCBkYXRhIGFuZCBjb250cm9sIHBsYW5l cyB3aWxsIG5lY2Vzc2l0YXRlIHRoZSBuZWVkDQpmb3IgdHdvIHNlcGFyYXRlIGRvY3VtZW50cyBi dXQgSSBhbSBoYXBweSB0byB3YWl0IGZvciB0aGUganVyeSBvbiB0aGF0IG9uZQ0KOy0pDQoNCk9u IDkvNC8xMyAxOjM0IFBNLCAiUm9uIFBhcmtlciIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jr cy5jb20+IHdyb3RlOg0KDQo+SmltLA0KPg0KPlRoYXQgc291bmRzIGZpbmUgdG8gbWUuICAgSSB3 YW50ZWQgdG8gZW1waGFzaXplIHRoZSBpZGVhIHRoYXQgY29udHJvbA0KPnBsYW5lIHNob3VsZCBu b3QgYmUgY29uc2lkZXJlZCBtYW5kYXRvcnkgdG8gcmVhbGl6ZSBhIG5ldHdvcmsgc2VydmljZQ0K PmNoYWluaW5nIGRlcGxveW1lbnQsIGFuZCBJIGZlZWwgdGhhdCB0aGF0IGNvbmNlcHQgaXMgbm93 IG9uIHRoZSB0YWJsZS4NCj4NCj5UaGFua3MuDQo+DQo+ICAgIFJvbg0KPg0KPg0KPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0 bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+U2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIw MTMgMToyMCBQTQ0KPlRvOiBKZXJvbWUgTW9pc2FuZDsgY2hyaXN0aWFuLmphY3F1ZW5ldEBvcmFu Z2UuY29tOyBSb24gUGFya2VyDQo+Q2M6IG5zY0BpZXRmLm9yZzsgVGhvbWFzIE5hZGVhdTsgTGlu ZGEgRHVuYmFyOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOw0KPlRob21hcyBOYXJ0ZW47IFN0ZXdhcnQg QnJ5YW50IChzdGJyeWFudCkNCj5TdWJqZWN0OiBSZTogW25zY10gTlNDIEJvRiBPdXRjb21lcw0K Pg0KPkxldCBtZSBzdWdnZXN0IHRoYXQgd2Uga2VlcCBhIHNpbmdsZSByZXF1aXJlbWVudHMgZG9j dW1lbnQgZm9yIG5vdyBhbmQNCj5wZXJoYXBzIHNwbGl0IGludG8gc2VwYXJhdGUgZGF0YSBhbmQg Y29udHJvbCBwbGFuZSBkb2N1bWVudHMgc2hvdWxkIHRoYXQNCj5iZWNvbWUgbmVjZXNzYXJ5IGFz IHRoZSBzaW5nbGUgZG9jdW1lbnQgZXZvbHZlcy4NCj4NCj5PbiA5LzQvMTMgMTI6MTggUE0sICJK ZXJvbWUgTW9pc2FuZCIgPGptb2lzYW5kQGp1bmlwZXIubmV0PiB3cm90ZToNCj4NCj4+SSB3b3Vs ZCB0ZW5kIHRvIGFncmVlIHdpdGggQ2hyaXN0aWFuLCByZXF1aXJlbWVudHMgc2hvdWxkIGJlIGFi b3V0IHRoZQ0KPj5vdmVyYWxsIHByb2JsZW0gdG8gc29sdmUuIFBsdXMgYSBjb250cm9sIHBsYW5l IHRlbmRzIHRvIGNvbnRyb2wuLi4gdGhlDQo+PmRhdGEgcGxhbmUhIFNvIGJldHRlciB3b3JrIG9u IHJlcXVpcmVtZW50cyB3aGljaCB3b3VsZCBiZSBjb25zaXN0ZW50DQo+PmVub3VnaCB0byBhY2tu b3dsZWRnZSBzdWNoIHJlbGF0aW9uc2hpcC4NCj4+DQo+Pk5vdywgSSBhbHNvIGFncmVlIHdpdGgg Um9uIHRoYXQgYSBjb250cm9sIHBsYW5lIG1heSBub3QgYmUgcmVxdWlyZWQgaW4NCj4+YWxsIGNh c2VzLiBUaGlzIHNob3VsZCBwcm9iYWJseSBiZSBhIHJlcXVpcmVtZW50LCBhY3R1YWxseSwgdG8g bm90DQo+Pm1hbmRhdGUgYSBjb250cm9sIHBsYW5lIGluIGFsbCBjYXNlcyENCj4+DQo+Pi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IGNocmlzdGlhbi5qYWNxdWVuZXRAb3Jhbmdl LmNvbQ0KPj5bbWFpbHRvOmNocmlzdGlhbi5qYWNxdWVuZXRAb3JhbmdlLmNvbV0NCj4+U2VudDog V2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTMgMTI6MDQgUE0NCj4+VG86IEppbSBHdWljaGFy ZCAoamd1aWNoYXIpOyBSb24gUGFya2VyOyBKZXJvbWUgTW9pc2FuZA0KPj5DYzogbnNjQGlldGYu b3JnOyBUaG9tYXMgTmFkZWF1OyBMaW5kYSBEdW5iYXI7IGFkcmlhbkBvbGRkb2cuY28udWs7DQo+ PlRob21hcyBOYXJ0ZW47IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFudCkNCj4+U3ViamVjdDogUkU6 IFtuc2NdIE5TQyBCb0YgT3V0Y29tZXMNCj4+DQo+PkhpKiwNCj4+DQo+Pkkgc3VwcG9ydCB0aGUg cHVibGljYXRpb24gb2YgYSBzaW5nbGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50IChmb3IgdGhlDQo+ PnNha2Ugb2YgY29uc2lzdGVuY3kpLCBhbmQgd2hpY2ggd291bGQgaW5jbHVkZSBib3RoIGNvbnRy b2wgYW5kIGRhdGENCj4+cGxhbmUgY29uc2lkZXJhdGlvbnMgYW1vbmcgb3RoZXIgdG9waWNzLg0K Pj4NCj4+Q2hlZXJzLA0KPj4NCj4+Q2hyaXN0aWFuLg0KPj4NCj4+LS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+PkRlIDogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNl c0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZQ0KPj5KaW0gR3VpY2hhcmQgKGpndWljaGFyKSBFbnZv ecOpIDogbWVyY3JlZGkgNCBzZXB0ZW1icmUgMjAxMyAxNzo1NyDDgCA6DQo+PlJvbiBQYXJrZXI7 IEplcm9tZSBNb2lzYW5kIENjIDogbnNjQGlldGYub3JnOyBUaG9tYXMgTmFkZWF1OyBMaW5kYQ0K Pj5EdW5iYXI7IGFkcmlhbkBvbGRkb2cuY28udWs7IFRob21hcyBOYXJ0ZW47IFN0ZXdhcnQgQnJ5 YW50IChzdGJyeWFudCkNCj4+T2JqZXQgOiBSZToNCj4+W25zY10gTlNDIEJvRiBPdXRjb21lcw0K Pj4NCj4+SXMgdGhlIHN1Z2dlc3Rpb24gdGhlcmVmb3JlIHRoYXQgc2VwYXJhdGUgZGF0YSBhbmQg Y29udHJvbCBwbGFuZQ0KPj5yZXF1aXJlbWVudHMgSS1EJ3Mgc2hvdWxkIGJlIGNyZWF0ZWQgcmF0 aGVyIHRoYW4gYW4gb3ZlcmFsbA0KPj5yZXF1aXJlbWVudHMgZG9jdW1lbnQgY292ZXJpbmcgYm90 aD8NCj4+DQo+Pk9uIDkvNC8xMyAxMTozOSBBTSwgIlJvbiBQYXJrZXIiIDxSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tPiB3cm90ZToNCj4+DQo+Pj5KaW0sDQo+Pj4NCj4+PkkgYWdyZWUg dGhhdCB0aGUgY2hhcnRlciBzaG91bGQgbm90IGJlIHRvbyBzcGVjaWZpYyBvbiB0aGUgZGVzaWdu IG9mDQo+Pj50aGUgY29udHJvbCBwbGFuZSwgYnV0IHJhdGhlciB0byByZWNvZ25pemUgdGhhdCBv bmUgY291bGQgYmUNCj4+PmFkdmFudGFnZW91cyAoYWx0aG91Z2ggbm90IG5lY2Vzc2FyaWx5IHJl cXVpcmVkKSBmb3IgdGhlIG92ZXJhbGwNCj4+PnNlcnZpY2UgY2hhaW5pbmcNCj4+PnNvbHV0aW9u LiAgICBBIGNvbnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzIGFuZC9vciB1c2UgY2FzZXMgZG9jdW1l bnQNCj4+PnNob3VsZCBwcmVjZWRlIGFueSBjb250cm9sIHBsYW5lIHByb3RvY29sIGRlc2lnbiBv ciBzZWxlY3Rpb24uDQo+Pj4NCj4+PiAgIFJvbg0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpn dWljaGFyQGNpc2NvLmNvbV0NCj4+PlNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDA0LCAyMDEz IDEwOjE3IEFNDQo+Pj5UbzogSmVyb21lIE1vaXNhbmQ7IFJvbiBQYXJrZXINCj4+PkNjOiBuc2NA aWV0Zi5vcmc7IFRob21hcyBOYWRlYXU7IFRob21hcyBOYXJ0ZW47IGFkcmlhbkBvbGRkb2cuY28u dWs7DQo+Pj5MaW5kYSBEdW5iYXI7IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFudCkNCj4+PlN1Ympl Y3Q6IFJlOiBbbnNjXSBOU0MgQm9GIE91dGNvbWVzDQo+Pj4NCj4+PkhpIEplcm9tZSwNCj4+Pg0K Pj4+TXkgYmFkIC4uIFJlc3BvbmRpbmcgdG8geW91ciBQUyA7KSDFoCBSaWdodCBub3cgdGhlIGNo YXJ0ZXIgc3VnZ2VzdHMNCj4+PnRoYXQgdGhlIFdHIGJlIHJlc3BvbnNpYmxlIGZvciBkZWZpbmlu ZyB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZQ0KPj4+Y29udHJvbCBwbGFuZSB3aXRoIHJlc3BlY3Qg dG8gc2VydmljZSBjaGFpbmluZy4gVGhlIHByb2JsZW0gaGVyZSBpcyBvZg0KPj4+Y291cnNlIHRo YXQgdGhlcmUgYXJlIG11bHRpcGxlIGNvbnRyb2wgcGxhbmVzLiBJbiBteSBtaW5kIGl0IG1ha2Vz DQo+Pj5saXR0bGUgc2Vuc2UgdG8gdHJ5IGFuZCB0YWNrbGUgdGhlbSBhbGwgYnV0IHJhdGhlciBk ZWZpbmUgd2hhdCBpcw0KPj4+bmVjZXNzYXJ5IGZvciBhIGNvbnRyb2wgcGxhbmUgdG8gaW1wbGVt ZW50IHRvIHN1Y2Nlc3NmdWxseSBlbmFibGUNCj4+PnNlcnZpY2UgY2hhaW5zIGFuZCB0aGVuIGxp YWlzZSB3aXRoIG90aGVyIFdHJ3Mgb24gdGhlIGRldGFpbHMuDQo+Pj4NCj4+PlNvbWUgZnVydGhl ciBjb21tZW50cyBpbmxpbmUuDQo+Pj4NCj4+Pk9uIDkvNC8xMyA5OjU1IEFNLCAiSmVyb21lIE1v aXNhbmQiIDxqbW9pc2FuZEBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+Pj4NCj4+Pj5JdCBzZWVtcyB0 byBtZSB0aGF0IHRoZSBlbnRpcmUgcG9pbnQgb2Ygc2VydmljZSBjaGFpbmluZyBpcyBpbmRlZWQg dG8NCj4+Pj5jaGFpbiB0b2dldGhlciBoZXRlcm9nZW5lb3VzIHNlcnZpY2UtZW5hYmxpbmcgZWxl bWVudHMsIGFuZCBtYWtlIHRoZQ0KPj4+PmJlc3Qgb3V0IG9mIHN1Y2ggY29tYm8uDQo+Pj4NCj4+ PkppbT4gZXhhY3RseS4gVGhlIHBvaW50IGJlaW5nIHNlcGFyYXRlIHNlcnZpY2UgZnVuY3Rpb25z IGludG8gYQ0KPj4+SmltPiByZXNvdXJjZQ0KPj4+cG9vbCB0aGF0IGNhbiBiZSB1dGlsaXplZCBh bmQgbm90IGNvbnN0cmFpbmVkIGJhc2VkIG9uIHRvcG9sb2d5Lg0KPj4+DQo+Pj4+IA0KPj4+Pg0K Pj4+PlNlcnZpY2UgRWRnZSByb3V0ZXJzIChpbmNsdWRpbmcgQml6LVBFcywgQk5HcyBhbmQgTW9i aWxlIEdXcykgZW5hYmxlDQo+Pj4+TDMgc2VydmljZXMsIG9uIGEgcGVyIHN1YnNjcmliZXIgYmFz aXMuIEZpcmV3YWxscyBjYW4gYWN0IGVpdGhlciBhdA0KPj4+PkwzL0w0IG9yDQo+Pj4+TDQvTDcg KGUuZy4gYWRkaW5nIHNvbWUgSW50cnVzaW9uIERldGVjdGlvbiB0byB0aGUgbWl4KS4gRFBJIG9y IEhUVFANCj4+Pj5Qcm94aWVzL0ZpbHRlcnMgZW5naW5lcyBhY3QgYXQgTDcuIFNlc3Npb24gQm9y ZGVyIENvbnRyb2xsZXJzIGFjdCBhdA0KPj4+Pkw3LCBhbHRob3VnaCB0aGV5IGRvIHNvbWUgTDMv TDQgcHJvY2Vzc2luZyB0b28gKE5BVCkuIEFsbCB0aG9zZQ0KPj4+PnZhcmlvdXMgZWxlbWVudHMg aGF2ZSB0aGVpciBvd24gc3RyZW5ndGhzIGluIHRlcm1zIG9mIHRyYWZmaWMNCj4+Pj5jbGFzc2lm aWNhdGlvbiBhbmQgaW4gdGVybXMgb2YgcG9saWN5IGVuZm9yY2VtZW50LiBXaGljaCBjYW4gY29t YmluZWQNCj4+Pj5pbiBzbWFydCB3YXlzIChlLmcuDQo+Pj4+dXNlIERQSSB0byBpZGVudGlmeS9j bGFzc2lmeSBhbiBhcHBsaWNhdGlvbiBmbG93LCB1c2UgYW4gZWRnZSByb3V0ZXINCj4+Pj50byBw ZXJmb3JtIGZhbmN5IHF1ZXVpbmcgYmFzZWQgb24gc3VjaCBEUEkgY2xhc3NpZmljYXRpb24gYW1v bmcgb3RoZXINCj4+Pj50cmFmZmljIGZsb3dzKS4NCj4+Pg0KPj4+SmltPiB5ZXAuIA0KPj4+DQo+ Pj4+IA0KPj4+Pg0KPj4+PlRoZSBiZWF1dHkgb2Ygc2VydmljZSBjaGFpbmluZyBpcyB0byBjb21i aW5lIGFsbCB0aG9zZSBlbGVtZW50cyB0bw0KPj4+Pm1ha2Ugc29tZXRoaW5nIHRydWx5IHVzZWZ1 bCAoZS5nLiBwcm92aWRlIGEgbW9yZSBjb21wbGV4IFNlcnZpY2UNCj4+Pj4td2l0aCBhIGNhcGl0 YWwgJ1MnLSB0byBzZXJ2aWNlIHByb3ZpZGVyIHVzZXJzIG9yIGVudGVycHJpc2UgdXNlcnMpLg0K Pj4+PkFsbCB0aGUgdXNlIGNhc2VzIEkndmUgaGVhcmQgc28gZmFyIGZyb20gdmFyaW91cyBwYXJ0 aWVzIGRvIG1peCBlZGdlDQo+Pj4+cm91dGVycywgc2VjdXJpdHkgYW5kIGFwcGxpY2F0aW9uLW9y aWVudGVkIGVsZW1lbnRzLg0KPj4+Pg0KPj4+PlNvLi4uIEkgd291bGQgbm90IGJlIHN1cHBvcnRp dmUgdG8gdHJ5aW5nIHRvIHNlcGFyYXRlIGEgZm9ybSBvZiBMMi9MMw0KPj4+PmNoYWluaW5nIGZy b20gYSBmb3JtIG9mIEw0L0w3IGNoYWluaW5nLiBPbiB0aGUgY29udHJhcnkhIDstKQ0KPj4+Pg0K Pj4+Pkkgd291bGQgYWN0dWFsbHkgZ28gYXMgZmFyIGFzIHN1Z2dlc3RpbmcgdGhhdCB3ZSBzaG91 bGQgbWFrZSBjbGVhcmVyDQo+Pj4+aW4gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGhhdCB0aGlzIGlz IGEgc3Ryb25nIGdvYWwsIHRvIGRlYWwgd2l0aCBzdWNoDQo+Pj4+aGV0ZXJvZ2VuZW91cyBjb21i b3MuDQo+Pj4NCj4+PkppbT4gYW55IHRleHQgYW5kIHN1Z2dlc3Rpb24gb2Ygd2hlcmUgdG8gaW5z ZXJ0IGludG8gdGhlIGNoYXJ0ZXI/DQo+Pj4NCj4+Pj4NCj4+Pj5KdXN0IG15IDIgY2VudHMsDQo+ Pj4+SmVyb21lDQo+Pj4+DQo+Pj4+PT09PQ0KPj4+PlRvdGFsbHkgdW5yZWxhdGVkIFBTIGZvciBK aW06IHlvdSBkaWRuJ3QgYW5zd2VyIG15IHF1ZXN0aW9uIGFib3V0IHRoZQ0KPj4+PmNvbnRyb2wg cGxhbmUgYXNwZWN0cywgdGhpcyBtYXkgaGF2ZSBzbGlwcGVkIHRocm91Z2ggdGhlIGNyYWNrcyEg Oy0pDQo+Pj4+DQo+Pj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj5Gcm9tOiBKaW0g R3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCj4+Pj5TZW50 OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMyA2OjUxIEFNDQo+Pj4+VG86IFJvbiBQYXJr ZXINCj4+Pj5DYzogbnNjQGlldGYub3JnOyBUaG9tYXMgTmFkZWF1OyBUaG9tYXMgTmFydGVuOyBh ZHJpYW5Ab2xkZG9nLmNvLnVrOw0KPj4+PkxpbmRhIER1bmJhcjsgU3Rld2FydCBCcnlhbnQgKHN0 YnJ5YW50KQ0KPj4+PlN1YmplY3Q6IFJlOiBbbnNjXSBOU0MgQm9GIE91dGNvbWVzDQo+Pj4+DQo+ Pj4+VGhlIHNhbWUgYXJndW1lbnQgY291bGQgYmUgYXBwbGllZCBmb3IgZmlyZXdhbGxzIGFzIHdp dGhvdXQgdGhlbQ0KPj4+PnBhY2tldHMgd291bGQgZ2V0IHJvdXRlZCBpbnN0ZWFkIG9mIHBlcmhh cHMgZHJvcHBlZC4NCj4+Pj4NCj4+Pj5TZW50IGZyb20gbXkgaVBob25lDQo+Pj4+DQo+Pj4+T24g U2VwIDMsIDIwMTMsIGF0IDg6NDUgUE0sICJSb24gUGFya2VyIg0KPj4+PjxSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tPiB3cm90ZToNCj4+Pj4NCj4+Pj4+IEhpLCBMaW5kYS4NCj4+Pj4+ IA0KPj4+Pj4gV2l0aCByZXNwZWN0IHRvOg0KPj4+Pj4gDQo+Pj4+PiAgICAtIExheWVyIDQgdG8g TGF5ZXIgNyBzZXJ2aWNlIGZ1bmN0aW9ucyAob3Igc2VydmljZSBub2RlcykgYXJlIHRvDQo+Pj4+ PmFwcGx5IGFjdGlvbnMgdG8gZGF0YSBwYWNrZXRzIHRyYXZlcnNpbmcgdGhyb3VnaC4gVGhleSBk b24ndCBpbXBhY3QNCj4+Pj4+b3ZlcmFsbCBuZXR3b3JrIHRvcG9sb2dpZXMvcm91dGVzL3Jlc3Rv cmF0aW9ucy4NCj4+Pj4+IA0KPj4+Pj4gTGF5ZXIgNC03IHNlcnZpY2VzIGNhbiwgaW5kZWVkLCBp bXBhY3Qgcm91dGluZyBkZWNpc2lvbnMuICBGb3INCj4+Pj4+ZXhhbXBsZSwgaWYgdGhlIHNlcnZp Y2UgaXMgRFBJIGFuYWx5c2lzLCB0aGVuIGEgZGV0ZWN0ZWQgcHJvdG9jb2wNCj4+Pj4+bWF5IGNh dXNlIHRoZSBzdWJzZXF1ZW50IHBhY2tldHMgdG8gYmUgcG9saWN5IHJvdXRlZCBvbiBhIHBhdGgN Cj4+Pj4+ZGlmZmVyZW50IHRoYW4gdGhlIFNQRiBwYXRoLg0KPj4+Pj4gDQo+Pj4+PiAgIFJvbg0K Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBG cm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYNCj4+Pj4+IE9mIExpbmRhIER1bmJhcg0KPj4+Pj4gU2VudDogVHVlc2RheSwgU2Vw dGVtYmVyIDAzLCAyMDEzIDY6NDggUE0NCj4+Pj4+IFRvOiBUaG9tYXMgTmFkZWF1DQo+Pj4+PiBD YzogbnNjQGlldGYub3JnOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgVGhvbWFzIE5hcnRlbjsN Cj4+Pj4+IGFkcmlhbkBvbGRkb2cuY28udWs7IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFudCkNCj4+ Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBOU0MgQm9GIE91dGNvbWVzDQo+Pj4+PiANCj4+Pj4+IEhl cmUgYXJlIHNvbWUgb2YgdGhlIHJlYXNvbnMgdGhhdCBjaGFpbmluZyBvZiBMYXllciAyIGFuZCAz IHNlcnZpY2UNCj4+Pj4+ZnVuY3Rpb25zIGFyZSBkaWZmZXJlbnQgZnJvbSBjaGFpbmluZyBvZiBM YXllciA0IHRvIDcgc2VydmljZQ0KPj4+Pj5mdW5jdGlvbnMgKEkgd2lsbCBhZGQgbW9yZSBsYXRl cik6DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gLSBMYXllciA0IHRvIExheWVyIDcgc2VydmljZSBm dW5jdGlvbnMgKG9yIHNlcnZpY2Ugbm9kZXMpIGFyZSB0bw0KPj4+Pj5hcHBseSBhY3Rpb25zIHRv IGRhdGEgcGFja2V0cyB0cmF2ZXJzaW5nIHRocm91Z2guIFRoZXkgZG9uJ3QgaW1wYWN0DQo+Pj4+ Pm92ZXJhbGwgbmV0d29yayB0b3BvbG9naWVzL3JvdXRlcy9yZXN0b3JhdGlvbnMuDQo+Pj4+PiAN Cj4+Pj4+IC0gTGF5ZXIgNC03IHNlcnZpY2UgZnVuY3Rpb25zIGRyb3AsIHBhc3MsIGNvbnN1bWUs IHJlLWluaXRpYXRlDQo+Pj4+PnBhY2tldHMsIGV0Yy4gVGhleSBkb24ndCBjaGFuZ2UgbmV0d29y ayB0b3BvbG9naWVzLCBhbmQgdGhleSBkb24ndA0KPj4+Pj5pbXBhY3QgbmV0d29yayByZXN0b3Jh dGlvbiBzY2hlbWUgKGUuZy4gZmFzdCByZS1yb3V0ZSkuICBXaGVuIHlvdQ0KPj4+Pj5tb3ZlIGEg TGF5ZXIgNCBzZXJ2aWNlIG1vZHVsZSBmcm9tIExvY2F0aW9uIEEgdG8gQiwgdGhlIExheWVyIDIv Mw0KPj4+Pj50b3BvbG9neSBpcyBub3QgY2hhbmdlZCwgcm91dGVzL3Jlc3RvcmF0aW9uIGFyZSBu b3QgY2hhbmdlZC4NCj4+Pj4+IA0KPj4+Pj4gLSBXaGVuIGNoYWluaW5nIExheWVyIDQgdG8gTGF5 ZXIgNyBzZXJ2aWNlIGZ1bmN0aW9ucyB0b2dldGhlciwgbGlrZQ0KPj4+Pj5TMS0+UzItPlMzLT5T NCwgdGhleSBhcmUgb3ZlcmxheWluZyBvdmVyIHRoZSB1bmRlcmxheSBuZXR3b3JrLg0KPj4+Pj4g DQo+Pj4+PiAtICBMYXllciAyIGFuZCBsYXllciAzIG5vZGVzIGhhdmUgY29udHJvbCBwbGFuZSAo ZS5nLiBJR1AvQkdQKSB0bw0KPj4+Pj5keW5hbWljYWxseSBkaXNjb3ZlciB0b3BvbG9neTsgZm9y d2FyZGluZyBwYXRoczsgcHJvdGVjdGlvbiBwYXRoczsNCj4+Pj4+cmVzdG9yYXRpb24gcGF0aHMs IGV0Yy4gVG9kYXksIGFsbCByb3V0ZXJzIGFyZSBjb25uZWN0ZWQgdG9nZXRoZXIgYnkNCj4+Pj4+ bGlua3MuIFRoZWlyIHRvcG9sb2d5IGlzIG1vcmUgbGlrZSBhIG1lc2hlZCBncmFwaCB0aGFuIGNo YWluLiBTbw0KPj4+Pj53aGVuIHlvdSBjaGFpbiBSb3V0ZXItMTwtPlJvdXRlci0yPC0+Um91dGVy LTMsIGFyZSB5b3UgdGFsa2luZyBhYm91dA0KPj4+Pj5zb3VyY2Ugcm91dGluZz8gVGhlcmVmb3Jl LCBuZWVkIGEgY2xlYXIgZGVmaW5pdGlvbiBvbiB3aGF0IGRvZXMgaXQNCj4+Pj4+cmVhbGx5IG1l YW4gYnkgY2hhaW5pbmcgTGF5ZXIgMi8zIHNlcnZpY2Ugbm9kZXMuDQo+Pj4+PiANCj4+Pj4+IExp bmRhDQo+Pj4+PiANCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZy b206IFRob21hcyBOYWRlYXUgW21haWx0bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbV0NCj4+Pj4+ PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDMsIDIwMTMgNToyOCBQTQ0KPj4+Pj4+IFRvOiBM aW5kYSBEdW5iYXINCj4+Pj4+PiBDYzogbnNjQGlldGYub3JnOyBKaW0gR3VpY2hhcmQgKGpndWlj aGFyKTsgU3Rld2FydCBCcnlhbnQNCj4+Pj4+PiAoc3RicnlhbnQpOyBUaG9tYXMgTmFydGVuOyBh ZHJpYW5Ab2xkZG9nLmNvLnVrDQo+Pj4+Pj4gU3ViamVjdDogUmU6IFtuc2NdIE5TQyBCb0YgT3V0 Y29tZXMNCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBPbiBTZXAgMywgMjAxMzo2OjI1IFBNLCBh dCA2OjI1IFBNLCBMaW5kYSBEdW5iYXINCj4+Pj4+PiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+ IHdyb3RlOg0KPj4+Pj4+IA0KPj4+Pj4+PiBUaG9tYXMsDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBcmUg eW91IHNheWluZyB0aGF0IHRoZSBOU0Mgc2NvcGUgaW5jbHVkZXMgY2hhaW5pbmcgTGF5ZXIgMiwN Cj4+Pj4+Pj4gTGF5ZXINCj4+Pj4+Pj4gMw0KPj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zLCBMYXll ciA0IHRvIExheWVyIDcgc2VydmljZSBmdW5jdGlvbnMsIGFuZA0KPj4+Pj4+IHZhcmlvdXMgY29t YmluYXRpb24gb2YgdGhlbT8NCj4+Pj4+PiANCj4+Pj4+PiAgICBJIGRvbid0IGRlZmluZSB0aGUg c2NvcGU7IHRoYXRzIHVwIHRvIHRoZSBBRHMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gICAgQ291bGQgeW91 IHBsZWFzZSBhbnN3ZXIgdGhlIHF1ZXN0aW9uIGJlbG93Pw0KPj4+Pj4+IA0KPj4+Pj4+ICAgIC0t VG9tDQo+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBMaW5kYQ0KPj4+Pj4+PiANCj4+Pj4+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+PiBGcm9tOiBUaG9tYXMgTmFkZWF1 IFttYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb21dDQo+Pj4+Pj4+PiBTZW50OiBUdWVzZGF5 LCBTZXB0ZW1iZXIgMDMsIDIwMTMgNToxOSBQTQ0KPj4+Pj4+Pj4gVG86IExpbmRhIER1bmJhcg0K Pj4+Pj4+Pj4gQ2M6IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBhZHJpYW5Ab2xkZG9nLmNvLnVr OyBuc2NAaWV0Zi5vcmc7DQo+Pj4+Pj4+PiBUaG9tYXMgTmFydGVuOyBTdGV3YXJ0IEJyeWFudCAo c3RicnlhbnQpDQo+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW25zY10gTlNDIEJvRiBPdXRjb21lcw0K Pj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IE9uIFNlcCAzLCAyMDEzOjU6NTQgUE0sIGF0 IDU6NTQgUE0sIExpbmRhIER1bmJhcg0KPj4+Pj4+Pj4gPGxpbmRhLmR1bmJhckBodWF3ZWkuY29t PiB3cm90ZToNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IE15IGNvbW1lbnRzIGFyZSBpbnNlcnRlZCBi ZWxvdyBtYXJrZWQgYnkgW0xpbmRhXToNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+ IEhvd2V2ZXIsIGl0IHdhcyBsZXNzIGNsZWFyIHRvIG1lIHRoYXQgdGhlcmUgaXMgYWdyZWVtZW50 DQo+Pj4+Pj4+Pj4+PiBhYm91dA0KPj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+PiBsYXllcg0KPj4+Pj4+ Pj4+Pj4gaW4NCj4+Pj4+Pj4+Pj4+IHdoaWNoIHNlcnZpY2UgY2hhaW5pbmcgaGFzIHRvIGJlIHNv bHZlZC4gSSBmZWx0IHRoYXQgc29tZQ0KPj4+Pj4+Pj4+Pj4gcGVvcGxlIHdlcmUgdGFsa2luZyBh Ym91dCBzZXJ2aWNlIGNoYWluaW5nIGluIHRoZSBhcHBsaWNhdGlvbg0KPj4+Pj4+Pj4+Pj4gbGF5 ZXIsDQo+Pj4+Pj4gc29tZQ0KPj4+Pj4+Pj4+Pj4gYWJvdXQgc2VydmljZSBjaGFpbmluZyBiYXNl ZCBvbiBmbG93cywgYW5kIHNvbWUgYWJvdXQNCj4+Pj4+Pj4+Pj4+IHBlci1wYWNrZXQgc2Vydmlj ZXMuIFRoZSBzb2x1dGlvbnMgYXJlLA0KPj4+Pj4+Pj4+PiBJDQo+Pj4+Pj4+Pj4+PiB0aGluaywN Cj4+Pj4+Pj4+Pj4+IGxpa2VseSB0byBiZSB2ZXJ5IGRpZmZlcmVudCBmb3IgdGhlIGRpZmZlcmVu dCBwcm9ibGVtcywgYW5kDQo+Pj4+Pj4+Pj4+PiBpdA0KPj4+Pj4+Pj4gd291bGQNCj4+Pj4+Pj4+ Pj4gYmUNCj4+Pj4+Pj4+Pj4+IHdyb25nIHRvDQo+Pj4+Pj4+Pj4+PiB0cnkgdG8gYnVuY2ggdGhl bSBhbGwgdG9nZXRoZXIuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBKaW0+IGFsdGhvdWdoIHRo ZXJlIHdhcyBjZXJ0YWlubHkgaW5pdGlhbCBjb25mdXNpb24gSSBiZWxpZXZlDQo+Pj4+Pj4+Pj4+ IEppbT4gdGhpcw0KPj4+Pj4+Pj4gaXMNCj4+Pj4+Pj4+Pj4gYmVjb21pbmcgbGVzcyBhbmQgbGVz cyBzbyBhcyB3ZSBzb2NpYWxpemUgdGhlIGJhc2ljIGlkZWEgb2YNCj4+Pj4+PiBzZXJ2aWNlDQo+ Pj4+Pj4+Pj4+IGNoYWluaW5nOyBpbmRlZWQsIGFzIHdlIG1vdmUgZm9yd2FyZCB3ZSB3aWxsIHJl ZmxlY3QgYSBtb3JlDQo+Pj4+Pj4+Pj4+IGNvbW1vbiB1bmRlcnN0YW5kaW5nIHdpdGhpbiB0aGUg cHJvYmxlbSBzdGF0ZW1lbnQuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gSXQgaXMgc3RpbGwgbm90 IGNsZWFyIHdoaWNoIGxheWVyIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBjaGFpbmVkDQo+Pj4+Pj4+ PiB0b2dldGhlci4gVGhlIGRyYWZ0LXF1aW5uLW5zYy1wcm9ibGVtLXN0YXRlbWVudC0wMyBkaXNj dXNzZWQNCj4+Pj4+PiBjaGFpbmluZw0KPj4+Pj4+Pj4gb2Ygc2VydmljZSBmdW5jdGlvbnMgdGhh dCBjYW4gYmUgYSBuZXR3b3JrIG9yIGFwcGxpY2F0aW9uIGJhc2VkDQo+Pj4+Pj4+PiBwYWNrZXQg dHJlYXRtZW50LC4uLiwgdG8gZW5hYmxlIGEgc2VydmljZSBvZmZlcmVkIGJ5IGEgbmV0d29yaw0K Pj4+Pj4+IG9wZXJhdG9ycy4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gICAgV2h5IGRvIHlvdSB0aGlu ayB0aGF0IG1hdHRlcnM/DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBUb2RheSwgdGhlcmUgYXJlIG1h bnkgc2VydmljZXMgb2ZmZXJlZCBieSBvcGVyYXRvcnMsIGUuZy4NCj4+Pj4+Pj4+PiBMMlZQTiwg TDNWUE4sIFAyUCBwYXRocywgZXRjLiBTbyB5b3UgY2FuIGludGVycHJldCBOU0MgYXMNCj4+Pj4+ Pj4+PiBjaGFpbmluZw0KPj4+Pj4+Pj4+IEwyL0wzDQo+Pj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9u cyAobGlrZSBwcm94eSBmb3J3YXJkaW5nLCBvciBmcmFnbWVudGF0aW9uLA0KPj4+Pj4+Pj5ldGMu KTsgWW91IGNhbiBhbHNvIGludGVycHJldCBOU0MgYXMgY2hhaW5pbmcgTDQgIChhbmQgYWJvdmUp DQo+Pj4+Pj4+PnNlcnZpY2UgZnVuY3Rpb25zOyBvciBjaGFpbmluZyBvZiBtaXhlZCBMNC1MNyBz ZXJ2aWNlIGZ1bmN0aW9ucw0KPj4+Pj4+Pj4oaS5lLiB3aXRoIHNvbWUgc2VydmljZSBub2RlcyBj b25zdW1pbmcgcGFja2V0cyBhbmQgcmVpbml0aWF0ZQ0KPj4+Pj4+Pj5uZXcgcGFja2V0cykuDQo+ Pj4+Pj4+PiANCj4+Pj4+Pj4+ICAgIFlvdSBjYW4sIGFuZCBwZW9wbGUgYWN0dWFsbHkgZG8gaW1w bGVtZW50IHRoaXMgdG9kYXkuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBJcyBOU0MgaW5jbHVkaW5n IGFsbCBjaGFpbmluZyBvZiBhbGwgdGhvc2Ugc2VydmljZXM/DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4gTGF5ZXIgMi8zIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgbWlnaHQgcmVxdWlyZSBkaWZm ZXJlbnQNCj4+Pj4+Pj4+PiBzY2hlbWVzDQo+Pj4+Pj4+PiB0aGFuIExheWVyIDQtNyBzZXJ2aWNl IGNoYWluaW5nLiBUaGVyZWZvcmUsIGl0IGlzIG1vcmUgZWZmZWN0aXZlDQo+Pj4+Pj4+PiB0byBk ZWZpbmUgdGhlbSBzZXBhcmF0ZWx5IHRvIG1ha2UgdGhlIGRpc2N1c3Npb24gbW9yZSBmb2N1c2Vk Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAgICBJIGRvIG5vdCB0aGluayBzby4gSSdkIHByZWZlciB0 byBub3QgbWFrZSB0aGlzIG9ubHkgYXMNCj4+Pj4+PiBjb21wbGljYXRlZA0KPj4+Pj4+Pj4gYXMg aXQgbmVlZHMgdG8gYmUsIGFuZCBubyBtb3JlLiBUaGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIG9m DQo+Pj4+Pj4+PiBMYXllcg0KPj4+Pj4+Pj4gMiBhbmQgMyBjaGFpbmluZyB0aGF0IGFyZSBhbGwg ZG9uZSB3aXRoIHRoZSBzYW1lDQo+Pj4+Pj4+PiBlbmNhcC9wcm92aXNpb25pbmcgc3lzdGVtcy4N Cj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gICAgLS1Ub20NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gTGluZGEgRHVuYmFyDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+Pj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+IG5zY0BpZXRmLm9yZw0K Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4+ Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4+Pj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4+Pj4gDQo+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gbnNj IG1haWxpbmcgbGlzdA0KPj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4+Pg0KPj4+Pg0KPj4+DQo+Pg0KPj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5uc2MgbWFpbGluZyBs aXN0DQo+Pm5zY0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25zYw0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+X19fIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pg0KPj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4+Y29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVz ZXMsDQo+PmV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyDQo+PmVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlDQo+PmxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzDQo+PmQnYWx0 ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZQ0KPj5hbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4NCj4+VGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQNCj4+aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsg dGhleSBzaG91bGQgbm90IGJlDQo+PmRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uDQo+PklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQNCj4+ZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzLg0KPj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUNCj4+YmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuDQo+PlRoYW5rIHlvdS4NCj4+DQo+DQoNCg== From paulq@cisco.com Wed Sep 4 10:48: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 51A5911E80FD for ; Wed, 4 Sep 2013 10:48:52 -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 bn9a5R-CRJSn for ; Wed, 4 Sep 2013 10:48:47 -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 EEC9211E80F6 for ; Wed, 4 Sep 2013 10:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37731; q=dns/txt; s=iport; t=1378316927; x=1379526527; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kbRDLm+m9VaR/2IAa60Q6/H1lM13dQjUgOh8SIJugDk=; b=gZ+FHx/LnOeegJV5De/fpr/df9PrX5F2TbcQFtEh5bNrzbVT+PcrdV4i CsQ/W/nuHILzsq05PVtsgLhAgKP+n+7S7bh/78QEev03FC5333OtBolG7 C4XMCixEr99P+6NA+Gc+awT84UDqCkpAtCAnsj3gRZVU4o9taTKLhO3/A o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAONxJ1KtJV2a/2dsb2JhbABagkNENVHBRIEoFnSCJQEBBAEBAWsEAgUQAgEIEhALCwEGBycLFAMOAgQOBQgTh2cMuiYEji2BAhkUBAYBCoMTgQADlBuVQIMggWlB X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208,217";a="255556698" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 04 Sep 2013 17:48:46 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r84HmkKx024052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 17:48:46 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.101]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 12:48:45 -0500 From: "Paul Quinn (paulq)" To: "mohamed.boucadair@orange.com" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1Ee0QgAEeZYA= Date: Wed, 4 Sep 2013 17:48:45 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.172.246] Content-Type: multipart/alternative; boundary="_000_B4CF12F64861194990FEA0AE39F9B1620EA58541xmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 17:48:52 -0000 --_000_B4CF12F64861194990FEA0AE39F9B1620EA58541xmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Med, Comments inline=85 Thanks! Paul On Sep 4, 2013, at 7:05 AM, mohamed.boucadair@orange.com wrote: Hi Jim, Thank you for preparing the text. I fully agree that, for the sake of interoperability, one standard track so= lution must be specified by the working group. I=92m fully supportive to me= ntion this in the charter and avoid that during the lifetime of the working= group multiple solutions are envisaged. I have some comments about the proposed deliverables and the proposed timin= g: (1) I don=92t think it is a good idea to split the requirements into multip= le documents. For the sake of consistency and also to have the big picture,= I suggest only one single document be chartered to record the requirements= . The requirements document should include functional requirements, managea= bility requirements (as per RFC5706) and security requirements. The full se= t of requirements should be taken into account during the design phase. (2) The specification effort should start once the requirements are almost = stable, not before. (3) I would remove the word =93metadata=94 from the milestones. (4) I personally don=92t see a value to add dedicated items for detailed us= e cases. There is already an undergoing effort in other fora; no need to ha= ve redundant effort in this space. Having an abstract description level in = the Problem Statement is sufficient IMHO. (5) I suggest to add a =93Analysis and Design Choices=94 document: Details = rated to design motivations and justifications will be recorded in the anal= ysis document while the specification document(s) focuses exclusively on th= e specification part. Past experience has shown that some questions are rai= sed multiple times during the lifetime of the wg and it is not sometimes ob= vious to find where the decision was made and for what reason. This kind of= details are hard (sometime) to find: either you need to check mailing list= archives, or contact the authors. I see the design analysis document as a = formal tool to record the consensus on controversial design issues. The doc= ument can also answer to =93why not my favourite solution=94 solve the prob= lem(s). PQ> This space is moving quickly, with a lot of vendor and operator activi= ty. We need this WG to be at the forefront of service chaining, consequent= ly, we should focus on a few, focused deliverables. Between the problem st= atement and the requirements documents (along with use cases as needed), we= have plenty to drive the designs. (6) We don=92t know at this stage how many specification documents will be = needed. Perhaps only one Standard Track document will be required. I sugges= t we leave the decision on the exact number of Standard Track documents ope= n. PQ> I think the current charter defines the one we know we need now. This= can certainly certainly evolve over time but the WG must be chartered to d= eliver protocol documents to be truly effective at driving interoperability= . To sum up: my suggestion is to go for this set of deliverables: (a) Problem Statement document (b) Framework document (terminology, functional elements, architecture, and= overall procedure) (c) Requirements document (d) Design Analysis document (e) Specification document(s) I wouldn=92t object if the first charter of the future WG covers only items= (a) to (d). An updated charter can be envisaged once the future WG has mor= e visibility on the detailed set of specification documents. Cheers, Med De : nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] De la part de Jim Guichard (jguichar) Envoy=E9 : mardi 3 septembre 2013 18:01 =C0 : nsc@ietf.org Objet : [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_B4CF12F64861194990FEA0AE39F9B1620EA58541xmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3ADC99831092914FB01D231F222385C2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Med,

Comments inline=85

Thanks!
Paul

On Sep 4, 2013, at 7:05 AM, mohamed.boucadair@orange.com wrote:

Hi Jim,
 
Thank you for preparing the text.
 
I fully agree that, for the sake of interoperability, one stand= ard track solution must be specified by the working group. I=92m fully supp= ortive to mention this in the charter and avoid that during the lifetime of the working group multiple solutions= are envisaged.
 
I have some comments about the proposed deliverables and the pr= oposed timing:
 
(1) I don=92t think it is a good idea to split the requirements= into multiple documents. For the sake of consistency and also to have the = big picture, I suggest only one single document be chartered to record the requirements. The requirements documen= t should include functional requirements, manageability requirements (as pe= r RFC5706) and security requirements. The full set of requirements should b= e taken into account during the design phase.
 
(2) The specification effort should start once the requirements= are almost stable, not before.
 
(3) I would remove the word =93metadata=94 from the milestones.=
 
(4) I personally don=92t see a value to add dedicated items for= detailed use cases. There is already an undergoing effort in other fora; n= o need to have redundant effort in this space. Having an abstract description level in the Problem Statement is su= fficient IMHO.
 
(5) I suggest to add a =93Analysis and Design Choices=94 docume= nt: Details rated to design motivations and justifications will be recorded= in the analysis document while the specification document(s) focuses exclusively on the specification part. Past experience= has shown that some questions are raised multiple times during the lifetim= e of the wg and it is not sometimes obvious to find where the decision was = made and for what reason. This kind of details are hard (sometime) to find: either you need to check mailing l= ist archives, or contact the authors. I see the design analysis document as= a formal tool to record the consensus on controversial design issues. The = document can also answer to =93why not my favourite solution=94 solve the problem(s).

PQ>  This space is moving quickly, with a lot of vendor and op= erator activity.  We need this WG to be at the forefront of service ch= aining, consequently, we should focus on a few, focused deliverables.  = ;Between the problem statement and the requirements documents (along with use cases as needed), we have plenty to drive the de= signs.  



 
(6) We don=92t know at this stage how many specification docume= nts will be needed. Perhaps only one Standard Track document will be requir= ed. I suggest we leave the decision on the exact number of Standard Track documents open.

PQ>  I think the current charter defines the one we know we ne= ed now.  This can certainly certainly evolve over time but the WG must= be chartered to deliver protocol documents to be truly effective at drivin= g interoperability.  



 
To sum up: my suggestion is to go for this set of deliverables:=
 
(a) Problem Statement document
(b) Framework document (terminology, functional elements, archi= tecture, and overall procedure)
(c) Requirements document
(d) Design Analysis document
(e) Specification document(s)
 
I wouldn=92t object if the first charter of the future WG cover= s only items (a) to (d). An updated charter can be envisaged once the futur= e WG has more visibility on the detailed set of specification documents.
 
Cheers,
Med
 
 
De&nb= sp;:  [mailto:nsc-bounces@ietf.org] De la part de Jim Guich= ard (jguichar)
Envoy=E9 : ma= rdi 3 septembre 2013 18:01
=C0 : nsc@ietf.org
Objet : [nsc]= NSC Working Group Charter Proposal
 
Greet= ings,
 = ;
As we= look forward to the formation of a working group that will focus on networ= k service chaining, I would like to propose a discussion on this alias to t= ry and reach consensus on an initial charter as requested by the routing area AD's. The following is a first dr= aft of the charter and I invite you to actively participate and provide inp= uts into this process.
 = ;
Pr= oposed NSC WG Charter
 = ;
Exist= ing service insertion and deployment techniques have not evolved to meet mo= dern network architectures and do not reflect multi-tenancy, virtualization= , elasticity, rich classification, and other network requirements. Networks, servers, storage, and applicatio= ns, have all undergone significant change in recent years: virtualization, = network overlays, and orchestration are increasingly the norm. All of these= have profound effects on network and services design.
 = ;
Today= , deploying new services, or making changes to existing services, often req= uires network topology changes. Adding and removing service functions is a = complex, risky task, that is tied to operationalizing topological changes leading to mostly-static service d= efinitions. New service insertion and deployment techniques must enable the= concept of service functions as shared resources, and enable the linkage o= f these resources using service chains that represent the abstracted view of the required service function= s, and define the order in which they should be applied. When a service cha= in is instantiated in a network, specific instances of service functions ar= e selected, and a service topology is created and used for forwarding packets through the service chain.=
 = ;
A bas= ic service chain might simply utilize an existing overlay technology to for= ce traffic through the necessary service functions. However, additional inf= ormation enables a richer service chain for more advanced composite services. For example, shared informatio= n (e.g., the result of classification) can be used to offload service funct= ion processing or inform other service functions about information that wou= ld otherwise be hard to glean. 
 = ;
The N= etwork Service Chaining (NSC) working group focuses on new approaches to se= rvice insertion and deployment, providing a framework for the construction = of services built using service chains. The WG focuses on the necessary protocols for the creation of service chai= ns, and the passing of metadata from the network to service functions, and = between service functions. When possible, the WG will extend existing proto= cols to provide service chaining functionality, and any protocol extensions will be reviewed by both the Ne= twork Service Chaining WG and by the WG responsible for the protocol being = extended.  
 = ;
Speci= fically, the Network Service Chaining WG is chartered to deliver the follow= ing work items: 
 = ;
1) Pr= oblem Statement: this document will provide a summary of the problem space = to be addressed by the Network Service Chaining WG including terminology an= d sample use cases.  Additionally, the WG will normalize on nomenclature and definitions for Network Service = Chaining.
 = ;
2) Sy= stem Architecture: this set of documents will provide a description of the = architecture building blocks and their relationships including interconnect= ion, placement of capabilities, and security models, as well as requirements on the control mechanisms and dat= a plane encapsulation.
 = ;
3) Se= rvice Chaining Data Plane: this document will describe on the wire data pla= ne encapsulation in support of (2).  A single encapsulation will be se= lected in order to enable interoperability of data plane components.
 = ;
4) Ma= nageability: this document will address service chaining operation, monitor= ing and troubleshooting including relevant service chaining models such as = MIBs or YANG modules, along with relevant OAM capabilities and how they are realized.
 = ;
Propo= sed Milestones:
 = ;
Dec 2= 013 Request publication of an Informational document defining the Network S= ervice Chaining problem statement to the IESG
 = ;
Mar 2= 014 Request publication of informational documents defining the system arch= itecture including protocol requirements and framework to the IESG
 = ;
May 2= 014 Request publication of a Standards Track document specifying the data-p= lane (including metadata) for Service Chaining to IESG
 = ;
May 2= 014 Request publication of an informational document specifying Service Cha= ining Control Plane requirements to IESG
 = ;
Dec 2= 014 Request publication of informational documents defining Service Chainin= g manageability requirements including MIBs, OAM, and information models to= IESG 
 = ;
 = ;
_______________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc<= /a>

--_000_B4CF12F64861194990FEA0AE39F9B1620EA58541xmbrcdx14ciscoc_-- From jguichar@cisco.com Wed Sep 4 10:54: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 9376521E8144 for ; Wed, 4 Sep 2013 10:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5++U32-bPaAl for ; Wed, 4 Sep 2013 10:53:57 -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 49E4E11E80F6 for ; Wed, 4 Sep 2013 10:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9656; q=dns/txt; s=iport; t=1378317237; x=1379526837; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Rvqewzf1dhL+mKwVHhWVRLRKSGtNsApN14Nh117IUbI=; b=Y2KD65BOwOaglosiN3XDkC4Eb1cku9vHsMO1gc9KthiBVNe2DQzs+WDF uQVE11Pn4Dcarmu1U20kWYbuweo1siHme8mgw2+77yiZ7DMbsLQUaQyCj vAp0EbyRktj/AY7TFSP4uDHsfkcdfSvf7DrWsCMOpFc1SjhNaCG/oLYrS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIFAFFzJ1KtJXG+/2dsb2JhbABagwc1SwbBRIEoFnSCJAEBAQQBAQFkBxcGAQgRAQMBAQEKHS4LFAMGCAIEARIIAYd5BwW6LI4XgRgGLQUGgxeBAAOIfYsehQmLC4UsgyCBcTk X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208";a="255606348" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 04 Sep 2013 17:53:21 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r84HrLnV012507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 17:53:21 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 12:53:20 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker , Ken Gray , "mohamed.boucadair@orange.com" , "nsc@ietf.org" Thread-Topic: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt Thread-Index: Ac6fMhIAzIOqddliRk+cqJ/CnVKw9ADv8zVgAZrASQAACgW9EP//xs+A//+qjJCAAMTAAA== Date: Wed, 4 Sep 2013 17:53:20 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6758E6@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.82.249.237] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.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, 04 Sep 2013 17:54:04 -0000 I would add that if the SF Map Index (aka service path id) also carries an index into the service chain (aka SF Map) then regardless of whether the receiving node is virtual or not it can still determine the placement within the service chain and the necessary service function to apply. Likewise the context, if carried, can indicate which particular profile of a given service function to apply. On 9/4/13 1:31 PM, "Ron Parker" wrote: >Hi, Ken. > >In some of the I'D's we do touch on the logical network function concept, >but we may need to consolidate and strengthen the requirements around >that. Not only can multiple disparate network functions co-reside at >the same managed network element, but even multiple instances of the same >type of network function where these instance imply differentiated >behaviors. For example, the same managed network element may support >'firewall-strict', 'firewall-loose', 'content-filter-adult', >'content-filter-child', 'dpi-analytics'. A useful service chain may, >for example, select 'firewall-strict' and 'content-filter-child' plus >other service functions that happen to reside in other managed network >elements. > >In draft-boucadair-service-chaining-framework, section 9.3, On Service >Function Profiles (a.k.a., Contexts), we point out that logical service >functions can imply differentiated behavior (policy). > >In the same I-D, section 5.5, SF Node, we have the text: > In case several SFs > are co-located in the same node, the packet is processed by > all SFs indicated in the SF Map. Once the packet is > successfully handled by local SF(s), the packet is forwarded > to the next SF Node in the list or to an intermediate node > (if the local SFC Node is the last element in the SF Map). > >Thanks. > > Ron > >-----Original Message----- >From: Ken Gray [mailto:kgray@juniper.net] >Sent: Wednesday, September 04, 2013 12:15 PM >To: Ron Parker; mohamed.boucadair@orange.com; nsc@ietf.org >Subject: Re: [nsc] TR: I-D Action: >draft-boucadair-chaining-requirements-01.txt > >We're bouncing around my point, though you actually bring up an ancillary >thing of interest. > >Assuming that an element performs multiple functions (either as multiple >virtual machines or as part of it's physical/logical architecture as a >non-virtual device), then there is an interesting question about how we >represent this in service discovery - particularly if we cannot >manipulate the order or isolate an order (that's the part I think is new >and interesting in your response). > >I think we're agreeing that the work of the NSC workgroup will ignore the >mechanics of such chaining as implementation details and thus not >describe how they are chained - keeping us out of the IPC/RPC bailywick >and focusing only on the description of/standardization of externally >chained services (though, as I mentioned above, representation of that >combined service IS relevant to NSC work). > >Yes? If so, we should make this clear in #2? > >On 9/4/13 11:47 AM, "Ron Parker" wrote: > >>Hi, Ken. >> >>Responding to your comment on REQ #2, from my perspective... >> >>A particular network element (physical or virtual) can definitely support >>multiple service functions simultaneously. Any particular chain may >>invoke any of them in any order. However, I feel that it is an >>implementation specific design issue whether hops between these >>co-resident services literally follow the exact service chaining >>procedures that we ultimately define or simply behave as if they were >>exactly followed (i.e., external-service A to internal-service B to >>internal-service C to external-service D -- only the external A to >>internal B and the internal C to external D are externally observable). >> >> Ron >> >> >>-----Original Message----- >>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>Ken Gray >>Sent: Wednesday, September 04, 2013 10:53 AM >>To: mohamed.boucadair@orange.com; nsc@ietf.org >>Subject: Re: [nsc] TR: I-D Action: >>draft-boucadair-chaining-requirements-01.txt >> >>Heya, Med. >> >>I gave it a quick read. I have the following questions/observations: >> >>REQ#2 - The document doesn't specifically say whether we're >>constraining our focus on chains that require an "externality" for each >>link (that is, ARE we assuming that each "link" will pass through a >>network/networked element e.g. Hypervisor switch) - and are thus >>excluding from discussion IPC (or RPC) mechanisms between service >>elements on the same device (which are much harder to detect, monitor, >>standardize). >> >>REQ#13 is putting a constraint on the header discussion. Is this the >>right place to put that, particularly since the requirements there >>haven't been fully defined (yet)? >> >>REQ#15 - while I fully appreciate your desire to avoid another 80+ part >>email thread on whether MPLS is an overlay, I think you make your point >>well enough in the main assertion and part "b" is actually redundant. >>8^) >> >>REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22 >>has to be a MUST (I think the need for downstream reclassification can >>be a normal outcome of the function of an individual service element as >>it potentially transforms a header - unless your argument is that we >>should avoid this wherever possible by imbedding a clue in the header - >>in which case we run into issues with "non-speakers" or legacy devices). >> >>REQ#23 seems to obviate the use of simple route NH manipulation to >>create a chain (this is destination address based). So, to be >>inclusive, I think that has to be a SHOULD. >> >>REQ#25 seems to be difficult to require if you don't dictate how the >>chain is formed (how the forwarding is instantiated) and should be >>worded more like REQ#29, IMO. >> >>REQ#30 I think you're trying to say that static definition/topology of >>service functions SHOULD be supported but dynamic MUST (not that every >>element has to support dynamic discovery but that the overall goal of >>the ongoing architecture should be dynamic with static augmentation for >>corner/legacy cases) ...which would be more in alignment with the tenor >>of REQ#32. >> >>Thanks for kicking it off and reading this drivel ... >> >> >> >> >> >> >>On 8/27/13 2:58 AM, "mohamed.boucadair@orange.com" >> wrote: >> >>>Dear all, >>> >>>A new version of the requirements draft is now available online. The >>>main changes in this new version are as follows: >>> >>>* Enrich the document with inputs from >>>draft-li-service-chaining-requirements >>>* Welcome authors of draft-li-service-chaining-requirements as >>>co-authors >>>* Add new security-related requirements. >>>* Re-order the requirements >>> >>>A more detailed diff is available at: >>>http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requiremen >>>t >>>s-0 >>>1.txt >>> >>>Feel free to share your comments, suggestions and text contributions >>>on the list or direct them to the authors. >>> >>>Cheers, >>>Med >>> >>>-----Message d'origine----- >>>De : i-d-announce-bounces@ietf.org >>>[mailto:i-d-announce-bounces@ietf.org] >>>De la part de internet-drafts@ietf.org Envoy=E9 : jeudi 22 ao=FBt 2013 >>>14:21 =C0 : i-d-announce@ietf.org Objet : I-D Action: >>>draft-boucadair-chaining-requirements-01.txt >>> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> >>> >>> Title : Requirements for Service Function Chaining >>> Author(s) : Mohamed Boucadair >>> Christian Jacquenet >>> Yuanlong Jiang >>> Hongyu Li >>> Ron Parker >>> Filename : draft-boucadair-chaining-requirements-01.txt >>> Pages : 10 >>> Date : 2013-08-22 >>> >>>Abstract: >>> This document identifies the requirements for the Service Function >>> Chaining. >>> >>> >>> >>>The IETF datatracker status page for this draft is: >>>https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirements >>> >>>There's also a htmlized version available at: >>>http://tools.ietf.org/html/draft-boucadair-chaining-requirements-01 >>> >>>A diff from the previous version is available at: >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirements >>>- >>>01 >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>_______________________________________________ >>>I-D-Announce mailing list >>>I-D-Announce@ietf.org >>>https://www.ietf.org/mailman/listinfo/i-d-announce >>>Internet-Draft directories: http://www.ietf.org/shadow.html or >>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >>> >>> >> >> >>_______________________________________________ >>nsc mailing 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 Wed Sep 4 11:04: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 06C3F21E80F8 for ; Wed, 4 Sep 2013 11:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.049 X-Spam-Level: X-Spam-Status: No, score=-4.049 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 maLSMChc8hm1 for ; Wed, 4 Sep 2013 11:04:33 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 21C9821E804D for ; Wed, 4 Sep 2013 11:04:32 -0700 (PDT) Received: from mail183-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE021.bigfish.com (10.243.66.84) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 18:04:32 +0000 Received: from mail183-co1 (localhost [127.0.0.1]) by mail183-co1-R.bigfish.com (Postfix) with ESMTP id 5B14A780321; Wed, 4 Sep 2013 18:04:32 +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: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail183-co1: 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:(377454003)(479174003)(24454002)(13464003)(199002)(189002)(51704005)(19580405001)(83322001)(83506001)(19580395003)(81686001)(80022001)(15975445006)(65816001)(69226001)(59766001)(77982001)(81816001)(4396001)(46102001)(63696002)(49866001)(50986001)(47976001)(81542001)(36756003)(76176001)(76786001)(76796001)(51856001)(74366001)(79102001)(81342001)(47736001)(56816003)(77096001)(53806001)(54356001)(80976001)(47446002)(31966008)(74502001)(74662001)(74876001)(56776001)(54316002)(83072001)(74706001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB081; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail183-co1 (localhost.localdomain [127.0.0.1]) by mail183-co1 (MessageSwitch) id 1378317869992891_16607; Wed, 4 Sep 2013 18:04:29 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.225]) by mail183-co1.bigfish.com (Postfix) with ESMTP id EC594580050; Wed, 4 Sep 2013 18:04:29 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 18:04:28 +0000 Received: from BL2PR05MB081.namprd05.prod.outlook.com (10.255.232.14) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 4 Sep 2013 18:04:28 +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.745.25; Wed, 4 Sep 2013 18:04:27 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 18:04:27 +0000 From: Ken Gray To: Linda Dunbar , Ron Parker , Thomas Nadeau Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqOMZHv0zVYXZE0SHEZHP0mGkNJm0jqkAgAAGpACAAAH1gIAAAJuAgAAFo4CAACDVAIABBEuA///a5gA= Date: Wed, 4 Sep 2013 18:04:26 +0000 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9D19E@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 095972DF2F Content-Type: text/plain; charset="us-ascii" Content-ID: <6CC97D6C73FE8B479E83ECF7E5181B92@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" , "Jim Guichard \(jguichar\)" , Thomas Narten , "adrian@olddog.co.uk" , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 18:04:38 -0000 In line ... On 9/4/13 12:17 PM, "Linda Dunbar" wrote: >Ron,=20 > >My comments are inserted below: >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Tuesday, September 03, 2013 7:46 PM >> To: Linda Dunbar; Thomas Nadeau >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; >> adrian@olddog.co.uk; Stewart Bryant (stbryant) >> Subject: RE: [nsc] NSC BoF Outcomes >>=20 >> Hi, Linda. >>=20 >> With respect to: >>=20 >> - Layer 4 to Layer 7 service functions (or service nodes) are to >> apply actions to data packets traversing through. They don't impact >> overall network topologies/routes/restorations. >>=20 >> Layer 4-7 services can, indeed, impact routing decisions. For example, >> if the service is DPI analysis, then a detected protocol may cause the >> subsequent packets to be policy routed on a path different than the SPF >> path. > >[Linda] Do you call this "DPI" function that re-direct data frames to a >different target (that is not the Destination of the data frame) "Layer >3" service? >When those "DPI" functions re-direct traffic, do they add another >Destination address to the data frames (i.e. create a tunnel)? Or do they >not touch the destination addresses in the existing data frames and >expect all the nodes along the way to know how to forward the data frames? I fail to see the point of the question. >=20 > > >Bottom line, those services need to be distinguished from traditional >Layer 3 services, and be distinguished from routers/switches that >dynamically establish topology, establish routes, and restoration paths. Disagree. Bump-in-the-wire - to me, that's what this ALL is ...you are making a distinction that is very temporary and (IMO) unnecessary. What you describe as something "dynamically establish topology" is morphing (heck, with the help of I2RS - sooner rather than later) to some different definition of dynamic than we have today. Bump-in-wire. >=20 > >=20 > >=20 >Linda > > > >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Linda Dunbar >> Sent: Tuesday, September 03, 2013 6:48 PM >> To: Thomas Nadeau >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; >> adrian@olddog.co.uk; Stewart Bryant (stbryant) >> Subject: Re: [nsc] NSC BoF Outcomes >>=20 >> Here are some of the reasons that chaining of Layer 2 and 3 service >> functions are different from chaining of Layer 4 to 7 service functions >> (I will add more later): >>=20 >>=20 >> - Layer 4 to Layer 7 service functions (or service nodes) are to apply >> actions to data packets traversing through. They don't impact overall >> network topologies/routes/restorations. >>=20 >> - Layer 4-7 service functions drop, pass, consume, re-initiate packets, >> etc. They don't change network topologies, and they don't impact >> network restoration scheme (e.g. fast re-route). When you move a Layer >> 4 service module from Location A to B, the Layer 2/3 topology is not >> changed, routes/restoration are not changed. >>=20 >> - When chaining Layer 4 to Layer 7 service functions together, like S1- >> >S2->S3->S4, they are overlaying over the underlay network. >>=20 >> - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to >> dynamically discover topology; forwarding paths; protection paths; >> restoration paths, etc. Today, all routers are connected together by >> links. Their topology is more like a meshed graph than chain. So when >> you chain Router-1<->Router-2<->Router-3, are you talking about source >> routing? Therefore, need a clear definition on what does it really mean >> by chaining Layer 2/3 service nodes. >>=20 >> Linda >>=20 >> > -----Original Message----- >> > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> > Sent: Tuesday, September 03, 2013 5:28 PM >> > To: Linda Dunbar >> > Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant (stbryant); >> > Thomas Narten; adrian@olddog.co.uk >> > Subject: Re: [nsc] NSC BoF Outcomes >> > >> > >> > On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar >> > wrote: >> > >> > > Thomas, >> > > >> > > Are you saying that the NSC scope includes chaining Layer 2, Layer >> 3 >> > service functions, Layer 4 to Layer 7 service functions, and various >> > combination of them? >> > >> > I don't define the scope; thats up to the ADs. >> > >> > Could you please answer the question below? >> > >> > --Tom >> > >> > > >> > > Linda >> > > >> > >> -----Original Message----- >> > >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> > >> Sent: Tuesday, September 03, 2013 5:19 PM >> > >> To: Linda Dunbar >> > >> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org; >> > >> Thomas Narten; Stewart Bryant (stbryant) >> > >> Subject: Re: [nsc] NSC BoF Outcomes >> > >> >> > >> >> > >> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar >> > >> wrote: >> > >> >> > >>> My comments are inserted below marked by [Linda]: >> > >>> >> > >>>> -----Original Message----- >> > >>>> >> > >>>>> >> > >>>>> However, it was less clear to me that there is agreement about >> > the >> > >>>> layer >> > >>>>> in >> > >>>>> which service chaining has to be solved. I felt that some >> people >> > >>>>> were talking about service chaining in the application layer, >> > some >> > >>>>> about service chaining based on flows, and some about per- >> packet >> > >>>>> services. The solutions are, >> > >>>> I >> > >>>>> think, >> > >>>>> likely to be very different for the different problems, and it >> > >> would >> > >>>> be >> > >>>>> wrong to >> > >>>>> try to bunch them all together. >> > >>>> >> > >>>> Jim> although there was certainly initial confusion I believe >> > >>>> Jim> this >> > >> is >> > >>>> becoming less and less so as we socialize the basic idea of >> > service >> > >>>> chaining; indeed, as we move forward we will reflect a more >> > >>>> common understanding within the problem statement. >> > >>> >> > >>> It is still not clear which layer service functions are chained >> > >> together. The draft-quinn-nsc-problem-statement-03 discussed >> > chaining >> > >> of service functions that can be a network or application based >> > >> packet treatment,..., to enable a service offered by a network >> > operators. >> > >> >> > >> Why do you think that matters? >> > >> >> > >>> Today, there are many services offered by operators, e.g. L2VPN, >> > >>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 >> > >> service functions (like proxy forwarding, or fragmentation, etc.); >> > >> You can also interpret NSC as chaining L4 (and above) service >> > >> functions; or chaining of mixed L4-L7 service functions (i.e. with >> > >> some service nodes consuming packets and reinitiate new packets). >> > >> >> > >> You can, and people actually do implement this today. >> > >> >> > >>> Is NSC including all chaining of all those services? >> > >>> >> > >>> Layer 2/3 service function chaining might require different >> > >>> schemes >> > >> than Layer 4-7 service chaining. Therefore, it is more effective >> to >> > >> define them separately to make the discussion more focused. >> > >> >> > >> I do not think so. I'd prefer to not make this only as >> > complicated >> > >> as it needs to be, and no more. There are implementations of Layer >> > >> 2 and 3 chaining that are all done with the same >> encap/provisioning >> > >> systems. >> > >> >> > >> --Tom >> > >> >> > >> >> > >>> >> > >>> Linda Dunbar >> > >>> >> > >>>> >> > >>>> _______________________________________________ >> > >>>> nsc mailing list >> > >>>> nsc@ietf.org >> > >>>> https://www.ietf.org/mailman/listinfo/nsc >> > >>> _______________________________________________ >> > >>> nsc mailing list >> > >>> nsc@ietf.org >> > >>> https://www.ietf.org/mailman/listinfo/nsc >> > >>> >> > > >> > > _______________________________________________ >> > > nsc mailing list >> > > nsc@ietf.org >> > > https://www.ietf.org/mailman/listinfo/nsc >> > > >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > From Ron_Parker@affirmednetworks.com Wed Sep 4 11:04:45 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B376B21E80E6 for ; Wed, 4 Sep 2013 11:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 4WRzd5qmJhbh for ; Wed, 4 Sep 2013 11:04:40 -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 DA99211E80F6 for ; Wed, 4 Sep 2013 11:04:40 -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; Wed, 4 Sep 2013 11:04:39 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , Ken Gray , "mohamed.boucadair@orange.com" , "nsc@ietf.org" Thread-Topic: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt Thread-Index: Ac6fMhIAzIOqddliRk+cqJ/CnVKw9ADv8zVgAZrASQAACgW9EP//xs+A//+qjJCAAMTAAIAADryA Date: Wed, 4 Sep 2013 18:04:39 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F6758E6@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6758E6@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.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, 04 Sep 2013 18:04:45 -0000 Hi, Jim. I agree that an index is required to support multiple service functions co-= residing within the same network element. I'll point out that when a chai= n selects multiple co-resident network functions, there is no requirement t= hat they be contiguous. For example, a chain with A, B, C where A and C h= appen to be co-resident. However, this concept of co-residence is orthogonal to virtualization. T= he important part, IMO, is that a single managed network element may suppor= t any number of co-resident service functions. That network element could= be a single VM, a cluster of VMs, a single physical server, a cluster of p= hysical servers, a cluster of blade-based physical servers, etc. Ron -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Wednesday, September 04, 2013 1:53 PM To: Ron Parker; Ken Gray; mohamed.boucadair@orange.com; nsc@ietf.org Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01= .txt I would add that if the SF Map Index (aka service path id) also carries an = index into the service chain (aka SF Map) then regardless of whether the re= ceiving node is virtual or not it can still determine the placement within = the service chain and the necessary service function to apply. Likewise the context, if carried, can indicate which particular profile of = a given service function to apply. On 9/4/13 1:31 PM, "Ron Parker" wrote: >Hi, Ken. > >In some of the I'D's we do touch on the logical network function=20 >concept, but we may need to consolidate and strengthen the requirements ar= ound >that. Not only can multiple disparate network functions co-reside at >the same managed network element, but even multiple instances of the=20 >same type of network function where these instance imply differentiated >behaviors. For example, the same managed network element may support >'firewall-strict', 'firewall-loose', 'content-filter-adult', >'content-filter-child', 'dpi-analytics'. A useful service chain may, >for example, select 'firewall-strict' and 'content-filter-child' plus=20 >other service functions that happen to reside in other managed network=20 >elements. > >In draft-boucadair-service-chaining-framework, section 9.3, On Service=20 >Function Profiles (a.k.a., Contexts), we point out that logical service=20 >functions can imply differentiated behavior (policy). > >In the same I-D, section 5.5, SF Node, we have the text: > In case several SFs > are co-located in the same node, the packet is processed by > all SFs indicated in the SF Map. Once the packet is > successfully handled by local SF(s), the packet is forwarded > to the next SF Node in the list or to an intermediate node > (if the local SFC Node is the last element in the SF Map). > >Thanks. > > Ron > >-----Original Message----- >From: Ken Gray [mailto:kgray@juniper.net] >Sent: Wednesday, September 04, 2013 12:15 PM >To: Ron Parker; mohamed.boucadair@orange.com; nsc@ietf.org >Subject: Re: [nsc] TR: I-D Action: >draft-boucadair-chaining-requirements-01.txt > >We're bouncing around my point, though you actually bring up an=20 >ancillary thing of interest. > >Assuming that an element performs multiple functions (either as=20 >multiple virtual machines or as part of it's physical/logical=20 >architecture as a non-virtual device), then there is an interesting=20 >question about how we represent this in service discovery -=20 >particularly if we cannot manipulate the order or isolate an order=20 >(that's the part I think is new and interesting in your response). > >I think we're agreeing that the work of the NSC workgroup will ignore=20 >the mechanics of such chaining as implementation details and thus not=20 >describe how they are chained - keeping us out of the IPC/RPC bailywick=20 >and focusing only on the description of/standardization of externally=20 >chained services (though, as I mentioned above, representation of that=20 >combined service IS relevant to NSC work). > >Yes? If so, we should make this clear in #2? > >On 9/4/13 11:47 AM, "Ron Parker" wrote: > >>Hi, Ken. >> >>Responding to your comment on REQ #2, from my perspective... >> >>A particular network element (physical or virtual) can definitely support >>multiple service functions simultaneously. Any particular chain may >>invoke any of them in any order. However, I feel that it is an >>implementation specific design issue whether hops between these=20 >>co-resident services literally follow the exact service chaining=20 >>procedures that we ultimately define or simply behave as if they were=20 >>exactly followed (i.e., external-service A to internal-service B to=20 >>internal-service C to external-service D -- only the external A to=20 >>internal B and the internal C to external D are externally observable). >> >> Ron >> >> >>-----Original Message----- >>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >>Ken Gray >>Sent: Wednesday, September 04, 2013 10:53 AM >>To: mohamed.boucadair@orange.com; nsc@ietf.org >>Subject: Re: [nsc] TR: I-D Action: >>draft-boucadair-chaining-requirements-01.txt >> >>Heya, Med. >> >>I gave it a quick read. I have the following questions/observations: >> >>REQ#2 - The document doesn't specifically say whether we're=20 >>constraining our focus on chains that require an "externality" for=20 >>each link (that is, ARE we assuming that each "link" will pass through=20 >>a network/networked element e.g. Hypervisor switch) - and are thus=20 >>excluding from discussion IPC (or RPC) mechanisms between service=20 >>elements on the same device (which are much harder to detect, monitor,=20 >>standardize). >> >>REQ#13 is putting a constraint on the header discussion. Is this the=20 >>right place to put that, particularly since the requirements there=20 >>haven't been fully defined (yet)? >> >>REQ#15 - while I fully appreciate your desire to avoid another 80+=20 >>part email thread on whether MPLS is an overlay, I think you make your=20 >>point well enough in the main assertion and part "b" is actually redundan= t. >>8^) >> >>REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22=20 >>has to be a MUST (I think the need for downstream reclassification can=20 >>be a normal outcome of the function of an individual service element=20 >>as it potentially transforms a header - unless your argument is that=20 >>we should avoid this wherever possible by imbedding a clue in the=20 >>header - in which case we run into issues with "non-speakers" or legacy d= evices). >> >>REQ#23 seems to obviate the use of simple route NH manipulation to=20 >>create a chain (this is destination address based). So, to be=20 >>inclusive, I think that has to be a SHOULD. >> >>REQ#25 seems to be difficult to require if you don't dictate how the=20 >>chain is formed (how the forwarding is instantiated) and should be=20 >>worded more like REQ#29, IMO. >> >>REQ#30 I think you're trying to say that static definition/topology of=20 >>service functions SHOULD be supported but dynamic MUST (not that every=20 >>element has to support dynamic discovery but that the overall goal of=20 >>the ongoing architecture should be dynamic with static augmentation=20 >>for corner/legacy cases) ...which would be more in alignment with the=20 >>tenor of REQ#32. >> >>Thanks for kicking it off and reading this drivel ... >> >> >> >> >> >> >>On 8/27/13 2:58 AM, "mohamed.boucadair@orange.com" >> wrote: >> >>>Dear all, >>> >>>A new version of the requirements draft is now available online. The=20 >>>main changes in this new version are as follows: >>> >>>* Enrich the document with inputs from=20 >>>draft-li-service-chaining-requirements >>>* Welcome authors of draft-li-service-chaining-requirements as=20 >>>co-authors >>>* Add new security-related requirements. >>>* Re-order the requirements >>> >>>A more detailed diff is available at: >>>http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requireme >>>n >>>t >>>s-0 >>>1.txt >>> >>>Feel free to share your comments, suggestions and text contributions=20 >>>on the list or direct them to the authors. >>> >>>Cheers, >>>Med >>> >>>-----Message d'origine----- >>>De : i-d-announce-bounces@ietf.org >>>[mailto:i-d-announce-bounces@ietf.org] >>>De la part de internet-drafts@ietf.org Envoy=E9 : jeudi 22 ao=FBt 2013 >>>14:21 =C0 : i-d-announce@ietf.org Objet : I-D Action: >>>draft-boucadair-chaining-requirements-01.txt >>> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>directories. >>> >>> >>> Title : Requirements for Service Function Chaining >>> Author(s) : Mohamed Boucadair >>> Christian Jacquenet >>> Yuanlong Jiang >>> Hongyu Li >>> Ron Parker >>> Filename : draft-boucadair-chaining-requirements-01.txt >>> Pages : 10 >>> Date : 2013-08-22 >>> >>>Abstract: >>> This document identifies the requirements for the Service Function >>> Chaining. >>> >>> >>> >>>The IETF datatracker status page for this draft is: >>>https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirement >>>s >>> >>>There's also a htmlized version available at: >>>http://tools.ietf.org/html/draft-boucadair-chaining-requirements-01 >>> >>>A diff from the previous version is available at: >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirement >>>s >>>- >>>01 >>> >>> >>>Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>_______________________________________________ >>>I-D-Announce mailing list >>>I-D-Announce@ietf.org >>>https://www.ietf.org/mailman/listinfo/i-d-announce >>>Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >>> >>> >> >> >>_______________________________________________ >>nsc mailing 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 Sep 4 11:06: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 B3FBD21E814C for ; Wed, 4 Sep 2013 11:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 nnyv9b3hZJGR for ; Wed, 4 Sep 2013 11:06: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 743D721E8145 for ; Wed, 4 Sep 2013 11:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11657; q=dns/txt; s=iport; t=1378317984; x=1379527584; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t5HiUFmAItxrO85mZF96VclB8hnpHO8oVc91B2dd1kY=; b=DOdiYayKyGjdTRDlcDKt5QUf6ax4GAY48Sc87NTFFtra+ryMY+GiTLuP ETlShVQZwq+FdKzM7vdYOb2HRk9JL0xcTca3UpwMXfTLGTL8mtFKhgt/T +xoedUIWh36knwqbpF0aFFx7U1a86FjRMPEIY5ItTJfeV4CmDTohvzcMf U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIFAFh2J1KtJV2b/2dsb2JhbABagwc1S8FKgSgWdIIkAQEBAwEBAQFkBwsFBwQCAQgRAQMBAQEnBycLFAMGCAIEDgUJh3MGBwW6Oo4XgRYIKwIFBoMXgQADiH2LHoNagS+LC4UsgyCBcQ X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208";a="255397551" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 04 Sep 2013 18:06:14 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r84I6Db5006742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 18:06:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 13:06:13 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt Thread-Index: Ac6fMhIAzIOqddliRk+cqJ/CnVKw9ADv8zVgAZrASQAACgW9EP//xs+A//+qjJCAAMTAAIAADryA///kHZk= Date: Wed, 4 Sep 2013 18:06:13 +0000 Message-ID: <62B5189A-B3B3-425F-B481-F4439F29A201@cisco.com> References: <68B171751455884590F8E38E96416F363F6758E6@xmb-rcd-x01.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "mohamed.boucadair@orange.com" , Ken Gray Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.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, 04 Sep 2013 18:06:29 -0000 Completely agree. Sent from my iPhone On Sep 4, 2013, at 2:04 PM, "Ron Parker" = wrote: > Hi, Jim. >=20 > I agree that an index is required to support multiple service functions c= o-residing within the same network element. I'll point out that when a ch= ain selects multiple co-resident network functions, there is no requirement= that they be contiguous. For example, a chain with A, B, C where A and C= happen to be co-resident. >=20 > However, this concept of co-residence is orthogonal to virtualization. = The important part, IMO, is that a single managed network element may supp= ort any number of co-resident service functions. That network element cou= ld be a single VM, a cluster of VMs, a single physical server, a cluster of= physical servers, a cluster of blade-based physical servers, etc. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 > Sent: Wednesday, September 04, 2013 1:53 PM > To: Ron Parker; Ken Gray; mohamed.boucadair@orange.com; nsc@ietf.org > Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-= 01.txt >=20 > I would add that if the SF Map Index (aka service path id) also carries a= n index into the service chain (aka SF Map) then regardless of whether the = receiving node is virtual or not it can still determine the placement withi= n the service chain and the necessary service function to apply. > Likewise the context, if carried, can indicate which particular profile o= f a given service function to apply. >=20 > On 9/4/13 1:31 PM, "Ron Parker" wrote: >=20 >> Hi, Ken. >>=20 >> In some of the I'D's we do touch on the logical network function=20 >> concept, but we may need to consolidate and strengthen the requirements = around >> that. Not only can multiple disparate network functions co-reside at >> the same managed network element, but even multiple instances of the=20 >> same type of network function where these instance imply differentiated >> behaviors. For example, the same managed network element may support >> 'firewall-strict', 'firewall-loose', 'content-filter-adult', >> 'content-filter-child', 'dpi-analytics'. A useful service chain may, >> for example, select 'firewall-strict' and 'content-filter-child' plus=20 >> other service functions that happen to reside in other managed network=20 >> elements. >>=20 >> In draft-boucadair-service-chaining-framework, section 9.3, On Service=20 >> Function Profiles (a.k.a., Contexts), we point out that logical service= =20 >> functions can imply differentiated behavior (policy). >>=20 >> In the same I-D, section 5.5, SF Node, we have the text: >> In case several SFs >> are co-located in the same node, the packet is processed by >> all SFs indicated in the SF Map. Once the packet is >> successfully handled by local SF(s), the packet is forwarded >> to the next SF Node in the list or to an intermediate node >> (if the local SFC Node is the last element in the SF Map). >>=20 >> Thanks. >>=20 >> Ron >>=20 >> -----Original Message----- >> From: Ken Gray [mailto:kgray@juniper.net] >> Sent: Wednesday, September 04, 2013 12:15 PM >> To: Ron Parker; mohamed.boucadair@orange.com; nsc@ietf.org >> Subject: Re: [nsc] TR: I-D Action: >> draft-boucadair-chaining-requirements-01.txt >>=20 >> We're bouncing around my point, though you actually bring up an=20 >> ancillary thing of interest. >>=20 >> Assuming that an element performs multiple functions (either as=20 >> multiple virtual machines or as part of it's physical/logical=20 >> architecture as a non-virtual device), then there is an interesting=20 >> question about how we represent this in service discovery -=20 >> particularly if we cannot manipulate the order or isolate an order=20 >> (that's the part I think is new and interesting in your response). >>=20 >> I think we're agreeing that the work of the NSC workgroup will ignore=20 >> the mechanics of such chaining as implementation details and thus not=20 >> describe how they are chained - keeping us out of the IPC/RPC bailywick= =20 >> and focusing only on the description of/standardization of externally=20 >> chained services (though, as I mentioned above, representation of that=20 >> combined service IS relevant to NSC work). >>=20 >> Yes? If so, we should make this clear in #2? >>=20 >> On 9/4/13 11:47 AM, "Ron Parker" wrote= : >>=20 >>> Hi, Ken. >>>=20 >>> Responding to your comment on REQ #2, from my perspective... >>>=20 >>> A particular network element (physical or virtual) can definitely suppo= rt >>> multiple service functions simultaneously. Any particular chain may >>> invoke any of them in any order. However, I feel that it is an >>> implementation specific design issue whether hops between these=20 >>> co-resident services literally follow the exact service chaining=20 >>> procedures that we ultimately define or simply behave as if they were=20 >>> exactly followed (i.e., external-service A to internal-service B to=20 >>> internal-service C to external-service D -- only the external A to=20 >>> internal B and the internal C to external D are externally observable). >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >>> Ken Gray >>> Sent: Wednesday, September 04, 2013 10:53 AM >>> To: mohamed.boucadair@orange.com; nsc@ietf.org >>> Subject: Re: [nsc] TR: I-D Action: >>> draft-boucadair-chaining-requirements-01.txt >>>=20 >>> Heya, Med. >>>=20 >>> I gave it a quick read. I have the following questions/observations: >>>=20 >>> REQ#2 - The document doesn't specifically say whether we're=20 >>> constraining our focus on chains that require an "externality" for=20 >>> each link (that is, ARE we assuming that each "link" will pass through= =20 >>> a network/networked element e.g. Hypervisor switch) - and are thus=20 >>> excluding from discussion IPC (or RPC) mechanisms between service=20 >>> elements on the same device (which are much harder to detect, monitor,= =20 >>> standardize). >>>=20 >>> REQ#13 is putting a constraint on the header discussion. Is this the=20 >>> right place to put that, particularly since the requirements there=20 >>> haven't been fully defined (yet)? >>>=20 >>> REQ#15 - while I fully appreciate your desire to avoid another 80+=20 >>> part email thread on whether MPLS is an overlay, I think you make your= =20 >>> point well enough in the main assertion and part "b" is actually redund= ant. >>> 8^) >>>=20 >>> REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22=20 >>> has to be a MUST (I think the need for downstream reclassification can= =20 >>> be a normal outcome of the function of an individual service element=20 >>> as it potentially transforms a header - unless your argument is that=20 >>> we should avoid this wherever possible by imbedding a clue in the=20 >>> header - in which case we run into issues with "non-speakers" or legacy= devices). >>>=20 >>> REQ#23 seems to obviate the use of simple route NH manipulation to=20 >>> create a chain (this is destination address based). So, to be=20 >>> inclusive, I think that has to be a SHOULD. >>>=20 >>> REQ#25 seems to be difficult to require if you don't dictate how the=20 >>> chain is formed (how the forwarding is instantiated) and should be=20 >>> worded more like REQ#29, IMO. >>>=20 >>> REQ#30 I think you're trying to say that static definition/topology of= =20 >>> service functions SHOULD be supported but dynamic MUST (not that every= =20 >>> element has to support dynamic discovery but that the overall goal of=20 >>> the ongoing architecture should be dynamic with static augmentation=20 >>> for corner/legacy cases) ...which would be more in alignment with the=20 >>> tenor of REQ#32. >>>=20 >>> Thanks for kicking it off and reading this drivel ... >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 8/27/13 2:58 AM, "mohamed.boucadair@orange.com" >>> wrote: >>>=20 >>>> Dear all, >>>>=20 >>>> A new version of the requirements draft is now available online. The=20 >>>> main changes in this new version are as follows: >>>>=20 >>>> * Enrich the document with inputs from=20 >>>> draft-li-service-chaining-requirements >>>> * Welcome authors of draft-li-service-chaining-requirements as=20 >>>> co-authors >>>> * Add new security-related requirements. >>>> * Re-order the requirements >>>>=20 >>>> A more detailed diff is available at: >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirem= e >>>> n >>>> t >>>> s-0 >>>> 1.txt >>>>=20 >>>> Feel free to share your comments, suggestions and text contributions=20 >>>> on the list or direct them to the authors. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>> -----Message d'origine----- >>>> De : i-d-announce-bounces@ietf.org >>>> [mailto:i-d-announce-bounces@ietf.org] >>>> De la part de internet-drafts@ietf.org Envoy=E9 : jeudi 22 ao=FBt 2013 >>>> 14:21 =C0 : i-d-announce@ietf.org Objet : I-D Action: >>>> draft-boucadair-chaining-requirements-01.txt >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>> directories. >>>>=20 >>>>=20 >>>> Title : Requirements for Service Function Chaining >>>> Author(s) : Mohamed Boucadair >>>> Christian Jacquenet >>>> Yuanlong Jiang >>>> Hongyu Li >>>> Ron Parker >>>> Filename : draft-boucadair-chaining-requirements-01.txt >>>> Pages : 10 >>>> Date : 2013-08-22 >>>>=20 >>>> Abstract: >>>> This document identifies the requirements for the Service Function >>>> Chaining. >>>>=20 >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirement >>>> s >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-boucadair-chaining-requirements-01 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requiremen= t >>>> s >>>> - >>>> 01 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of=20 >>>> submission until the htmlized version and diff are available at=20 >>>> tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >=20 From kgray@juniper.net Wed Sep 4 11:10: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 29AC811E81CE for ; Wed, 4 Sep 2013 11:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=-0.900, 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 lSum5DGmDfGI for ; Wed, 4 Sep 2013 11:10:27 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id C137211E80FF for ; Wed, 4 Sep 2013 11:10:26 -0700 (PDT) Received: from mail220-db9-R.bigfish.com (10.174.16.226) by DB9EHSOBE031.bigfish.com (10.174.14.94) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 18:10:12 +0000 Received: from mail220-db9 (localhost [127.0.0.1]) by mail220-db9-R.bigfish.com (Postfix) with ESMTP id B5366800D8; Wed, 4 Sep 2013 18:10:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -77 X-BigFish: VPS-77(zzbb2dI98dI9371Ic89bh936eI1454I148cI542I1432I1418I15caKJ168aJa706lzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail220-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=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(57704003)(24454002)(189002)(199002)(52604005)(51704005)(13464003)(51444003)(52044002)(55784002)(377454003)(479174003)(377424004)(74662001)(31966008)(74502001)(47446002)(74876001)(53806001)(54356001)(80976001)(77096001)(56816003)(83072001)(76482001)(74706001)(15202345003)(54316002)(56776001)(69226001)(59766001)(15975445006)(65816001)(81816001)(46102001)(4396001)(77982001)(19580405001)(80022001)(83506001)(83322001)(81686001)(19580395003)(79102001)(51856001)(74366001)(81342001)(47736001)(49866001)(81542001)(47976001)(50986001)(63696002)(76796001)(76786001)(76176001)(36756003)(427584002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB081; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail220-db9 (localhost.localdomain [127.0.0.1]) by mail220-db9 (MessageSwitch) id 1378318209823895_26959; Wed, 4 Sep 2013 18:10:09 +0000 (UTC) Received: from DB9EHSMHS001.bigfish.com (unknown [10.174.16.252]) by mail220-db9.bigfish.com (Postfix) with ESMTP id BDB9720045; Wed, 4 Sep 2013 18:10:09 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS001.bigfish.com (10.174.14.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 18:10:08 +0000 Received: from BL2PR05MB081.namprd05.prod.outlook.com (10.255.232.14) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 4 Sep 2013 18:10:08 +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.745.25; Wed, 4 Sep 2013 18:10:07 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 18:10:06 +0000 From: Ken Gray To: "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt Thread-Index: Ac6fMhIAzIOqddliRk+cqJ/CnVKw9ADv8zVgAZrASQAACgW9EP//xs+A//+qjJCAAMTAAIAADryA///kHZn//73+AA== Date: Wed, 4 Sep 2013 18:10:06 +0000 Message-ID: In-Reply-To: <62B5189A-B3B3-425F-B481-F4439F29A201@cisco.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: 095972DF2F Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9F6D1DE595D34D49B1EB7109C37879BD@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" , "mohamed.boucadair@orange.com" Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.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, 04 Sep 2013 18:10:32 -0000 Yup. I agree as well. Looping back to #2, are/do we need to explicitly rule out IPC/RPC from the requirements/focus or am I being an @ss for wanting to be so explicit? On 9/4/13 2:06 PM, "Jim Guichard (jguichar)" wrote: >Completely agree. > >Sent from my iPhone > >On Sep 4, 2013, at 2:04 PM, "Ron Parker" > wrote: > >> Hi, Jim. >>=20 >> I agree that an index is required to support multiple service functions >>co-residing within the same network element. I'll point out that when >>a chain selects multiple co-resident network functions, there is no >>requirement that they be contiguous. For example, a chain with A, B, C >>where A and C happen to be co-resident. >>=20 >> However, this concept of co-residence is orthogonal to virtualization. >> The important part, IMO, is that a single managed network element may >>support any number of co-resident service functions. That network >>element could be a single VM, a cluster of VMs, a single physical >>server, a cluster of physical servers, a cluster of blade-based physical >>servers, etc. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Wednesday, September 04, 2013 1:53 PM >> To: Ron Parker; Ken Gray; mohamed.boucadair@orange.com; nsc@ietf.org >> Subject: Re: [nsc] TR: I-D Action: >>draft-boucadair-chaining-requirements-01.txt >>=20 >> I would add that if the SF Map Index (aka service path id) also carries >>an index into the service chain (aka SF Map) then regardless of whether >>the receiving node is virtual or not it can still determine the >>placement within the service chain and the necessary service function to >>apply. >> Likewise the context, if carried, can indicate which particular profile >>of a given service function to apply. >>=20 >> On 9/4/13 1:31 PM, "Ron Parker" wrote: >>=20 >>> Hi, Ken. >>>=20 >>> In some of the I'D's we do touch on the logical network function >>> concept, but we may need to consolidate and strengthen the >>>requirements around >>> that. Not only can multiple disparate network functions co-reside >>>at >>> the same managed network element, but even multiple instances of the >>> same type of network function where these instance imply differentiated >>> behaviors. For example, the same managed network element may support >>> 'firewall-strict', 'firewall-loose', 'content-filter-adult', >>> 'content-filter-child', 'dpi-analytics'. A useful service chain may, >>> for example, select 'firewall-strict' and 'content-filter-child' plus >>> other service functions that happen to reside in other managed network >>> elements. >>>=20 >>> In draft-boucadair-service-chaining-framework, section 9.3, On Service >>> Function Profiles (a.k.a., Contexts), we point out that logical >>>service=20 >>> functions can imply differentiated behavior (policy). >>>=20 >>> In the same I-D, section 5.5, SF Node, we have the text: >>> In case several SFs >>> are co-located in the same node, the packet is processed by >>> all SFs indicated in the SF Map. Once the packet is >>> successfully handled by local SF(s), the packet is forwarded >>> to the next SF Node in the list or to an intermediate node >>> (if the local SFC Node is the last element in the SF Map). >>>=20 >>> Thanks. >>>=20 >>> Ron >>>=20 >>> -----Original Message----- >>> From: Ken Gray [mailto:kgray@juniper.net] >>> Sent: Wednesday, September 04, 2013 12:15 PM >>> To: Ron Parker; mohamed.boucadair@orange.com; nsc@ietf.org >>> Subject: Re: [nsc] TR: I-D Action: >>> draft-boucadair-chaining-requirements-01.txt >>>=20 >>> We're bouncing around my point, though you actually bring up an >>> ancillary thing of interest. >>>=20 >>> Assuming that an element performs multiple functions (either as >>> multiple virtual machines or as part of it's physical/logical >>> architecture as a non-virtual device), then there is an interesting >>> question about how we represent this in service discovery - >>> particularly if we cannot manipulate the order or isolate an order >>> (that's the part I think is new and interesting in your response). >>>=20 >>> I think we're agreeing that the work of the NSC workgroup will ignore >>> the mechanics of such chaining as implementation details and thus not >>> describe how they are chained - keeping us out of the IPC/RPC >>>bailywick=20 >>> and focusing only on the description of/standardization of externally >>> chained services (though, as I mentioned above, representation of that >>> combined service IS relevant to NSC work). >>>=20 >>> Yes? If so, we should make this clear in #2? >>>=20 >>> On 9/4/13 11:47 AM, "Ron Parker" >>>wrote: >>>=20 >>>> Hi, Ken. >>>>=20 >>>> Responding to your comment on REQ #2, from my perspective... >>>>=20 >>>> A particular network element (physical or virtual) can definitely >>>>support >>>> multiple service functions simultaneously. Any particular chain may >>>> invoke any of them in any order. However, I feel that it is an >>>> implementation specific design issue whether hops between these >>>> co-resident services literally follow the exact service chaining >>>> procedures that we ultimately define or simply behave as if they were >>>> exactly followed (i.e., external-service A to internal-service B to >>>> internal-service C to external-service D -- only the external A to >>>> internal B and the internal C to external D are externally >>>>observable). >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>>> Ken Gray >>>> Sent: Wednesday, September 04, 2013 10:53 AM >>>> To: mohamed.boucadair@orange.com; nsc@ietf.org >>>> Subject: Re: [nsc] TR: I-D Action: >>>> draft-boucadair-chaining-requirements-01.txt >>>>=20 >>>> Heya, Med. >>>>=20 >>>> I gave it a quick read. I have the following questions/observations: >>>>=20 >>>> REQ#2 - The document doesn't specifically say whether we're >>>> constraining our focus on chains that require an "externality" for >>>> each link (that is, ARE we assuming that each "link" will pass >>>>through=20 >>>> a network/networked element e.g. Hypervisor switch) - and are thus >>>> excluding from discussion IPC (or RPC) mechanisms between service >>>> elements on the same device (which are much harder to detect, >>>>monitor,=20 >>>> standardize). >>>>=20 >>>> REQ#13 is putting a constraint on the header discussion. Is this the >>>> right place to put that, particularly since the requirements there >>>> haven't been fully defined (yet)? >>>>=20 >>>> REQ#15 - while I fully appreciate your desire to avoid another 80+ >>>> part email thread on whether MPLS is an overlay, I think you make >>>>your=20 >>>> point well enough in the main assertion and part "b" is actually >>>>redundant. >>>> 8^) >>>>=20 >>>> REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22 >>>> has to be a MUST (I think the need for downstream reclassification >>>>can=20 >>>> be a normal outcome of the function of an individual service element >>>> as it potentially transforms a header - unless your argument is that >>>> we should avoid this wherever possible by imbedding a clue in the >>>> header - in which case we run into issues with "non-speakers" or >>>>legacy devices). >>>>=20 >>>> REQ#23 seems to obviate the use of simple route NH manipulation to >>>> create a chain (this is destination address based). So, to be >>>> inclusive, I think that has to be a SHOULD. >>>>=20 >>>> REQ#25 seems to be difficult to require if you don't dictate how the >>>> chain is formed (how the forwarding is instantiated) and should be >>>> worded more like REQ#29, IMO. >>>>=20 >>>> REQ#30 I think you're trying to say that static definition/topology >>>>of=20 >>>> service functions SHOULD be supported but dynamic MUST (not that >>>>every=20 >>>> element has to support dynamic discovery but that the overall goal of >>>> the ongoing architecture should be dynamic with static augmentation >>>> for corner/legacy cases) ...which would be more in alignment with the >>>> tenor of REQ#32. >>>>=20 >>>> Thanks for kicking it off and reading this drivel ... >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 8/27/13 2:58 AM, "mohamed.boucadair@orange.com" >>>> wrote: >>>>=20 >>>>> Dear all, >>>>>=20 >>>>> A new version of the requirements draft is now available online. The >>>>> main changes in this new version are as follows: >>>>>=20 >>>>> * Enrich the document with inputs from >>>>> draft-li-service-chaining-requirements >>>>> * Welcome authors of draft-li-service-chaining-requirements as >>>>> co-authors >>>>> * Add new security-related requirements. >>>>> * Re-order the requirements >>>>>=20 >>>>> A more detailed diff is available at: >>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-require= me >>>>> n >>>>> t >>>>> s-0 >>>>> 1.txt >>>>>=20 >>>>> Feel free to share your comments, suggestions and text contributions >>>>> on the list or direct them to the authors. >>>>>=20 >>>>> Cheers, >>>>> Med >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : i-d-announce-bounces@ietf.org >>>>> [mailto:i-d-announce-bounces@ietf.org] >>>>> De la part de internet-drafts@ietf.org Envoy=E9 : jeudi 22 ao=FBt 201= 3 >>>>> 14:21 =C0 : i-d-announce@ietf.org Objet : I-D Action: >>>>> draft-boucadair-chaining-requirements-01.txt >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>>=20 >>>>>=20 >>>>> Title : Requirements for Service Function Chaining >>>>> Author(s) : Mohamed Boucadair >>>>> Christian Jacquenet >>>>> Yuanlong Jiang >>>>> Hongyu Li >>>>> Ron Parker >>>>> Filename : draft-boucadair-chaining-requirements-01.txt >>>>> Pages : 10 >>>>> Date : 2013-08-22 >>>>>=20 >>>>> Abstract: >>>>> This document identifies the requirements for the Service Function >>>>> Chaining. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirement >>>>> s >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-boucadair-chaining-requirements-01 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requireme= nt >>>>> s >>>>> - >>>>> 01 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 > > From Ron_Parker@affirmednetworks.com Wed Sep 4 11:12: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 75AF621F9473 for ; Wed, 4 Sep 2013 11:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 gduuD2SpEilD for ; Wed, 4 Sep 2013 11:12:35 -0700 (PDT) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id B673121F93C4 for ; Wed, 4 Sep 2013 11:12:35 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0123.003; Wed, 4 Sep 2013 11:12:34 -0700 From: Ron Parker To: Ken Gray , "Jim Guichard (jguichar)" Thread-Topic: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt Thread-Index: Ac6fMhIAzIOqddliRk+cqJ/CnVKw9ADv8zVgAZrASQAACgW9EP//xs+A//+qjJCAAMTAAIAADryA///kHZn//73+AP//vLAw Date: Wed, 4 Sep 2013 18:12:35 +0000 Message-ID: References: <62B5189A-B3B3-425F-B481-F4439F29A201@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "mohamed.boucadair@orange.com" Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.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, 04 Sep 2013 18:12:40 -0000 I feel that we could explicitly rule out specification of the details of in= tra-network-element IPC/RPC as an implementation detail. Ron -----Original Message----- From: Ken Gray [mailto:kgray@juniper.net]=20 Sent: Wednesday, September 04, 2013 2:10 PM To: Jim Guichard (jguichar); Ron Parker Cc: mohamed.boucadair@orange.com; nsc@ietf.org Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01= .txt Yup. I agree as well. Looping back to #2, are/do we need to explicitly ru= le out IPC/RPC from the requirements/focus or am I being an @ss for wanting= to be so explicit? On 9/4/13 2:06 PM, "Jim Guichard (jguichar)" wrote: >Completely agree. > >Sent from my iPhone > >On Sep 4, 2013, at 2:04 PM, "Ron Parker" > wrote: > >> Hi, Jim. >>=20 >> I agree that an index is required to support multiple service functions >>co-residing within the same network element. I'll point out that when >>a chain selects multiple co-resident network functions, there is no >>requirement that they be contiguous. For example, a chain with A, B, C >>where A and C happen to be co-resident. >>=20 >> However, this concept of co-residence is orthogonal to virtualization. >> The important part, IMO, is that a single managed network element may >>support any number of co-resident service functions. That network >>element could be a single VM, a cluster of VMs, a single physical=20 >>server, a cluster of physical servers, a cluster of blade-based=20 >>physical servers, etc. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Wednesday, September 04, 2013 1:53 PM >> To: Ron Parker; Ken Gray; mohamed.boucadair@orange.com; nsc@ietf.org >> Subject: Re: [nsc] TR: I-D Action: >>draft-boucadair-chaining-requirements-01.txt >>=20 >> I would add that if the SF Map Index (aka service path id) also=20 >>carries an index into the service chain (aka SF Map) then regardless=20 >>of whether the receiving node is virtual or not it can still determine=20 >>the placement within the service chain and the necessary service=20 >>function to apply. >> Likewise the context, if carried, can indicate which particular=20 >>profile of a given service function to apply. >>=20 >> On 9/4/13 1:31 PM, "Ron Parker" wrote: >>=20 >>> Hi, Ken. >>>=20 >>> In some of the I'D's we do touch on the logical network function =20 >>>concept, but we may need to consolidate and strengthen the=20 >>>requirements around >>> that. Not only can multiple disparate network functions co-reside >>>at >>> the same managed network element, but even multiple instances of the =20 >>>same type of network function where these instance imply differentiated >>> behaviors. For example, the same managed network element may support >>> 'firewall-strict', 'firewall-loose', 'content-filter-adult', >>> 'content-filter-child', 'dpi-analytics'. A useful service chain may, >>> for example, select 'firewall-strict' and 'content-filter-child'=20 >>>plus other service functions that happen to reside in other managed=20 >>>network elements. >>>=20 >>> In draft-boucadair-service-chaining-framework, section 9.3, On=20 >>>Service Function Profiles (a.k.a., Contexts), we point out that=20 >>>logical service functions can imply differentiated behavior=20 >>>(policy). >>>=20 >>> In the same I-D, section 5.5, SF Node, we have the text: >>> In case several SFs >>> are co-located in the same node, the packet is processed by >>> all SFs indicated in the SF Map. Once the packet is >>> successfully handled by local SF(s), the packet is forwarded >>> to the next SF Node in the list or to an intermediate node >>> (if the local SFC Node is the last element in the SF Map). >>>=20 >>> Thanks. >>>=20 >>> Ron >>>=20 >>> -----Original Message----- >>> From: Ken Gray [mailto:kgray@juniper.net] >>> Sent: Wednesday, September 04, 2013 12:15 PM >>> To: Ron Parker; mohamed.boucadair@orange.com; nsc@ietf.org >>> Subject: Re: [nsc] TR: I-D Action: >>> draft-boucadair-chaining-requirements-01.txt >>>=20 >>> We're bouncing around my point, though you actually bring up an=20 >>> ancillary thing of interest. >>>=20 >>> Assuming that an element performs multiple functions (either as=20 >>> multiple virtual machines or as part of it's physical/logical=20 >>> architecture as a non-virtual device), then there is an interesting=20 >>> question about how we represent this in service discovery -=20 >>> particularly if we cannot manipulate the order or isolate an order=20 >>> (that's the part I think is new and interesting in your response). >>>=20 >>> I think we're agreeing that the work of the NSC workgroup will=20 >>>ignore the mechanics of such chaining as implementation details and=20 >>>thus not describe how they are chained - keeping us out of the=20 >>>IPC/RPC bailywick and focusing only on the description=20 >>>of/standardization of externally chained services (though, as I=20 >>>mentioned above, representation of that combined service IS relevant=20 >>>to NSC work). >>>=20 >>> Yes? If so, we should make this clear in #2? >>>=20 >>> On 9/4/13 11:47 AM, "Ron Parker" >>>wrote: >>>=20 >>>> Hi, Ken. >>>>=20 >>>> Responding to your comment on REQ #2, from my perspective... >>>>=20 >>>> A particular network element (physical or virtual) can definitely=20 >>>>support >>>> multiple service functions simultaneously. Any particular chain may >>>> invoke any of them in any order. However, I feel that it is an >>>> implementation specific design issue whether hops between these =20 >>>>co-resident services literally follow the exact service chaining =20 >>>>procedures that we ultimately define or simply behave as if they=20 >>>>were exactly followed (i.e., external-service A to internal-service=20 >>>>B to internal-service C to external-service D -- only the external=20 >>>>A to internal B and the internal C to external D are externally=20 >>>>observable). >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>>> Of Ken Gray >>>> Sent: Wednesday, September 04, 2013 10:53 AM >>>> To: mohamed.boucadair@orange.com; nsc@ietf.org >>>> Subject: Re: [nsc] TR: I-D Action: >>>> draft-boucadair-chaining-requirements-01.txt >>>>=20 >>>> Heya, Med. >>>>=20 >>>> I gave it a quick read. I have the following questions/observations: >>>>=20 >>>> REQ#2 - The document doesn't specifically say whether we're =20 >>>>constraining our focus on chains that require an "externality" for =20 >>>>each link (that is, ARE we assuming that each "link" will pass=20 >>>>through a network/networked element e.g. Hypervisor switch) - and=20 >>>>are thus excluding from discussion IPC (or RPC) mechanisms between=20 >>>>service elements on the same device (which are much harder to=20 >>>>detect, monitor, standardize). >>>>=20 >>>> REQ#13 is putting a constraint on the header discussion. Is this=20 >>>> the right place to put that, particularly since the requirements=20 >>>> there haven't been fully defined (yet)? >>>>=20 >>>> REQ#15 - while I fully appreciate your desire to avoid another 80+ =20 >>>>part email thread on whether MPLS is an overlay, I think you make=20 >>>>your point well enough in the main assertion and part "b" is=20 >>>>actually redundant. >>>> 8^) >>>>=20 >>>> REQ #19 part "a" seems to clash a bit with REQ#22 and I think=20 >>>>REQ#22 has to be a MUST (I think the need for downstream=20 >>>>reclassification can be a normal outcome of the function of an=20 >>>>individual service element as it potentially transforms a header -=20 >>>>unless your argument is that we should avoid this wherever possible=20 >>>>by imbedding a clue in the header - in which case we run into=20 >>>>issues with "non-speakers" or legacy devices). >>>>=20 >>>> REQ#23 seems to obviate the use of simple route NH manipulation to=20 >>>> create a chain (this is destination address based). So, to be=20 >>>> inclusive, I think that has to be a SHOULD. >>>>=20 >>>> REQ#25 seems to be difficult to require if you don't dictate how=20 >>>> the chain is formed (how the forwarding is instantiated) and should=20 >>>> be worded more like REQ#29, IMO. >>>>=20 >>>> REQ#30 I think you're trying to say that static definition/topology=20 >>>>of service functions SHOULD be supported but dynamic MUST (not that=20 >>>>every element has to support dynamic discovery but that the overall=20 >>>>goal of the ongoing architecture should be dynamic with static=20 >>>>augmentation for corner/legacy cases) ...which would be more in=20 >>>>alignment with the tenor of REQ#32. >>>>=20 >>>> Thanks for kicking it off and reading this drivel ... >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 8/27/13 2:58 AM, "mohamed.boucadair@orange.com" >>>> wrote: >>>>=20 >>>>> Dear all, >>>>>=20 >>>>> A new version of the requirements draft is now available online.=20 >>>>> The main changes in this new version are as follows: >>>>>=20 >>>>> * Enrich the document with inputs from=20 >>>>> draft-li-service-chaining-requirements >>>>> * Welcome authors of draft-li-service-chaining-requirements as=20 >>>>> co-authors >>>>> * Add new security-related requirements. >>>>> * Re-order the requirements >>>>>=20 >>>>> A more detailed diff is available at: >>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requir >>>>> eme >>>>> n >>>>> t >>>>> s-0 >>>>> 1.txt >>>>>=20 >>>>> Feel free to share your comments, suggestions and text=20 >>>>> contributions on the list or direct them to the authors. >>>>>=20 >>>>> Cheers, >>>>> Med >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : i-d-announce-bounces@ietf.org=20 >>>>> [mailto:i-d-announce-bounces@ietf.org] >>>>> De la part de internet-drafts@ietf.org Envoy=E9 : jeudi 22 ao=FBt 201= 3 >>>>> 14:21 =C0 : i-d-announce@ietf.org Objet : I-D Action: >>>>> draft-boucadair-chaining-requirements-01.txt >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>>> directories. >>>>>=20 >>>>>=20 >>>>> Title : Requirements for Service Function Chaining >>>>> Author(s) : Mohamed Boucadair >>>>> Christian Jacquenet >>>>> Yuanlong Jiang >>>>> Hongyu Li >>>>> Ron Parker >>>>> Filename : draft-boucadair-chaining-requirements-01.txt >>>>> Pages : 10 >>>>> Date : 2013-08-22 >>>>>=20 >>>>> Abstract: >>>>> This document identifies the requirements for the Service=20 >>>>> Function Chaining. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirem >>>>> ent >>>>> s >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-boucadair-chaining-requirements-0 >>>>> 1 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirem >>>>> ent >>>>> s >>>>> - >>>>> 01 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of=20 >>>>> submission until the htmlized version and diff are available at=20 >>>>> tools.ietf.org. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 > > From jguichar@cisco.com Wed Sep 4 11:15:02 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A61111E81CE for ; Wed, 4 Sep 2013 11:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 w8GxNMHUY1AB for ; Wed, 4 Sep 2013 11:14:57 -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 426B621F93C4 for ; Wed, 4 Sep 2013 11:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13274; q=dns/txt; s=iport; t=1378318497; x=1379528097; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tjpUYumWG+voEUVln6khop3yGv5W3aBgDRp7NncJw4k=; b=HBHv43o8OoxLXUNYnCZoFnhfI3BUsJZv3nAk7t4ki8gbUsQ5Qjpm9YF6 GqvlbAW4Nmbe/E3zaghhc0UXvk395VXAFMYt0dXMKRoDKfdrt8xEcpBwO GwMlGk/BShJ8V5vY6u7AGRMhTuR2BnDcuokGswOvaKKYThS1D95oJ0kl7 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIFAIZ3J1KtJXG+/2dsb2JhbABagwc1S8FKgSgWdIIkAQEBAwEBAQFkBwsFBwQCAQgRAQMBAQEnBycLFAMGCAIEDgUJh3MGBwW6OI4XgRYIKwIFBoMXgQADiH2LHoNagS+LC4UsgyCBcQ X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208";a="255567985" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 04 Sep 2013 18:14:56 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r84IEuFl005241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 18:14:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 13:14:55 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt Thread-Index: Ac6fMhIAzIOqddliRk+cqJ/CnVKw9ADv8zVgAZrASQAACgW9EP//xs+A//+qjJCAAMTAAIAADryA///kHZn//73+AP//vLAw//94P+E= Date: Wed, 4 Sep 2013 18:14:55 +0000 Message-ID: References: <62B5189A-B3B3-425F-B481-F4439F29A201@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "mohamed.boucadair@orange.com" , Ken Gray Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.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, 04 Sep 2013 18:15:02 -0000 I also see that as an implementation detail.=20 Sent from my iPhone On Sep 4, 2013, at 2:12 PM, "Ron Parker" = wrote: > I feel that we could explicitly rule out specification of the details of = intra-network-element IPC/RPC as an implementation detail. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Ken Gray [mailto:kgray@juniper.net]=20 > Sent: Wednesday, September 04, 2013 2:10 PM > To: Jim Guichard (jguichar); Ron Parker > Cc: mohamed.boucadair@orange.com; nsc@ietf.org > Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-= 01.txt >=20 > Yup. I agree as well. Looping back to #2, are/do we need to explicitly = rule out IPC/RPC from the requirements/focus or am I being an @ss for wanti= ng to be so explicit? >=20 > On 9/4/13 2:06 PM, "Jim Guichard (jguichar)" wrote: >=20 >> Completely agree. >>=20 >> Sent from my iPhone >>=20 >> On Sep 4, 2013, at 2:04 PM, "Ron Parker" >> wrote: >>=20 >>> Hi, Jim. >>>=20 >>> I agree that an index is required to support multiple service functions >>> co-residing within the same network element. I'll point out that when >>> a chain selects multiple co-resident network functions, there is no >>> requirement that they be contiguous. For example, a chain with A, B, = C >>> where A and C happen to be co-resident. >>>=20 >>> However, this concept of co-residence is orthogonal to virtualization. >>> The important part, IMO, is that a single managed network element may >>> support any number of co-resident service functions. That network >>> element could be a single VM, a cluster of VMs, a single physical=20 >>> server, a cluster of physical servers, a cluster of blade-based=20 >>> physical servers, etc. >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, September 04, 2013 1:53 PM >>> To: Ron Parker; Ken Gray; mohamed.boucadair@orange.com; nsc@ietf.org >>> Subject: Re: [nsc] TR: I-D Action: >>> draft-boucadair-chaining-requirements-01.txt >>>=20 >>> I would add that if the SF Map Index (aka service path id) also=20 >>> carries an index into the service chain (aka SF Map) then regardless=20 >>> of whether the receiving node is virtual or not it can still determine= =20 >>> the placement within the service chain and the necessary service=20 >>> function to apply. >>> Likewise the context, if carried, can indicate which particular=20 >>> profile of a given service function to apply. >>>=20 >>> On 9/4/13 1:31 PM, "Ron Parker" wrote= : >>>=20 >>>> Hi, Ken. >>>>=20 >>>> In some of the I'D's we do touch on the logical network function =20 >>>> concept, but we may need to consolidate and strengthen the=20 >>>> requirements around >>>> that. Not only can multiple disparate network functions co-reside >>>> at >>>> the same managed network element, but even multiple instances of the = =20 >>>> same type of network function where these instance imply differentiate= d >>>> behaviors. For example, the same managed network element may support >>>> 'firewall-strict', 'firewall-loose', 'content-filter-adult', >>>> 'content-filter-child', 'dpi-analytics'. A useful service chain may= , >>>> for example, select 'firewall-strict' and 'content-filter-child'=20 >>>> plus other service functions that happen to reside in other managed=20 >>>> network elements. >>>>=20 >>>> In draft-boucadair-service-chaining-framework, section 9.3, On=20 >>>> Service Function Profiles (a.k.a., Contexts), we point out that=20 >>>> logical service functions can imply differentiated behavior=20 >>>> (policy). >>>>=20 >>>> In the same I-D, section 5.5, SF Node, we have the text: >>>> In case several SFs >>>> are co-located in the same node, the packet is processed by >>>> all SFs indicated in the SF Map. Once the packet is >>>> successfully handled by local SF(s), the packet is forwarded >>>> to the next SF Node in the list or to an intermediate node >>>> (if the local SFC Node is the last element in the SF Map). >>>>=20 >>>> Thanks. >>>>=20 >>>> Ron >>>>=20 >>>> -----Original Message----- >>>> From: Ken Gray [mailto:kgray@juniper.net] >>>> Sent: Wednesday, September 04, 2013 12:15 PM >>>> To: Ron Parker; mohamed.boucadair@orange.com; nsc@ietf.org >>>> Subject: Re: [nsc] TR: I-D Action: >>>> draft-boucadair-chaining-requirements-01.txt >>>>=20 >>>> We're bouncing around my point, though you actually bring up an=20 >>>> ancillary thing of interest. >>>>=20 >>>> Assuming that an element performs multiple functions (either as=20 >>>> multiple virtual machines or as part of it's physical/logical=20 >>>> architecture as a non-virtual device), then there is an interesting=20 >>>> question about how we represent this in service discovery -=20 >>>> particularly if we cannot manipulate the order or isolate an order=20 >>>> (that's the part I think is new and interesting in your response). >>>>=20 >>>> I think we're agreeing that the work of the NSC workgroup will=20 >>>> ignore the mechanics of such chaining as implementation details and=20 >>>> thus not describe how they are chained - keeping us out of the=20 >>>> IPC/RPC bailywick and focusing only on the description=20 >>>> of/standardization of externally chained services (though, as I=20 >>>> mentioned above, representation of that combined service IS relevant= =20 >>>> to NSC work). >>>>=20 >>>> Yes? If so, we should make this clear in #2? >>>>=20 >>>> On 9/4/13 11:47 AM, "Ron Parker" >>>> wrote: >>>>=20 >>>>> Hi, Ken. >>>>>=20 >>>>> Responding to your comment on REQ #2, from my perspective... >>>>>=20 >>>>> A particular network element (physical or virtual) can definitely=20 >>>>> support >>>>> multiple service functions simultaneously. Any particular chain may >>>>> invoke any of them in any order. However, I feel that it is an >>>>> implementation specific design issue whether hops between these =20 >>>>> co-resident services literally follow the exact service chaining =20 >>>>> procedures that we ultimately define or simply behave as if they=20 >>>>> were exactly followed (i.e., external-service A to internal-service= =20 >>>>> B to internal-service C to external-service D -- only the external=20 >>>>> A to internal B and the internal C to external D are externally=20 >>>>> observable). >>>>>=20 >>>>> Ron >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>>>> Of Ken Gray >>>>> Sent: Wednesday, September 04, 2013 10:53 AM >>>>> To: mohamed.boucadair@orange.com; nsc@ietf.org >>>>> Subject: Re: [nsc] TR: I-D Action: >>>>> draft-boucadair-chaining-requirements-01.txt >>>>>=20 >>>>> Heya, Med. >>>>>=20 >>>>> I gave it a quick read. I have the following questions/observations: >>>>>=20 >>>>> REQ#2 - The document doesn't specifically say whether we're =20 >>>>> constraining our focus on chains that require an "externality" for =20 >>>>> each link (that is, ARE we assuming that each "link" will pass=20 >>>>> through a network/networked element e.g. Hypervisor switch) - and=20 >>>>> are thus excluding from discussion IPC (or RPC) mechanisms between=20 >>>>> service elements on the same device (which are much harder to=20 >>>>> detect, monitor, standardize). >>>>>=20 >>>>> REQ#13 is putting a constraint on the header discussion. Is this=20 >>>>> the right place to put that, particularly since the requirements=20 >>>>> there haven't been fully defined (yet)? >>>>>=20 >>>>> REQ#15 - while I fully appreciate your desire to avoid another 80+ =20 >>>>> part email thread on whether MPLS is an overlay, I think you make=20 >>>>> your point well enough in the main assertion and part "b" is=20 >>>>> actually redundant. >>>>> 8^) >>>>>=20 >>>>> REQ #19 part "a" seems to clash a bit with REQ#22 and I think=20 >>>>> REQ#22 has to be a MUST (I think the need for downstream=20 >>>>> reclassification can be a normal outcome of the function of an=20 >>>>> individual service element as it potentially transforms a header -=20 >>>>> unless your argument is that we should avoid this wherever possible= =20 >>>>> by imbedding a clue in the header - in which case we run into=20 >>>>> issues with "non-speakers" or legacy devices). >>>>>=20 >>>>> REQ#23 seems to obviate the use of simple route NH manipulation to=20 >>>>> create a chain (this is destination address based). So, to be=20 >>>>> inclusive, I think that has to be a SHOULD. >>>>>=20 >>>>> REQ#25 seems to be difficult to require if you don't dictate how=20 >>>>> the chain is formed (how the forwarding is instantiated) and should=20 >>>>> be worded more like REQ#29, IMO. >>>>>=20 >>>>> REQ#30 I think you're trying to say that static definition/topology=20 >>>>> of service functions SHOULD be supported but dynamic MUST (not that= =20 >>>>> every element has to support dynamic discovery but that the overall= =20 >>>>> goal of the ongoing architecture should be dynamic with static=20 >>>>> augmentation for corner/legacy cases) ...which would be more in=20 >>>>> alignment with the tenor of REQ#32. >>>>>=20 >>>>> Thanks for kicking it off and reading this drivel ... >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 8/27/13 2:58 AM, "mohamed.boucadair@orange.com" >>>>> wrote: >>>>>=20 >>>>>> Dear all, >>>>>>=20 >>>>>> A new version of the requirements draft is now available online.=20 >>>>>> The main changes in this new version are as follows: >>>>>>=20 >>>>>> * Enrich the document with inputs from=20 >>>>>> draft-li-service-chaining-requirements >>>>>> * Welcome authors of draft-li-service-chaining-requirements as=20 >>>>>> co-authors >>>>>> * Add new security-related requirements. >>>>>> * Re-order the requirements >>>>>>=20 >>>>>> A more detailed diff is available at: >>>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requir >>>>>> eme >>>>>> n >>>>>> t >>>>>> s-0 >>>>>> 1.txt >>>>>>=20 >>>>>> Feel free to share your comments, suggestions and text=20 >>>>>> contributions on the list or direct them to the authors. >>>>>>=20 >>>>>> Cheers, >>>>>> Med >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : i-d-announce-bounces@ietf.org=20 >>>>>> [mailto:i-d-announce-bounces@ietf.org] >>>>>> De la part de internet-drafts@ietf.org Envoy=E9 : jeudi 22 ao=FBt 20= 13 >>>>>> 14:21 =C0 : i-d-announce@ietf.org Objet : I-D Action: >>>>>> draft-boucadair-chaining-requirements-01.txt >>>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>>>> directories. >>>>>>=20 >>>>>>=20 >>>>>> Title : Requirements for Service Function Chaining >>>>>> Author(s) : Mohamed Boucadair >>>>>> Christian Jacquenet >>>>>> Yuanlong Jiang >>>>>> Hongyu Li >>>>>> Ron Parker >>>>>> Filename : draft-boucadair-chaining-requirements-01.txt >>>>>> Pages : 10 >>>>>> Date : 2013-08-22 >>>>>>=20 >>>>>> Abstract: >>>>>> This document identifies the requirements for the Service=20 >>>>>> Function Chaining. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirem >>>>>> ent >>>>>> s >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-boucadair-chaining-requirements-0 >>>>>> 1 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirem >>>>>> ent >>>>>> s >>>>>> - >>>>>> 01 >>>>>>=20 >>>>>>=20 >>>>>> Please note that it may take a couple of minutes from the time of=20 >>>>>> submission until the htmlized version and diff are available at=20 >>>>>> tools.ietf.org. >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >=20 >=20 From jmh@joelhalpern.com Wed Sep 4 11:33: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 1D6A711E80E7 for ; Wed, 4 Sep 2013 11:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 IloiX-caFGp4 for ; Wed, 4 Sep 2013 11:33:09 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 29D7111E8103 for ; Wed, 4 Sep 2013 11:33:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id F38FB1C05A8; Wed, 4 Sep 2013 11:33:08 -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 66BCE1C0772; Wed, 4 Sep 2013 11:33:06 -0700 (PDT) Message-ID: <52277CE1.60805@joelhalpern.com> Date: Wed, 04 Sep 2013 14:33:05 -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: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 18:33:15 -0000 Clipping for focus... On 9/4/13 10:05 AM, mohamed.boucadair@orange.com wrote: > Hi Jim, > > Thank you for preparing the text. ... > To sum up: my suggestion is to go for this set of deliverables: > > (a) Problem Statement document > > (b) Framework document (terminology, functional elements, architecture, > and overall procedure) > > (c) Requirements document > > (d) Design Analysis document > > (e) Specification document(s) > > I wouldn’t object if the first charter of the future WG covers only > items (a) to (d). An updated charter can be envisaged once the future WG > has more visibility on the detailed set of specification documents. > > Cheers, > > Med I find this list difficult to understand. And the omissions of certain items from the previous proposal cause me personally some concern. Separating the problem statement, framework, requirements, and "design analysis" produces a multiplicity of documents which will divide the WGs efforts without, as far as I can tell, improving clarity. I also find the notion of a Design Analysis odd. What we need is an architecture or design to drive the protocol effort. From where I sit, we need to pick an approach to the problem, and document that pick. In many ways, it is quite likely that we will have to pick simply because a choice is needed, not because one is universally better than another. I would strongly prefer that the focus of the document be on the actual answer. Similarly, while I find use case drafts useful information for the WG to consider, I think that arguing about which use cases we should put in an RFC, would not be a good use of the WGs time and energy. Some discussion of importance is inevitable as we decide which pieces of the problem to solve well, which pieces to solve awkwardly, and which pieces not to solve. Yours, Joel From damascene.joachimpillai@verizon.com Wed Sep 4 11:41:36 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEAE21E8054 for ; Wed, 4 Sep 2013 11:41:36 -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 os3JGU661hKZ for ; Wed, 4 Sep 2013 11:41:36 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC1311E8104 for ; Wed, 4 Sep 2013 11:41:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 04 Sep 2013 18:41:35 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208";a="540735567" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 04 Sep 2013 18:41:35 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Wed, 4 Sep 2013 14:41:35 -0400 To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" Date: Wed, 4 Sep 2013 14:41:33 -0400 Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: Ac6pnTssjGimBAbpQ121burQuzM+5AAARlfg Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB012331637F@FHDP1LUMXC7V31.us.one.verizon.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> <52277CE1.60805@joelhalpern.com> In-Reply-To: <52277CE1.60805@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 18:41:36 -0000 I completely concur with Joel here. I think we need two things: 1) A clear problem statement 2) An Architecture that addresses the problem=20 Once these two are established then we can go into the details of how. -- DJ -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Joel = M. Halpern Sent: Wednesday, September 04, 2013 2:33 PM To: mohamed.boucadair@orange.com Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] NSC Working Group Charter Proposal Clipping for focus... On 9/4/13 10:05 AM, mohamed.boucadair@orange.com wrote: > Hi Jim, > > Thank you for preparing the text. ... > To sum up: my suggestion is to go for this set of deliverables: > > (a) Problem Statement document > > (b) Framework document (terminology, functional elements,=20 > architecture, and overall procedure) > > (c) Requirements document > > (d) Design Analysis document > > (e) Specification document(s) > > I wouldn't object if the first charter of the future WG covers only=20 > items (a) to (d). An updated charter can be envisaged once the future=20 > WG has more visibility on the detailed set of specification documents. > > Cheers, > > Med I find this list difficult to understand. And the omissions of certain ite= ms from the previous proposal cause me personally some concern. Separating the problem statement, framework, requirements, and "design anal= ysis" produces a multiplicity of documents which will divide the WGs effort= s without, as far as I can tell, improving clarity. I also find the notion of a Design Analysis odd. What we need is an archit= ecture or design to drive the protocol effort. From where I sit, we need t= o pick an approach to the problem, and document that pick. In many ways, i= t is quite likely that we will have to pick simply because a choice is need= ed, not because one is universally better than another. I would strongly p= refer that the focus of the document be on the actual answer. Similarly, while I find use case drafts useful information for the WG to co= nsider, I think that arguing about which use cases we should put in an RFC,= would not be a good use of the WGs time and energy. Some discussion of im= portance is inevitable as we decide which pieces of the problem to solve we= ll, which pieces to solve awkwardly, and which pieces not to solve. Yours, Joel _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Wed Sep 4 11:51: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 E0B1621E80DA for ; Wed, 4 Sep 2013 11:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.811 X-Spam-Level: X-Spam-Status: No, score=-5.811 tagged_above=-999 required=5 tests=[AWL=0.188, 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 OSMPUujV6uyb for ; Wed, 4 Sep 2013 11:50:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 633B621E8054 for ; Wed, 4 Sep 2013 11:50:49 -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.5-GA FastPath queued) with ESMTP id AWX22884; Wed, 04 Sep 2013 18:50:46 +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.146.0; Wed, 4 Sep 2013 19:50:28 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 19:50:44 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 11:50:39 -0700 From: Linda Dunbar To: Ken Gray , Ron Parker , Thomas Nadeau Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqOMaexl2TK45oEebqJb9MjX0ypm0iPEwgACBtAD//4uI4IAAdwmA//+LeYCAAJr/AIAAjMgAgACVfgD//5cMoA== Date: Wed, 4 Sep 2013 18:50:39 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9D390@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645B9D19E@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.192.11.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Thomas Narten , "adrian@olddog.co.uk" , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 18:51:05 -0000 Ken,=20 You brought up a very good point, about I2RS.=20 I see I2RS as a mechanism to chain L3 service modules. If NSC also covers t= he L3 service function chaining, are the use cases similar to I2RS' use cas= es? Or different?=20 Linda > -----Original Message----- > From: Ken Gray [mailto:kgray@juniper.net] > Sent: Wednesday, September 04, 2013 1:04 PM > To: Linda Dunbar; Ron Parker; Thomas Nadeau > Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant (stbryant); > adrian@olddog.co.uk; Thomas Narten > Subject: Re: [nsc] NSC BoF Outcomes >=20 > In line ... >=20 > On 9/4/13 12:17 PM, "Linda Dunbar" wrote: >=20 > >Ron, > > > >My comments are inserted below: > >> -----Original Message----- > >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> Sent: Tuesday, September 03, 2013 7:46 PM > >> To: Linda Dunbar; Thomas Nadeau > >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; > >> adrian@olddog.co.uk; Stewart Bryant (stbryant) > >> Subject: RE: [nsc] NSC BoF Outcomes > >> > >> Hi, Linda. > >> > >> With respect to: > >> > >> - Layer 4 to Layer 7 service functions (or service nodes) are to > >> apply actions to data packets traversing through. They don't impact > >> overall network topologies/routes/restorations. > >> > >> Layer 4-7 services can, indeed, impact routing decisions. For > example, > >> if the service is DPI analysis, then a detected protocol may cause > the > >> subsequent packets to be policy routed on a path different than the > SPF > >> path. > > > >[Linda] Do you call this "DPI" function that re-direct data frames to > a > >different target (that is not the Destination of the data frame) > "Layer > >3" service? > >When those "DPI" functions re-direct traffic, do they add another > >Destination address to the data frames (i.e. create a tunnel)? Or do > they > >not touch the destination addresses in the existing data frames and > >expect all the nodes along the way to know how to forward the data > frames? >=20 > I fail to see the point of the question. >=20 > > > > > > > >Bottom line, those services need to be distinguished from traditional > >Layer 3 services, and be distinguished from routers/switches that > >dynamically establish topology, establish routes, and restoration > paths. >=20 > Disagree. Bump-in-the-wire - to me, that's what this ALL > is ...you > are making a distinction that is very temporary and (IMO) unnecessary. > What you describe as something "dynamically establish topology" is > morphing (heck, with the help of I2RS - sooner rather than later) to > some > different definition of dynamic than we have today. Bump-in-wire. >=20 > > > > > > > > > > > >Linda > > > > > > > >> > >> Ron > >> > >> > >> -----Original Message----- > >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > >> Linda Dunbar > >> Sent: Tuesday, September 03, 2013 6:48 PM > >> To: Thomas Nadeau > >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; > >> adrian@olddog.co.uk; Stewart Bryant (stbryant) > >> Subject: Re: [nsc] NSC BoF Outcomes > >> > >> Here are some of the reasons that chaining of Layer 2 and 3 service > >> functions are different from chaining of Layer 4 to 7 service > functions > >> (I will add more later): > >> > >> > >> - Layer 4 to Layer 7 service functions (or service nodes) are to > apply > >> actions to data packets traversing through. They don't impact > overall > >> network topologies/routes/restorations. > >> > >> - Layer 4-7 service functions drop, pass, consume, re-initiate > packets, > >> etc. They don't change network topologies, and they don't impact > >> network restoration scheme (e.g. fast re-route). When you move a > Layer > >> 4 service module from Location A to B, the Layer 2/3 topology is not > >> changed, routes/restoration are not changed. > >> > >> - When chaining Layer 4 to Layer 7 service functions together, like > S1- > >> >S2->S3->S4, they are overlaying over the underlay network. > >> > >> - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to > >> dynamically discover topology; forwarding paths; protection paths; > >> restoration paths, etc. Today, all routers are connected together by > >> links. Their topology is more like a meshed graph than chain. So > when > >> you chain Router-1<->Router-2<->Router-3, are you talking about > source > >> routing? Therefore, need a clear definition on what does it really > mean > >> by chaining Layer 2/3 service nodes. > >> > >> Linda > >> > >> > -----Original Message----- > >> > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > >> > Sent: Tuesday, September 03, 2013 5:28 PM > >> > To: Linda Dunbar > >> > Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant > (stbryant); > >> > Thomas Narten; adrian@olddog.co.uk > >> > Subject: Re: [nsc] NSC BoF Outcomes > >> > > >> > > >> > On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar > >> > wrote: > >> > > >> > > Thomas, > >> > > > >> > > Are you saying that the NSC scope includes chaining Layer 2, > Layer > >> 3 > >> > service functions, Layer 4 to Layer 7 service functions, and > various > >> > combination of them? > >> > > >> > I don't define the scope; thats up to the ADs. > >> > > >> > Could you please answer the question below? > >> > > >> > --Tom > >> > > >> > > > >> > > Linda > >> > > > >> > >> -----Original Message----- > >> > >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > >> > >> Sent: Tuesday, September 03, 2013 5:19 PM > >> > >> To: Linda Dunbar > >> > >> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org; > >> > >> Thomas Narten; Stewart Bryant (stbryant) > >> > >> Subject: Re: [nsc] NSC BoF Outcomes > >> > >> > >> > >> > >> > >> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar > >> > >> wrote: > >> > >> > >> > >>> My comments are inserted below marked by [Linda]: > >> > >>> > >> > >>>> -----Original Message----- > >> > >>>> > >> > >>>>> > >> > >>>>> However, it was less clear to me that there is agreement > about > >> > the > >> > >>>> layer > >> > >>>>> in > >> > >>>>> which service chaining has to be solved. I felt that some > >> people > >> > >>>>> were talking about service chaining in the application layer, > >> > some > >> > >>>>> about service chaining based on flows, and some about per- > >> packet > >> > >>>>> services. The solutions are, > >> > >>>> I > >> > >>>>> think, > >> > >>>>> likely to be very different for the different problems, and > it > >> > >> would > >> > >>>> be > >> > >>>>> wrong to > >> > >>>>> try to bunch them all together. > >> > >>>> > >> > >>>> Jim> although there was certainly initial confusion I believe > >> > >>>> Jim> this > >> > >> is > >> > >>>> becoming less and less so as we socialize the basic idea of > >> > service > >> > >>>> chaining; indeed, as we move forward we will reflect a more > >> > >>>> common understanding within the problem statement. > >> > >>> > >> > >>> It is still not clear which layer service functions are > chained > >> > >> together. The draft-quinn-nsc-problem-statement-03 discussed > >> > chaining > >> > >> of service functions that can be a network or application based > >> > >> packet treatment,..., to enable a service offered by a network > >> > operators. > >> > >> > >> > >> Why do you think that matters? > >> > >> > >> > >>> Today, there are many services offered by operators, e.g. > L2VPN, > >> > >>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining > L2/L3 > >> > >> service functions (like proxy forwarding, or fragmentation, > etc.); > >> > >> You can also interpret NSC as chaining L4 (and above) service > >> > >> functions; or chaining of mixed L4-L7 service functions (i.e. > with > >> > >> some service nodes consuming packets and reinitiate new > packets). > >> > >> > >> > >> You can, and people actually do implement this today. > >> > >> > >> > >>> Is NSC including all chaining of all those services? > >> > >>> > >> > >>> Layer 2/3 service function chaining might require different > >> > >>> schemes > >> > >> than Layer 4-7 service chaining. Therefore, it is more > effective > >> to > >> > >> define them separately to make the discussion more focused. > >> > >> > >> > >> I do not think so. I'd prefer to not make this only as > >> > complicated > >> > >> as it needs to be, and no more. There are implementations of > Layer > >> > >> 2 and 3 chaining that are all done with the same > >> encap/provisioning > >> > >> systems. > >> > >> > >> > >> --Tom > >> > >> > >> > >> > >> > >>> > >> > >>> Linda Dunbar > >> > >>> > >> > >>>> > >> > >>>> _______________________________________________ > >> > >>>> nsc mailing list > >> > >>>> nsc@ietf.org > >> > >>>> https://www.ietf.org/mailman/listinfo/nsc > >> > >>> _______________________________________________ > >> > >>> nsc mailing list > >> > >>> nsc@ietf.org > >> > >>> https://www.ietf.org/mailman/listinfo/nsc > >> > >>> > >> > > > >> > > _______________________________________________ > >> > > nsc mailing list > >> > > nsc@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/nsc > >> > > > >> > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ > >nsc mailing list > >nsc@ietf.org > >https://www.ietf.org/mailman/listinfo/nsc > > > > >=20 From melinda.shore@gmail.com Wed Sep 4 11:58: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 A0DAC11E810C for ; Wed, 4 Sep 2013 11:58:42 -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 zQ4VQsRVMfaf for ; Wed, 4 Sep 2013 11:58:42 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 24E4911E810B for ; Wed, 4 Sep 2013 11:58:42 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr4so709406pbb.20 for ; Wed, 04 Sep 2013 11:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YmZnnZnJJXpnxTMFRLDsLz1cH4NFa4YMniMdVKyIjI8=; b=SaKYvhT+LNaxt33VmbK59oASqVoIyGroHdBv8e9x7xZ7+EInwseCd8A87NwOPJdq82 Qz/gYSgTVTcfzwjZUC77+rIeFZQjspZu3hKparncXiIIT3x8ixKdmDlbmPIqg0reCWY7 i4Uosw18zGNdmXk6zMmhenhkzyKwX56AiuSulJPD9lep1Yl2PtHy/vl6nQedaVEx9PR4 ZFR70t16CS7ZPZn+9ND/5SG/zmrmQiEFZ3aYl1um5qHGnij6tqhuI8VIkJ7pDwLZIE8s tIzyCcmFnsVZKxmtwnw4/qKV8cIdT6ztz9vNMrcWeSbhBSMkIn7exO2bJ5fWMk8xzW6R +C9Q== X-Received: by 10.67.5.132 with SMTP id cm4mr3489500pad.186.1378321120866; Wed, 04 Sep 2013 11:58:40 -0700 (PDT) Received: from spandex.local (216-67-47-26-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.47.26]) by mx.google.com with ESMTPSA id nv6sm30423743pbc.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Sep 2013 11:58:40 -0700 (PDT) Message-ID: <522782DE.9080803@gmail.com> Date: Wed, 04 Sep 2013 10:58:38 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: nsc@ietf.org References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> <52277CE1.60805@joelhalpern.com> In-Reply-To: <52277CE1.60805@joelhalpern.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 18:58:42 -0000 On 9/4/13 10:33 AM, Joel M. Halpern wrote: > Separating the problem statement, framework, requirements, and "design > analysis" produces a multiplicity of documents which will divide the WGs > efforts without, as far as I can tell, improving clarity. I agree quite strongly with this. > Similarly, while I find use case drafts useful information for the WG to > consider, I think that arguing about which use cases we should put in an > RFC, would not be a good use of the WGs time and energy. I'm not sure. Noting the feeding frenzy in this space, it may be worthwhile to define a few use cases that must be satisfied as a way to bring order to the chaos. On the other hand, getting the use cases laid out may bring about a slugfest of its own. I'm ambivalent about this but I do think it's worth trying to anticipate process issues and to think about how to avoid this turning into another nvo3. Use cases may or may not be helpful. Melinda From tnadeau@lucidvision.com Wed Sep 4 12:45:16 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 0C76D11E80F1 for ; Wed, 4 Sep 2013 12:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 NnEd3CdlUKnw for ; Wed, 4 Sep 2013 12:45:05 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 50D8611E81E1 for ; Wed, 4 Sep 2013 12:45:05 -0700 (PDT) Received: from [172.28.132.200] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id AE98D255A990; Wed, 4 Sep 2013 15:45:01 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_29307D8A-040C-4328-8BC0-93FEFA43B2F6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: <68B171751455884590F8E38E96416F363F675803@xmb-rcd-x01.cisco.com> Date: Wed, 4 Sep 2013 15:44:59 -0400 Message-Id: <4F77EB66-E974-41D2-9BFE-83A7381B3F42@lucidvision.com> References: <68B171751455884590F8E38E96416F363F675803@xmb-rcd-x01.cisco.com> To: "Jim Guichard (jguichar)" X-Mailer: Apple Mail (2.1508) Cc: "nsc@ietf.org" , "christian.jacquenet@orange.com" , Thomas Narten , Ron Parker , "adrian@olddog.co.uk" , Linda Dunbar , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 19:45:16 -0000 --Apple-Mail=_29307D8A-040C-4328-8BC0-93FEFA43B2F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I like this idea. Its practical and satisfies the desire to have = detailed requirements.=20 On Sep 4, 2013:1:19 PM, at 1:19 PM, "Jim Guichard (jguichar)" = wrote: > Let me suggest that we keep a single requirements document for now and > perhaps split into separate data and control plane documents should = that > become necessary as the single document evolves. >=20 > On 9/4/13 12:18 PM, "Jerome Moisand" wrote: >=20 >> I would tend to agree with Christian, requirements should be about = the >> overall problem to solve. Plus a control plane tends to control... = the >> data plane! So better work on requirements which would be consistent >> enough to acknowledge such relationship. >>=20 >> Now, I also agree with Ron that a control plane may not be required = in >> all cases. This should probably be a requirement, actually, to not >> mandate a control plane in all cases! >>=20 >> -----Original Message----- >> From: christian.jacquenet@orange.com >> [mailto:christian.jacquenet@orange.com] >> Sent: Wednesday, September 04, 2013 12:04 PM >> To: Jim Guichard (jguichar); Ron Parker; Jerome Moisand >> Cc: nsc@ietf.org; Thomas Nadeau; Linda Dunbar; adrian@olddog.co.uk; >> Thomas Narten; Stewart Bryant (stbryant) >> Subject: RE: [nsc] NSC BoF Outcomes >>=20 >> Hi*, >>=20 >> I support the publication of a single requirements document (for the = sake >> of consistency), and which would include both control and data plane >> considerations among other topics. >>=20 >> Cheers, >>=20 >> Christian. >>=20 >> -----Message d'origine----- >> De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de = Jim >> Guichard (jguichar) Envoy=E9 : mercredi 4 septembre 2013 17:57 =C0 : = Ron >> Parker; Jerome Moisand Cc : nsc@ietf.org; Thomas Nadeau; Linda = Dunbar; >> adrian@olddog.co.uk; Thomas Narten; Stewart Bryant (stbryant) Objet : = Re: >> [nsc] NSC BoF Outcomes >>=20 >> Is the suggestion therefore that separate data and control plane >> requirements I-D's should be created rather than an overall = requirements >> document covering both? >>=20 >> On 9/4/13 11:39 AM, "Ron Parker" = wrote: >>=20 >>> Jim, >>>=20 >>> I agree that the charter should not be too specific on the design of >>> the control plane, but rather to recognize that one could be >>> advantageous (although not necessarily required) for the overall = service >>> chaining >>> solution. A control plane requirements and/or use cases document >>> should precede any control plane protocol design or selection. >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, September 04, 2013 10:17 AM >>> To: Jerome Moisand; Ron Parker >>> Cc: nsc@ietf.org; Thomas Nadeau; Thomas Narten; adrian@olddog.co.uk; >>> Linda Dunbar; Stewart Bryant (stbryant) >>> Subject: Re: [nsc] NSC BoF Outcomes >>>=20 >>> Hi Jerome, >>>=20 >>> My bad .. Responding to your PS ;) =8A Right now the charter = suggests >>> that the WG be responsible for defining the requirements of the = control >>> plane with respect to service chaining. The problem here is of = course >>> that there are multiple control planes. In my mind it makes little >>> sense to try and tackle them all but rather define what is necessary >>> for a control plane to implement to successfully enable service = chains >>> and then liaise with other WG's on the details. >>>=20 >>> Some further comments inline. >>>=20 >>> On 9/4/13 9:55 AM, "Jerome Moisand" wrote: >>>=20 >>>> It seems to me that the entire point of service chaining is indeed = to >>>> chain together heterogeneous service-enabling elements, and make = the >>>> best out of such combo. >>>=20 >>> Jim> exactly. The point being separate service functions into a >>> Jim> resource >>> pool that can be utilized and not constrained based on topology. >>>=20 >>>>=20 >>>>=20 >>>> Service Edge routers (including Biz-PEs, BNGs and Mobile GWs) = enable >>>> L3 services, on a per subscriber basis. Firewalls can act either at >>>> L3/L4 or >>>> L4/L7 (e.g. adding some Intrusion Detection to the mix). DPI or = HTTP >>>> Proxies/Filters engines act at L7. Session Border Controllers act = at >>>> L7, although they do some L3/L4 processing too (NAT). All those >>>> various elements have their own strengths in terms of traffic >>>> classification and in terms of policy enforcement. Which can = combined >>>> in smart ways (e.g. >>>> use DPI to identify/classify an application flow, use an edge = router >>>> to perform fancy queuing based on such DPI classification among = other >>>> traffic flows). >>>=20 >>> Jim> yep.=20 >>>=20 >>>>=20 >>>>=20 >>>> The beauty of service chaining is to combine all those elements to >>>> make something truly useful (e.g. provide a more complex Service = -with >>>> a capital 'S'- to service provider users or enterprise users). All = the >>>> use cases I've heard so far from various parties do mix edge = routers, >>>> security and application-oriented elements. >>>>=20 >>>> So... I would not be supportive to trying to separate a form of = L2/L3 >>>> chaining from a form of L4/L7 chaining. On the contrary! ;-) >>>>=20 >>>> I would actually go as far as suggesting that we should make = clearer >>>> in the proposed charter that this is a strong goal, to deal with = such >>>> heterogeneous combos. >>>=20 >>> Jim> any text and suggestion of where to insert into the charter? >>>=20 >>>>=20 >>>> Just my 2 cents, >>>> Jerome >>>>=20 >>>> =3D=3D=3D=3D >>>> Totally unrelated PS for Jim: you didn't answer my question about = the >>>> control plane aspects, this may have slipped through the cracks! = ;-) >>>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, September 04, 2013 6:51 AM >>>> To: Ron Parker >>>> Cc: nsc@ietf.org; Thomas Nadeau; Thomas Narten; = adrian@olddog.co.uk; >>>> Linda Dunbar; Stewart Bryant (stbryant) >>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>=20 >>>> The same argument could be applied for firewalls as without them >>>> packets would get routed instead of perhaps dropped. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Sep 3, 2013, at 8:45 PM, "Ron Parker" >>>> wrote: >>>>=20 >>>>> Hi, Linda. >>>>>=20 >>>>> With respect to: >>>>>=20 >>>>> - Layer 4 to Layer 7 service functions (or service nodes) are to >>>>> apply actions to data packets traversing through. They don't = impact >>>>> overall network topologies/routes/restorations. >>>>>=20 >>>>> Layer 4-7 services can, indeed, impact routing decisions. For >>>>> example, if the service is DPI analysis, then a detected protocol = may >>>>> cause the subsequent packets to be policy routed on a path = different >>>>> than the SPF path. >>>>>=20 >>>>> Ron >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>>> Of Linda Dunbar >>>>> Sent: Tuesday, September 03, 2013 6:48 PM >>>>> To: Thomas Nadeau >>>>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; >>>>> adrian@olddog.co.uk; Stewart Bryant (stbryant) >>>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>>=20 >>>>> Here are some of the reasons that chaining of Layer 2 and 3 = service >>>>> functions are different from chaining of Layer 4 to 7 service >>>>> functions (I will add more later): >>>>>=20 >>>>>=20 >>>>> - Layer 4 to Layer 7 service functions (or service nodes) are to >>>>> apply actions to data packets traversing through. They don't = impact >>>>> overall network topologies/routes/restorations. >>>>>=20 >>>>> - Layer 4-7 service functions drop, pass, consume, re-initiate >>>>> packets, etc. They don't change network topologies, and they don't >>>>> impact network restoration scheme (e.g. fast re-route). When you >>>>> move a Layer 4 service module from Location A to B, the Layer 2/3 >>>>> topology is not changed, routes/restoration are not changed. >>>>>=20 >>>>> - When chaining Layer 4 to Layer 7 service functions together, = like >>>>> S1->S2->S3->S4, they are overlaying over the underlay network. >>>>>=20 >>>>> - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to >>>>> dynamically discover topology; forwarding paths; protection paths; >>>>> restoration paths, etc. Today, all routers are connected together = by >>>>> links. Their topology is more like a meshed graph than chain. So = when >>>>> you chain Router-1<->Router-2<->Router-3, are you talking about >>>>> source routing? Therefore, need a clear definition on what does it >>>>> really mean by chaining Layer 2/3 service nodes. >>>>>=20 >>>>> Linda >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>>> Sent: Tuesday, September 03, 2013 5:28 PM >>>>>> To: Linda Dunbar >>>>>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant >>>>>> (stbryant); Thomas Narten; adrian@olddog.co.uk >>>>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>>>=20 >>>>>>=20 >>>>>> On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar >>>>>> wrote: >>>>>>=20 >>>>>>> Thomas, >>>>>>>=20 >>>>>>> Are you saying that the NSC scope includes chaining Layer 2, = Layer >>>>>>> 3 >>>>>> service functions, Layer 4 to Layer 7 service functions, and >>>>>> various combination of them? >>>>>>=20 >>>>>> I don't define the scope; thats up to the ADs. >>>>>>=20 >>>>>> Could you please answer the question below? >>>>>>=20 >>>>>> --Tom >>>>>>=20 >>>>>>>=20 >>>>>>> Linda >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>>>>> Sent: Tuesday, September 03, 2013 5:19 PM >>>>>>>> To: Linda Dunbar >>>>>>>> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org; >>>>>>>> Thomas Narten; Stewart Bryant (stbryant) >>>>>>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> My comments are inserted below marked by [Linda]: >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> However, it was less clear to me that there is agreement = about >>>>>> the >>>>>>>>>> layer >>>>>>>>>>> in >>>>>>>>>>> which service chaining has to be solved. I felt that some >>>>>>>>>>> people were talking about service chaining in the = application >>>>>>>>>>> layer, >>>>>> some >>>>>>>>>>> about service chaining based on flows, and some about >>>>>>>>>>> per-packet services. The solutions are, >>>>>>>>>> I >>>>>>>>>>> think, >>>>>>>>>>> likely to be very different for the different problems, and = it >>>>>>>> would >>>>>>>>>> be >>>>>>>>>>> wrong to >>>>>>>>>>> try to bunch them all together. >>>>>>>>>>=20 >>>>>>>>>> Jim> although there was certainly initial confusion I believe >>>>>>>>>> Jim> this >>>>>>>> is >>>>>>>>>> becoming less and less so as we socialize the basic idea of >>>>>> service >>>>>>>>>> chaining; indeed, as we move forward we will reflect a more >>>>>>>>>> common understanding within the problem statement. >>>>>>>>>=20 >>>>>>>>> It is still not clear which layer service functions are = chained >>>>>>>> together. The draft-quinn-nsc-problem-statement-03 discussed >>>>>> chaining >>>>>>>> of service functions that can be a network or application based >>>>>>>> packet treatment,..., to enable a service offered by a network >>>>>> operators. >>>>>>>>=20 >>>>>>>> Why do you think that matters? >>>>>>>>=20 >>>>>>>>> Today, there are many services offered by operators, e.g. = L2VPN, >>>>>>>>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining >>>>>>>>> L2/L3 >>>>>>>> service functions (like proxy forwarding, or fragmentation, >>>>>>>> etc.); You can also interpret NSC as chaining L4 (and above) >>>>>>>> service functions; or chaining of mixed L4-L7 service functions >>>>>>>> (i.e. with some service nodes consuming packets and reinitiate = new >>>>>>>> packets). >>>>>>>>=20 >>>>>>>> You can, and people actually do implement this today. >>>>>>>>=20 >>>>>>>>> Is NSC including all chaining of all those services? >>>>>>>>>=20 >>>>>>>>> Layer 2/3 service function chaining might require different >>>>>>>>> schemes >>>>>>>> than Layer 4-7 service chaining. Therefore, it is more = effective >>>>>>>> to define them separately to make the discussion more focused. >>>>>>>>=20 >>>>>>>> I do not think so. I'd prefer to not make this only as >>>>>> complicated >>>>>>>> as it needs to be, and no more. There are implementations of >>>>>>>> Layer >>>>>>>> 2 and 3 chaining that are all done with the same >>>>>>>> encap/provisioning systems. >>>>>>>>=20 >>>>>>>> --Tom >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Linda Dunbar >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> nsc mailing list >>>>>>>>>> nsc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>> _______________________________________________ >>>>>>>>> nsc mailing list >>>>>>>>> nsc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>=20 >>>>> _______________________________________________ >>>>> 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 >> = __________________________________________________________________________= >> _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message = par >> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les >> pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged >> information that may be protected by law; they should not be = distributed, >> used or copied without authorisation. >> If you have received this email in error, please notify the sender = and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >>=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc --Apple-Mail=_29307D8A-040C-4328-8BC0-93FEFA43B2F6 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 iQIcBAEBCgAGBQJSJ427AAoJEPcO+I7eiUJZYCQP/2qV3e9Q5bAyKM0SJqkOKxXn +2YE8wK5F69bupqH2ia28YLsOiBckfbnIBypONmSGniU/RrR8081vJCcWmxFOjJk yVJYcgPCWefGvOsRuRCuvCzKK9nt/B1BEop/CYhNBW49qNrxWuOGoDFf/Sdx3Yr8 z6aXr38RtGtVTek3OYB0ULvO74hFSpt1Ol+tdlecl0iFOf+WRGyJLliYXx6jpAYO VkePQyXxjVxhGIOCWZaDOtau0ULN99ymx9HGCu6hWFyh4ziRfL2AiHjGTtdaLSpb WiudFDu5xu5IKZMrmPTnVwlFFYh3gpVaO4GPOuQEvZc74Ubvh8z4JoNclS0Ir7eD j8urNPxxcHoqi5qRSjDxm2hzJIeLGK/9rhiLefNFEfywZOSZddxMDgOe5c5sy1N8 b2IwVDGkMtoyeCTOXWgnfYHqv308zDRGHZE7kK5vucD9JDIraQs332Ps8M4gCB+J 57ojXQuhPCnHAE1nNZV9lSAjiDcXMun9ex6sCLJytO+Xl2IjPThGEX2MP2yck+Uz P/NOQ8dRkZ5PynFXSy9JbXkpjxHzLM+yYI17VmXw3Mn7MeIh04kxtjr9WVGdhXw1 j/HbnNEJLKpWv8eFrT/0hpHkZmCA813TOTJRTwcU0rEo3DFCWK4L3bfKN6TX5bT5 SGOoDvUVhP/xSAg+cPMG =siIA -----END PGP SIGNATURE----- --Apple-Mail=_29307D8A-040C-4328-8BC0-93FEFA43B2F6-- From tnadeau@lucidvision.com Wed Sep 4 12:53: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 A331A21F9E02 for ; Wed, 4 Sep 2013 12:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 ST2SJCvZJ5ve for ; Wed, 4 Sep 2013 12:53:40 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1C62921F9D46 for ; Wed, 4 Sep 2013 12:53:37 -0700 (PDT) Received: from [172.28.132.200] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 0E674255A9E2; Wed, 4 Sep 2013 15:53:35 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2B0362C0-B268-4FD2-BA65-2012C9611603"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9D390@dfweml509-mbx.china.huawei.com> Date: Wed, 4 Sep 2013 15:53:33 -0400 Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F645B9D19E@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645B9D390@dfweml509-mbx.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1508) Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Thomas Narten , Ken Gray , Ron Parker , "adrian@olddog.co.uk" , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 19:53:44 -0000 --Apple-Mail=_2B0362C0-B268-4FD2-BA65-2012C9611603 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I2RS is not chartered to do service-chaining explicitly, = especially any data plane changes that might be needed; its chartered to = do fast programmability and topology. --Tom > Ken,=20 >=20 > You brought up a very good point, about I2RS.=20 >=20 > I see I2RS as a mechanism to chain L3 service modules. If NSC also = covers the L3 service function chaining, are the use cases similar to = I2RS' use cases? Or different?=20 >=20 > Linda >=20 >=20 >=20 >> -----Original Message----- >> From: Ken Gray [mailto:kgray@juniper.net] >> Sent: Wednesday, September 04, 2013 1:04 PM >> To: Linda Dunbar; Ron Parker; Thomas Nadeau >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant (stbryant); >> adrian@olddog.co.uk; Thomas Narten >> Subject: Re: [nsc] NSC BoF Outcomes >>=20 >> In line ... >>=20 >> On 9/4/13 12:17 PM, "Linda Dunbar" wrote: >>=20 >>> Ron, >>>=20 >>> My comments are inserted below: >>>> -----Original Message----- >>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>> Sent: Tuesday, September 03, 2013 7:46 PM >>>> To: Linda Dunbar; Thomas Nadeau >>>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; >>>> adrian@olddog.co.uk; Stewart Bryant (stbryant) >>>> Subject: RE: [nsc] NSC BoF Outcomes >>>>=20 >>>> Hi, Linda. >>>>=20 >>>> With respect to: >>>>=20 >>>> - Layer 4 to Layer 7 service functions (or service nodes) are to >>>> apply actions to data packets traversing through. They don't impact >>>> overall network topologies/routes/restorations. >>>>=20 >>>> Layer 4-7 services can, indeed, impact routing decisions. For >> example, >>>> if the service is DPI analysis, then a detected protocol may cause >> the >>>> subsequent packets to be policy routed on a path different than the >> SPF >>>> path. >>>=20 >>> [Linda] Do you call this "DPI" function that re-direct data frames = to >> a >>> different target (that is not the Destination of the data frame) >> "Layer >>> 3" service? >>> When those "DPI" functions re-direct traffic, do they add another >>> Destination address to the data frames (i.e. create a tunnel)? Or do >> they >>> not touch the destination addresses in the existing data frames and >>> expect all the nodes along the way to know how to forward the data >> frames? >>=20 >> I fail to see the point of the question. >>=20 >>>=20 >>>=20 >>>=20 >>> Bottom line, those services need to be distinguished from = traditional >>> Layer 3 services, and be distinguished from routers/switches that >>> dynamically establish topology, establish routes, and restoration >> paths. >>=20 >> Disagree. Bump-in-the-wire - to me, that's what this ALL >> is ...you >> are making a distinction that is very temporary and (IMO) = unnecessary. >> What you describe as something "dynamically establish topology" is >> morphing (heck, with the help of I2RS - sooner rather than later) to >> some >> different definition of dynamic than we have today. Bump-in-wire. >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Linda >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >>>> Linda Dunbar >>>> Sent: Tuesday, September 03, 2013 6:48 PM >>>> To: Thomas Nadeau >>>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; >>>> adrian@olddog.co.uk; Stewart Bryant (stbryant) >>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>=20 >>>> Here are some of the reasons that chaining of Layer 2 and 3 service >>>> functions are different from chaining of Layer 4 to 7 service >> functions >>>> (I will add more later): >>>>=20 >>>>=20 >>>> - Layer 4 to Layer 7 service functions (or service nodes) are to >> apply >>>> actions to data packets traversing through. They don't impact >> overall >>>> network topologies/routes/restorations. >>>>=20 >>>> - Layer 4-7 service functions drop, pass, consume, re-initiate >> packets, >>>> etc. They don't change network topologies, and they don't impact >>>> network restoration scheme (e.g. fast re-route). When you move a >> Layer >>>> 4 service module from Location A to B, the Layer 2/3 topology is = not >>>> changed, routes/restoration are not changed. >>>>=20 >>>> - When chaining Layer 4 to Layer 7 service functions together, like >> S1- >>>>> S2->S3->S4, they are overlaying over the underlay network. >>>>=20 >>>> - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to >>>> dynamically discover topology; forwarding paths; protection paths; >>>> restoration paths, etc. Today, all routers are connected together = by >>>> links. Their topology is more like a meshed graph than chain. So >> when >>>> you chain Router-1<->Router-2<->Router-3, are you talking about >> source >>>> routing? Therefore, need a clear definition on what does it really >> mean >>>> by chaining Layer 2/3 service nodes. >>>>=20 >>>> Linda >>>>=20 >>>>> -----Original Message----- >>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>> Sent: Tuesday, September 03, 2013 5:28 PM >>>>> To: Linda Dunbar >>>>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant >> (stbryant); >>>>> Thomas Narten; adrian@olddog.co.uk >>>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>>=20 >>>>>=20 >>>>> On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar >>>>> wrote: >>>>>=20 >>>>>> Thomas, >>>>>>=20 >>>>>> Are you saying that the NSC scope includes chaining Layer 2, >> Layer >>>> 3 >>>>> service functions, Layer 4 to Layer 7 service functions, and >> various >>>>> combination of them? >>>>>=20 >>>>> I don't define the scope; thats up to the ADs. >>>>>=20 >>>>> Could you please answer the question below? >>>>>=20 >>>>> --Tom >>>>>=20 >>>>>>=20 >>>>>> Linda >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>>>> Sent: Tuesday, September 03, 2013 5:19 PM >>>>>>> To: Linda Dunbar >>>>>>> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org; >>>>>>> Thomas Narten; Stewart Bryant (stbryant) >>>>>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar >>>>>>> wrote: >>>>>>>=20 >>>>>>>> My comments are inserted below marked by [Linda]: >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> However, it was less clear to me that there is agreement >> about >>>>> the >>>>>>>>> layer >>>>>>>>>> in >>>>>>>>>> which service chaining has to be solved. I felt that some >>>> people >>>>>>>>>> were talking about service chaining in the application layer, >>>>> some >>>>>>>>>> about service chaining based on flows, and some about per- >>>> packet >>>>>>>>>> services. The solutions are, >>>>>>>>> I >>>>>>>>>> think, >>>>>>>>>> likely to be very different for the different problems, and >> it >>>>>>> would >>>>>>>>> be >>>>>>>>>> wrong to >>>>>>>>>> try to bunch them all together. >>>>>>>>>=20 >>>>>>>>> Jim> although there was certainly initial confusion I believe >>>>>>>>> Jim> this >>>>>>> is >>>>>>>>> becoming less and less so as we socialize the basic idea of >>>>> service >>>>>>>>> chaining; indeed, as we move forward we will reflect a more >>>>>>>>> common understanding within the problem statement. >>>>>>>>=20 >>>>>>>> It is still not clear which layer service functions are >> chained >>>>>>> together. The draft-quinn-nsc-problem-statement-03 discussed >>>>> chaining >>>>>>> of service functions that can be a network or application based >>>>>>> packet treatment,..., to enable a service offered by a network >>>>> operators. >>>>>>>=20 >>>>>>> Why do you think that matters? >>>>>>>=20 >>>>>>>> Today, there are many services offered by operators, e.g. >> L2VPN, >>>>>>>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining >> L2/L3 >>>>>>> service functions (like proxy forwarding, or fragmentation, >> etc.); >>>>>>> You can also interpret NSC as chaining L4 (and above) service >>>>>>> functions; or chaining of mixed L4-L7 service functions (i.e. >> with >>>>>>> some service nodes consuming packets and reinitiate new >> packets). >>>>>>>=20 >>>>>>> You can, and people actually do implement this today. >>>>>>>=20 >>>>>>>> Is NSC including all chaining of all those services? >>>>>>>>=20 >>>>>>>> Layer 2/3 service function chaining might require different >>>>>>>> schemes >>>>>>> than Layer 4-7 service chaining. Therefore, it is more >> effective >>>> to >>>>>>> define them separately to make the discussion more focused. >>>>>>>=20 >>>>>>> I do not think so. I'd prefer to not make this only as >>>>> complicated >>>>>>> as it needs to be, and no more. There are implementations of >> Layer >>>>>>> 2 and 3 chaining that are all done with the same >>>> encap/provisioning >>>>>>> systems. >>>>>>>=20 >>>>>>> --Tom >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Linda Dunbar >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> nsc mailing list >>>>>>>>> nsc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>>=20 >>=20 >=20 >=20 --Apple-Mail=_2B0362C0-B268-4FD2-BA65-2012C9611603 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 iQIbBAEBCgAGBQJSJ4++AAoJEPcO+I7eiUJZHLIP90LfLb6JRNsXXeXNOYbkqeai DSPeoFcMPhq5I59oLkfAOhqgi4X0LHCaIR2kmTmxuVFqJYYeTALdJFw9LpSY/VxD 06T3xNaBuosJzvCtjU72YSh7YYXJNHlnS4Ztdqv8ImrW/p8TqzIMWXxA+BEDEKqN 5Xx9j+WlP11ELzhY1Vp2zvw5e+WUEL2RXS6BDzAkA0ghwt3Vpi3wq99O9xyGcDro Sn3qxATrNydNKn+q7kNUN/8QR2mgf9+6KhaaJ2CwKmRetMxq+UlsIx6D9bkjEgB5 aIqGMTwZK/4F+5xLLzy6xFM6tSSTHqxWse2pisaDOlnylVCHEl0npovXJBI0ybon Xu6Bs3ph+RFNAADCWoi8N+Hldtk4D00UWK231NIWcSugrheYcOchMhlx5MRLXqTZ j31VzX2fUXn/aVFqRWP++376nyDxi81F1L+7qhjzrX1niofUk4TkQjRVRU9ocHMe ahrWIzUkFXpAPmRKgPZrflXvXudgfRT0FssZ0UNDzx3xk8XqUDfp4qVNcHzfIHlr VLUtSMc6hLJZ1Nlp7KeKJP0B8Ri1AjB1lLcmZ5G7tiiJJQRZzYjD33g851cwIjkv 2E5HnFgKciJWA4QB2dGMWEfGn5Kz7ByGYWgFWdr9ZPhcy4MbAoSHF6QqeVVShrUr aNm4D7gfj08lqqA82/0= =jQlh -----END PGP SIGNATURE----- --Apple-Mail=_2B0362C0-B268-4FD2-BA65-2012C9611603-- From kgray@juniper.net Wed Sep 4 12:57: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 4FCCD21E809D for ; Wed, 4 Sep 2013 12:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=-0.880, 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 5mVVljtOgPY5 for ; Wed, 4 Sep 2013 12:57:21 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 9A22121F8B07 for ; Wed, 4 Sep 2013 12:57:11 -0700 (PDT) Received: from mail201-db8-R.bigfish.com (10.174.8.248) by DB8EHSOBE027.bigfish.com (10.174.4.90) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 19:57:02 +0000 Received: from mail201-db8 (localhost [127.0.0.1]) by mail201-db8-R.bigfish.com (Postfix) with ESMTP id 18A0EBA012E; Wed, 4 Sep 2013 19:57:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432I1418Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail201-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(479174003)(51444003)(24454002)(199002)(189002)(51704005)(19580405001)(83322001)(83506001)(19580395003)(81686001)(80022001)(65816001)(59766001)(69226001)(81816001)(77982001)(4396001)(46102001)(63696002)(49866001)(50986001)(47976001)(81542001)(36756003)(76176001)(76786001)(76796001)(51856001)(74366001)(79102001)(81342001)(47736001)(56816003)(77096001)(53806001)(54356001)(80976001)(47446002)(31966008)(74502001)(74662001)(74876001)(56776001)(54316002)(83072001)(74706001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB081; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail201-db8 (localhost.localdomain [127.0.0.1]) by mail201-db8 (MessageSwitch) id 137832456530410_15421; Wed, 4 Sep 2013 19:56:05 +0000 (UTC) Received: from DB8EHSMHS001.bigfish.com (unknown [10.174.8.227]) by mail201-db8.bigfish.com (Postfix) with ESMTP id C9DAF980127; Wed, 4 Sep 2013 19:55:52 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS001.bigfish.com (10.174.4.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 19:55:50 +0000 Received: from BL2PR05MB081.namprd05.prod.outlook.com (10.255.232.14) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 4 Sep 2013 19:55:48 +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.745.25; Wed, 4 Sep 2013 19:55:47 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 19:55:47 +0000 From: Ken Gray To: Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1Ee0QgADW+YCAAAcjAP//zOKA Date: Wed, 4 Sep 2013 19:55:47 +0000 Message-ID: In-Reply-To: <522782DE.9080803@gmail.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: 095972DF2F Content-Type: text/plain; charset="us-ascii" Content-ID: <4AE00BDB6715274D8E96681F4D596CA8@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% Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 19:57:30 -0000 "Feeding frenzy" is apt. I'm personally hoping we can constrain the use-case love-fest within it's own document or any document in the WG to those that illustrate/support specific requirements relevant to the general specifications of the WG - that is, those that make the case for specific metadata needs, site relevance to the header discussion, etc ... I expect these could be paragraph-to-page length summaries with pointers to relevant architectures, drawings, related work (if they are included in a document at all) - versus sweeping architectural disgorgement wherein one or two points are actually salient/pertinent to the overall discussion at hand. Having READ the various/numerous/copious use-case whitepapers in other SDOs/quasi-SDOs/study_groups, I personally think anything longer goes in the round, can-shaped object on my desktop. On 9/4/13 2:58 PM, "Melinda Shore" wrote: >On 9/4/13 10:33 AM, Joel M. Halpern wrote: >> Separating the problem statement, framework, requirements, and "design >> analysis" produces a multiplicity of documents which will divide the WGs >> efforts without, as far as I can tell, improving clarity. > >I agree quite strongly with this. > >> Similarly, while I find use case drafts useful information for the WG to >> consider, I think that arguing about which use cases we should put in an >> RFC, would not be a good use of the WGs time and energy. > >I'm not sure. Noting the feeding frenzy in this space, it may >be worthwhile to define a few use cases that must be satisfied >as a way to bring order to the chaos. On the other hand, getting >the use cases laid out may bring about a slugfest of its own. >I'm ambivalent about this but I do think it's worth trying to >anticipate process issues and to think about how to avoid this >turning into another nvo3. Use cases may or may not be helpful. > >Melinda > > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > From linda.dunbar@huawei.com Wed Sep 4 13:45:43 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055C311E813B for ; Wed, 4 Sep 2013 13:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.476, 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 9mncRUSIW6k8 for ; Wed, 4 Sep 2013 13:45:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B99321E809D for ; Wed, 4 Sep 2013 13:45:35 -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.5-GA FastPath queued) with ESMTP id AVB17421; Wed, 04 Sep 2013 20:45:34 +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; Wed, 4 Sep 2013 21:45:10 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 21:45:27 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 13:45:22 -0700 From: Linda Dunbar To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtg Date: Wed, 4 Sep 2013 20:45:21 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9D4FB@dfweml509-mbx.china.huawei.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F672511@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.192.11.59] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B9D4FBdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 20:45:43 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645B9D4FBdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One clarification on Work Item #3: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. Is it really "A single encapsulation"? The encapsulation should depend on the underlay networks. Underlay network = could be IP based, MPLS based, or Ethernet based. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Tuesday, September 03, 2013 11:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_4A95BA014132FF49AE685FAB4B9F17F645B9D4FBdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One clarification on Work= Item #3:

3) Service= Chaining Data Plane: this document will describe on the wire data plane en= capsulation in support of (2). A single encapsulation will be selected in order to enable interoperability of data plane components.<= o:p>

 <= /p>

Is it really “A sin= gle encapsulation”?

The encapsulation should = depend on the underlay networks. Underlay network could be IP based, MPLS b= ased, or Ethernet based.  

 <= /p>

Linda

 <= /p>

From: nsc-boun= ces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, September 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal<= /p>

 

Greetings,=

 

As we look forward to the fo= rmation of a working group that will focus on network service chaining, I w= ould like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area AD'= s. The following is a first draft of the charter and I invite you to active= ly participate and provide inputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion a= nd deployment techniques have not evolved to meet modern network architectu= res and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, st= orage, and applications, have all undergone significant change in recent ye= ars: virtualization, network overlays, and orchestration are increasingly t= he norm. All of these have profound effects on network and services design.

 

Today, deploying new service= s, or making changes to existing services, often requires network topology = changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o mostly-static service definitions. New service insertion and deployment t= echniques must enable the concept of service functions as shared resources,= and enable the linkage of these resources using service chains that represent the abstracted view of the r= equired service functions, and define the order in which they should be app= lied. When a service chain is instantiated in a network, specific instances= of service functions are selected, and a service topology is created and used for forwarding packets through = the service chain.

 

A basic service chain might = simply utilize an existing overlay technology to force traffic through the = necessary service functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chaining= (NSC) working group focuses on new approaches to service insertion and dep= loyment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary protocols for = the creation of service chains, and the passing of metadata from the networ= k to service functions, and between service functions. When possible, the W= G will extend existing protocols to provide service chaining functionality, and any protocol extensions wil= l be reviewed by both the Network Service Chaining WG and by the WG respons= ible for the protocol being extended.  

 

Specifically, the Network Se= rvice Chaining WG is chartered to deliver the following work items: 

 

1) Problem Statement: this d= ocument will provide a summary of the problem space to be addressed by the = Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.

 

2) System Architecture: this= set of documents will provide a description of the architecture building b= locks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pla= ne: this document will describe on the wire data plane encapsulation in sup= port of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docum= ent will address service chaining operation, monitoring and troubleshooting= including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are rea= lized.

 

Proposed Milestones:

 

Dec 2013 Request publication= of an Informational document defining the Network Service Chaining problem= statement to the IESG

 

Mar 2014 Request publication= of informational documents defining the system architecture including prot= ocol requirements and framework to the IESG

 

May 2014 Request publication= of a Standards Track document specifying the data-plane (including metadat= a) for Service Chaining to IESG

 

May 2014 Request publication= of an informational document specifying Service Chaining Control Plane req= uirements to IESG

 

Dec 2014 Request publication= of informational documents defining Service Chaining manageability require= ments including MIBs, OAM, and information models to IESG <= /span>

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645B9D4FBdfweml509mbxchi_-- From Ron_Parker@affirmednetworks.com Wed Sep 4 14:27: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 C56B811E81F9 for ; Wed, 4 Sep 2013 14:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.128, 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 cS463YeqBT76 for ; Wed, 4 Sep 2013 14:27: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 74BFC11E8139 for ; Wed, 4 Sep 2013 14:27:10 -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; Wed, 4 Sep 2013 14:27:09 -0700 From: Ron Parker To: Linda Dunbar , "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtggAALk6A= Date: Wed, 4 Sep 2013 21:27:08 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9D4FB@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9D4FB@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: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6D0D6BMBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 21:27:21 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6D0D6BMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, I think that is a fundamental issue for the group to decide. If the goal = is a single encapsulation, then IMO it would have to be IP-based, since tha= t is the most common denominator. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda= Dunbar Sent: Wednesday, September 04, 2013 4:45 PM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal One clarification on Work Item #3: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. Is it really "A single encapsulation"? The encapsulation should depend on the underlay networks. Underlay network = could be IP based, MPLS based, or Ethernet based. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, September 03, 2013 11:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6D0D6BMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda,<= /p>

 <= /p>

I think that is a fundame= ntal issue for the group to decide.   If the goal is a single enc= apsulation, then IMO it would have to be IP-based, since that is the most common denominator.   

 <= /p>

   Ron

 <= /p>

From: nsc-bo= unces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 4:45 PM
To: Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

One clarification on Work= Item #3:

3) Service= Chaining Data Plane: this document will describe on the wire data plane en= capsulation in support of (2). A single encapsulation will be selected in order to enable interoperability of data plane components.<= o:p>

 <= /p>

Is it really “A sin= gle encapsulation”?

The encapsulation should = depend on the underlay networks. Underlay network could be IP based, MPLS b= ased, or Ethernet based.  

 <= /p>

Linda

 <= /p>

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, September 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal<= /p>

 

Greetings,=

 

As we look forward to the fo= rmation of a working group that will focus on network service chaining, I w= ould like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area AD'= s. The following is a first draft of the charter and I invite you to active= ly participate and provide inputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion a= nd deployment techniques have not evolved to meet modern network architectu= res and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, st= orage, and applications, have all undergone significant change in recent ye= ars: virtualization, network overlays, and orchestration are increasingly t= he norm. All of these have profound effects on network and services design.

 

Today, deploying new service= s, or making changes to existing services, often requires network topology = changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o mostly-static service definitions. New service insertion and deployment t= echniques must enable the concept of service functions as shared resources,= and enable the linkage of these resources using service chains that represent the abstracted view of the r= equired service functions, and define the order in which they should be app= lied. When a service chain is instantiated in a network, specific instances= of service functions are selected, and a service topology is created and used for forwarding packets through = the service chain.

 

A basic service chain might = simply utilize an existing overlay technology to force traffic through the = necessary service functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chaining= (NSC) working group focuses on new approaches to service insertion and dep= loyment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary protocols for = the creation of service chains, and the passing of metadata from the networ= k to service functions, and between service functions. When possible, the W= G will extend existing protocols to provide service chaining functionality, and any protocol extensions wil= l be reviewed by both the Network Service Chaining WG and by the WG respons= ible for the protocol being extended.  

 

Specifically, the Network Se= rvice Chaining WG is chartered to deliver the following work items: 

 

1) Problem Statement: this d= ocument will provide a summary of the problem space to be addressed by the = Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.

 

2) System Architecture: this= set of documents will provide a description of the architecture building b= locks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pla= ne: this document will describe on the wire data plane encapsulation in sup= port of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docum= ent will address service chaining operation, monitoring and troubleshooting= including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are rea= lized.

 

Proposed Milestones:

 

Dec 2013 Request publication= of an Informational document defining the Network Service Chaining problem= statement to the IESG

 

Mar 2014 Request publication= of informational documents defining the system architecture including prot= ocol requirements and framework to the IESG

 

May 2014 Request publication= of a Standards Track document specifying the data-plane (including metadat= a) for Service Chaining to IESG

 

May 2014 Request publication= of an informational document specifying Service Chaining Control Plane req= uirements to IESG

 

Dec 2014 Request publication= of informational documents defining Service Chaining manageability require= ments including MIBs, OAM, and information models to IESG <= /span>

 

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6D0D6BMBX021W3CA2exch_-- From jguichar@cisco.com Wed Sep 4 14:30: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 689A811E81F9 for ; Wed, 4 Sep 2013 14:30:09 -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 ZYXKOlCl3Jv4 for ; Wed, 4 Sep 2013 14:30:04 -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 46CDD11E8139 for ; Wed, 4 Sep 2013 14:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2817; q=dns/txt; s=iport; t=1378330204; x=1379539804; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=xzY02KxjTmEyVXc/fRk+NBaT9RrhMaf/8UZSaE0+9U4=; b=dmJk5FfMKhRAEX8YUg6TG9hyKA5tU8JX62CfBjlTs79Jx1A8O5kifHxm olWF1dxs+8Hla8QoCVV5uHEWZiStxB9vwa6j2mPCQW0eWjEMWf7Wj4AUL ZXcwXgJf0EzCG8way972ue8aSr7bczyWg36Ei1ls4J9JCfPAwEbvJ6dWR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFADqlJ1KtJXG8/2dsb2JhbABagwc1UcFEgSgWdIIkAQEBBAEBATc0HQEIDgoKFDEGCyUCBAESCIdoAw8MsQMNiSEEjHSBIoEZOIMdgQADlBuBcY4ghS+DIIIq X-IronPort-AV: E=Sophos;i="4.90,1023,1371081600"; d="scan'208";a="255480082" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 04 Sep 2013 21:30:02 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r84LU23k025232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 21:30:02 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 16:30:02 -0500 From: "Jim Guichard (jguichar)" To: Ken Gray , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1Ee0QgAEqyoCAAAckAIAAD/eA///XRIA= Date: Wed, 4 Sep 2013 21:30:01 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6761C4@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.82.254.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <5C6D249219CB5D4A82DA39F7A4ECE4EF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 21:30:09 -0000 Our approach with the charter has been to document a couple of high-level use cases within the problem statement if only to educate folks on what the heck we are talking about. Outside of this we have avoided putting use cases in the charter as specific work items and taken the approach that if folks want to write use case I-D's and submit them to the WG for consideration then they are free to do so. I believe this is the right and most productive approach for the WG to take. On 9/4/13 3:55 PM, "Ken Gray" wrote: >"Feeding frenzy" is apt. I'm personally hoping we can constrain the >use-case love-fest within it's own document or any document in the WG to >those that illustrate/support specific requirements relevant to the >general specifications of the WG - that is, those that make the case for >specific metadata needs, site relevance to the header discussion, etc ... > >I expect these could be paragraph-to-page length summaries with pointers >to relevant architectures, drawings, related work (if they are included in >a document at all) - versus sweeping architectural disgorgement wherein >one or two points are actually salient/pertinent to the overall discussion >at hand. > >Having READ the various/numerous/copious use-case whitepapers in other >SDOs/quasi-SDOs/study_groups, I personally think anything longer goes in >the round, can-shaped object on my desktop. > > > >On 9/4/13 2:58 PM, "Melinda Shore" wrote: > >>On 9/4/13 10:33 AM, Joel M. Halpern wrote: >>> Separating the problem statement, framework, requirements, and "design >>> analysis" produces a multiplicity of documents which will divide the >>>WGs >>> efforts without, as far as I can tell, improving clarity. >> >>I agree quite strongly with this. >> >>> Similarly, while I find use case drafts useful information for the WG >>>to >>> consider, I think that arguing about which use cases we should put in >>>an >>> RFC, would not be a good use of the WGs time and energy. >> >>I'm not sure. Noting the feeding frenzy in this space, it may >>be worthwhile to define a few use cases that must be satisfied >>as a way to bring order to the chaos. On the other hand, getting >>the use cases laid out may bring about a slugfest of its own. >>I'm ambivalent about this but I do think it's worth trying to >>anticipate process issues and to think about how to avoid this >>turning into another nvo3. Use cases may or may not be helpful. >> >>Melinda >> >> >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc >> >> > > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Wed Sep 4 14:36: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 9BC8511E8126 for ; Wed, 4 Sep 2013 14:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.450, 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 UN7xAguW0zpl for ; Wed, 4 Sep 2013 14:36:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 34E4711E80ED for ; Wed, 4 Sep 2013 14:36:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVB19411; Wed, 04 Sep 2013 21:36:10 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 22:35:53 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 22:36:08 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 14:36:02 -0700 From: Linda Dunbar To: Ron Parker , "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtggAALk6CAAAI3kA== Date: Wed, 4 Sep 2013 21:36:02 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9D56D@dfweml509-mbx.china.huawei.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9D4FB@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-cr-hashedpuzzle: APSY FUlf FbBo HfR5 LgPh OwxE O04q RBuj SkBK TYeh VpkT Xvt1 Yg3S ZSlQ cd/t cz2Q; 3; agBnAHUAaQBjAGgAYQByAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBuAHMAYwBAAGkAZQB0AGYALgBvAHIAZwA7AHIAbwBuAF8AcABhAHIAawBlAHIAQABhAGYAZgBpAHIAbQBlAGQAbgBlAHQAdwBvAHIAawBzAC4AYwBvAG0A; Sosha1_v1; 7; {7A86E1C6-5F81-4035-9412-A50399C5ED9D}; bABpAG4AZABhAC4AZAB1AG4AYgBhAHIAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Wed, 04 Sep 2013 21:35:56 GMT; UgBFADoAIABOAFMAQwAgAFcAbwByAGsAaQBuAGcAIABHAHIAbwB1AHAAIABDAGgAYQByAHQAZQByACAAUAByAG8AcABvAHMAYQBsAA== x-cr-puzzleid: {7A86E1C6-5F81-4035-9412-A50399C5ED9D} x-originating-ip: [10.192.11.59] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B9D56Ddfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 21:36:19 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645B9D56Ddfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IMO, "single encapsulation" is too limiting. Many of today's service provi= der networks are MPLS based. In addition, there are even Ethernet based net= works (if you venture into IEEE802 or CEF). How about: "A single encapsulation per underlay network will be selected.."= ? Linda From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, September 04, 2013 4:27 PM To: Linda Dunbar; Jim Guichard (jguichar); nsc@ietf.org Subject: RE: NSC Working Group Charter Proposal Linda, I think that is a fundamental issue for the group to decide. If the goal = is a single encapsulation, then IMO it would have to be IP-based, since tha= t is the most common denominator. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda= Dunbar Sent: Wednesday, September 04, 2013 4:45 PM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal One clarification on Work Item #3: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. Is it really "A single encapsulation"? The encapsulation should depend on the underlay networks. Underlay network = could be IP based, MPLS based, or Ethernet based. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, September 03, 2013 11:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_4A95BA014132FF49AE685FAB4B9F17F645B9D56Ddfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMO, “single encaps= ulation” is too  limiting. Many of today’s service provide= r networks are MPLS based. In addition, there are even Ethernet based netwo= rks (if you  venture into IEEE802 or CEF).

 <= /p>

How about: “A single encapsulation per underlay network will be selected..&= #8221;?

 <= /p>

Linda

 <= /p>

From: Ron Park= er [mailto:Ron_Parker@affirmednetworks.com]
Sent: Wednesday, September 04, 2013 4:27 PM
To: Linda Dunbar; Jim Guichard (jguichar); nsc@ietf.org
Subject: RE: NSC Working Group Charter Proposal

 

Linda,<= /p>

 <= /p>

I think that is a fundame= ntal issue for the group to decide.   If the goal is a single enc= apsulation, then IMO it would have to be IP-based, since that is the most common denominator.   

 <= /p>

   Ron

 <= /p>

From: nsc-bo= unces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 4:45 PM
To: Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

One clarification on Work= Item #3:

3) Service= Chaining Data Plane: this document will describe on the wire data plane en= capsulation in support of (2). A single encapsulation will be selected in order to enable interoperability of data plane components.<= o:p>

 <= /p>

Is it really “A sin= gle encapsulation”?

The encapsulation should = depend on the underlay networks. Underlay network could be IP based, MPLS b= ased, or Ethernet based.  

 <= /p>

Linda

 <= /p>

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, September 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal<= /p>

 

Greetings,=

 

As we look forward to the fo= rmation of a working group that will focus on network service chaining, I w= ould like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area AD'= s. The following is a first draft of the charter and I invite you to active= ly participate and provide inputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion a= nd deployment techniques have not evolved to meet modern network architectu= res and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, st= orage, and applications, have all undergone significant change in recent ye= ars: virtualization, network overlays, and orchestration are increasingly t= he norm. All of these have profound effects on network and services design.

 

Today, deploying new service= s, or making changes to existing services, often requires network topology = changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o mostly-static service definitions. New service insertion and deployment t= echniques must enable the concept of service functions as shared resources,= and enable the linkage of these resources using service chains that represent the abstracted view of the r= equired service functions, and define the order in which they should be app= lied. When a service chain is instantiated in a network, specific instances= of service functions are selected, and a service topology is created and used for forwarding packets through = the service chain.

 

A basic service chain might = simply utilize an existing overlay technology to force traffic through the = necessary service functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chaining= (NSC) working group focuses on new approaches to service insertion and dep= loyment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary protocols for = the creation of service chains, and the passing of metadata from the networ= k to service functions, and between service functions. When possible, the W= G will extend existing protocols to provide service chaining functionality, and any protocol extensions wil= l be reviewed by both the Network Service Chaining WG and by the WG respons= ible for the protocol being extended.  

 

Specifically, the Network Se= rvice Chaining WG is chartered to deliver the following work items: 

 

1) Problem Statement: this d= ocument will provide a summary of the problem space to be addressed by the = Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.

 

2) System Architecture: this= set of documents will provide a description of the architecture building b= locks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pla= ne: this document will describe on the wire data plane encapsulation in sup= port of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docum= ent will address service chaining operation, monitoring and troubleshooting= including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are rea= lized.

 

Proposed Milestones:

 

Dec 2013 Request publication= of an Informational document defining the Network Service Chaining problem= statement to the IESG

 

Mar 2014 Request publication= of informational documents defining the system architecture including prot= ocol requirements and framework to the IESG

 

May 2014 Request publication= of a Standards Track document specifying the data-plane (including metadat= a) for Service Chaining to IESG

 

May 2014 Request publication= of an informational document specifying Service Chaining Control Plane req= uirements to IESG

 

Dec 2014 Request publication= of informational documents defining Service Chaining manageability require= ments including MIBs, OAM, and information models to IESG <= /span>

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645B9D56Ddfweml509mbxchi_-- From lucy.yong@huawei.com Wed Sep 4 14:38:34 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 02E2411E811E for ; Wed, 4 Sep 2013 14:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.112, 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 dezPk+qE4FLD for ; Wed, 4 Sep 2013 14:38:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 670E311E80D9 for ; Wed, 4 Sep 2013 14:38:26 -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.5-GA FastPath queued) with ESMTP id AVB19496; Wed, 04 Sep 2013 21:38:24 +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.146.0; Wed, 4 Sep 2013 22:38:07 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 22:38:23 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 14:38:10 -0700 From: Lucy yong To: Linda Dunbar , "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtggAAOrPA= Date: Wed, 4 Sep 2013 21:38:10 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452B3020@dfweml509-mbx.china.huawei.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9D4FB@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9D4FB@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.47.155.162] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452B3020dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 21:38:34 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452B3020dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The first charter should focus on the problem statement, architecture, use = case, and requirement; Not on specifying one solution. Therefore, work ite= m #3 should not be in the first charter. Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda= Dunbar Sent: Wednesday, September 04, 2013 3:45 PM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal One clarification on Work Item #3: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. Is it really "A single encapsulation"? The encapsulation should depend on the underlay networks. Underlay network = could be IP based, MPLS based, or Ethernet based. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, September 03, 2013 11:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_2691CE0099834E4A9C5044EEC662BB9D452B3020dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The first charter should = focus on the problem statement, architecture, use case, and requirement; &n= bsp;Not on specifying one solution. Therefore, work item #3 should not be in the first charter.

 <= /p>

Lucy

 <= /p>

From: nsc-boun= ces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 3:45 PM
To: Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

One clarification on Work= Item #3:

3) Service= Chaining Data Plane: this document will describe on the wire data plane en= capsulation in support of (2). A single encapsulation will be selected in order to enable interoperability of data plane components.<= o:p>

 <= /p>

Is it really “A sin= gle encapsulation”?

The encapsulation should = depend on the underlay networks. Underlay network could be IP based, MPLS b= ased, or Ethernet based.  

 <= /p>

Linda

 <= /p>

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, September 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal<= /p>

 

Greetings,=

 

As we look forward to the fo= rmation of a working group that will focus on network service chaining, I w= ould like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area AD'= s. The following is a first draft of the charter and I invite you to active= ly participate and provide inputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion a= nd deployment techniques have not evolved to meet modern network architectu= res and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, st= orage, and applications, have all undergone significant change in recent ye= ars: virtualization, network overlays, and orchestration are increasingly t= he norm. All of these have profound effects on network and services design.

 

Today, deploying new service= s, or making changes to existing services, often requires network topology = changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o mostly-static service definitions. New service insertion and deployment t= echniques must enable the concept of service functions as shared resources,= and enable the linkage of these resources using service chains that represent the abstracted view of the r= equired service functions, and define the order in which they should be app= lied. When a service chain is instantiated in a network, specific instances= of service functions are selected, and a service topology is created and used for forwarding packets through = the service chain.

 

A basic service chain might = simply utilize an existing overlay technology to force traffic through the = necessary service functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chaining= (NSC) working group focuses on new approaches to service insertion and dep= loyment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary protocols for = the creation of service chains, and the passing of metadata from the networ= k to service functions, and between service functions. When possible, the W= G will extend existing protocols to provide service chaining functionality, and any protocol extensions wil= l be reviewed by both the Network Service Chaining WG and by the WG respons= ible for the protocol being extended.  

 

Specifically, the Network Se= rvice Chaining WG is chartered to deliver the following work items: 

 

1) Problem Statement: this d= ocument will provide a summary of the problem space to be addressed by the = Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.

 

2) System Architecture: this= set of documents will provide a description of the architecture building b= locks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pla= ne: this document will describe on the wire data plane encapsulation in sup= port of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docum= ent will address service chaining operation, monitoring and troubleshooting= including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are rea= lized.

 

Proposed Milestones:

 

Dec 2013 Request publication= of an Informational document defining the Network Service Chaining problem= statement to the IESG

 

Mar 2014 Request publication= of informational documents defining the system architecture including prot= ocol requirements and framework to the IESG

 

May 2014 Request publication= of a Standards Track document specifying the data-plane (including metadat= a) for Service Chaining to IESG

 

May 2014 Request publication= of an informational document specifying Service Chaining Control Plane req= uirements to IESG

 

Dec 2014 Request publication= of informational documents defining Service Chaining manageability require= ments including MIBs, OAM, and information models to IESG <= /span>

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D452B3020dfweml509mbxchi_-- From linda.dunbar@huawei.com Wed Sep 4 14:42: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 CF52111E8100 for ; Wed, 4 Sep 2013 14:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.426, 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 O7dmblWpvqsg for ; Wed, 4 Sep 2013 14:41:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3A50311E80D9 for ; Wed, 4 Sep 2013 14:41: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.5-GA FastPath queued) with ESMTP id AWX29992; Wed, 04 Sep 2013 21:41:43 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 22:41:25 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 22:41:40 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 14:41:30 -0700 From: Linda Dunbar To: Lucy yong , "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtggAAOrPCAAAHhcA== Date: Wed, 4 Sep 2013 21:41:30 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9D596@dfweml509-mbx.china.huawei.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9D4FB@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452B3020@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452B3020@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AzD9 ERTW Ex2I E2QE GPg1 I+0p Ka4+ KuNj MSkp QsUU Rl+y Sfo8 S9Ds UKUn V5uX Xhlv; 2; agBnAHUAaQBjAGgAYQByAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBuAHMAYwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {42A992F1-562D-43FA-9823-DF040E1FE07F}; bABpAG4AZABhAC4AZAB1AG4AYgBhAHIAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Wed, 04 Sep 2013 21:41:22 GMT; UgBFADoAIABOAFMAQwAgAFcAbwByAGsAaQBuAGcAIABHAHIAbwB1AHAAIABDAGgAYQByAHQAZQByACAAUAByAG8AcABvAHMAYQBsAA== x-cr-puzzleid: {42A992F1-562D-43FA-9823-DF040E1FE07F} x-originating-ip: [10.192.11.59] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B9D596dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 21:42:01 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645B9D596dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree. Linda From: Lucy yong Sent: Wednesday, September 04, 2013 4:38 PM To: Linda Dunbar; Jim Guichard (jguichar); nsc@ietf.org Subject: RE: NSC Working Group Charter Proposal The first charter should focus on the problem statement, architecture, use = case, and requirement; Not on specifying one solution. Therefore, work ite= m #3 should not be in the first charter. Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda= Dunbar Sent: Wednesday, September 04, 2013 3:45 PM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal One clarification on Work Item #3: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. Is it really "A single encapsulation"? The encapsulation should depend on the underlay networks. Underlay network = could be IP based, MPLS based, or Ethernet based. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, September 03, 2013 11:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_4A95BA014132FF49AE685FAB4B9F17F645B9D596dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree.<= /p>

 <= /p>

Linda

 <= /p>

From: Lucy yon= g
Sent: Wednesday, September 04, 2013 4:38 PM
To: Linda Dunbar; Jim Guichard (jguichar); nsc@ietf.org
Subject: RE: NSC Working Group Charter Proposal

 

The first charter should = focus on the problem statement, architecture, use case, and requirement; &n= bsp;Not on specifying one solution. Therefore, work item #3 should not be in the first charter.

 <= /p>

Lucy

 <= /p>

From: nsc-boun= ces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 3:45 PM
To: Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

One clarification on Work= Item #3:

3) Service= Chaining Data Plane: this document will describe on the wire data plane en= capsulation in support of (2). A single encapsulation will be selected in order to enable interoperability of data plane components.<= o:p>

 <= /p>

Is it really “A sin= gle encapsulation”?

The encapsulation should = depend on the underlay networks. Underlay network could be IP based, MPLS b= ased, or Ethernet based.  

 <= /p>

Linda

 <= /p>

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, September 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal<= /p>

 

Greetings,=

 

As we look forward to the fo= rmation of a working group that will focus on network service chaining, I w= ould like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area AD'= s. The following is a first draft of the charter and I invite you to active= ly participate and provide inputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion a= nd deployment techniques have not evolved to meet modern network architectu= res and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, st= orage, and applications, have all undergone significant change in recent ye= ars: virtualization, network overlays, and orchestration are increasingly t= he norm. All of these have profound effects on network and services design.

 

Today, deploying new service= s, or making changes to existing services, often requires network topology = changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o mostly-static service definitions. New service insertion and deployment t= echniques must enable the concept of service functions as shared resources,= and enable the linkage of these resources using service chains that represent the abstracted view of the r= equired service functions, and define the order in which they should be app= lied. When a service chain is instantiated in a network, specific instances= of service functions are selected, and a service topology is created and used for forwarding packets through = the service chain.

 

A basic service chain might = simply utilize an existing overlay technology to force traffic through the = necessary service functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chaining= (NSC) working group focuses on new approaches to service insertion and dep= loyment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary protocols for = the creation of service chains, and the passing of metadata from the networ= k to service functions, and between service functions. When possible, the W= G will extend existing protocols to provide service chaining functionality, and any protocol extensions wil= l be reviewed by both the Network Service Chaining WG and by the WG respons= ible for the protocol being extended.  

 

Specifically, the Network Se= rvice Chaining WG is chartered to deliver the following work items: 

 

1) Problem Statement: this d= ocument will provide a summary of the problem space to be addressed by the = Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.

 

2) System Architecture: this= set of documents will provide a description of the architecture building b= locks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pla= ne: this document will describe on the wire data plane encapsulation in sup= port of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docum= ent will address service chaining operation, monitoring and troubleshooting= including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are rea= lized.

 

Proposed Milestones:

 

Dec 2013 Request publication= of an Informational document defining the Network Service Chaining problem= statement to the IESG

 

Mar 2014 Request publication= of informational documents defining the system architecture including prot= ocol requirements and framework to the IESG

 

May 2014 Request publication= of a Standards Track document specifying the data-plane (including metadat= a) for Service Chaining to IESG

 

May 2014 Request publication= of an informational document specifying Service Chaining Control Plane req= uirements to IESG

 

Dec 2014 Request publication= of informational documents defining Service Chaining manageability require= ments including MIBs, OAM, and information models to IESG <= /span>

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645B9D596dfweml509mbxchi_-- From paulq@cisco.com Wed Sep 4 14:42: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 3A30521F969F for ; Wed, 4 Sep 2013 14:42:56 -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=[AWL=-0.000, 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 T2HO7CCne8XP for ; Wed, 4 Sep 2013 14:42:51 -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 D91BB21F93D4 for ; Wed, 4 Sep 2013 14:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28692; q=dns/txt; s=iport; t=1378330971; x=1379540571; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fiL0aNN8ld1Aj3QMIRRKGcY2/Kx7sXv8xSlH+r0cxHc=; b=Cn0iSjV9vscrf6YYY9/bQLzByA89+nxdX9VnSXX+4n6+9YRrmQ6IOSwh c4CByIF8/Gpkil0LkkaHin0ETB6qhH1HcVydSpQg39qyd5RYIguaJAmJW 51Zle5JVsPyb9DFDqpLtWVXycHzXkj9OqA3NJ1oLiaFBx1sVpQDh++UYR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAFAPqoJ1KtJXG9/2dsb2JhbABagkNENVHBRIEoFnSCJAEBAQQBAQFkBwQHEAIBCBEBAwEBCxYHBycLFAMGCAIEDgUIh3oMujMEji2BAi0EBgECgxuBAAOUG5VAgyCBaUE X-IronPort-AV: E=Sophos;i="4.90,1023,1371081600"; d="scan'208,217";a="255650614" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 04 Sep 2013 21:42:48 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r84Lgl39029226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 21:42:47 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.101]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 16:42:47 -0500 From: "Paul Quinn (paulq)" To: Ron Parker Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtggAALk6CAAFk4AA== Date: Wed, 4 Sep 2013 21:42:47 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9D4FB@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: [10.19.172.246] Content-Type: multipart/alternative; boundary="_000_B4CF12F64861194990FEA0AE39F9B1620EA5923Axmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Linda Dunbar Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 21:42:56 -0000 --_000_B4CF12F64861194990FEA0AE39F9B1620EA5923Axmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ron, The encapsulation in this context refers to the service chain specific data= plane encapsulation (i.e. a service header) used for chaining. That in tur= n is wrapped in the overlay (we will strive to be overlay agnostic), which = in turn is carried via the underlay (we are agnostic here as well). Let's revise the proposed charter to make sure that it is clear on this poi= nt. Paul On Sep 4, 2013, at 2:27 PM, Ron Parker > wrote: Linda, I think that is a fundamental issue for the group to decide. If the goal = is a single encapsulation, then IMO it would have to be IP-based, since tha= t is the most common denominator. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, September 04, 2013 4:45 PM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal One clarification on Work Item #3: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. Is it really =93A single encapsulation=94? The encapsulation should depend on the underlay networks. Underlay network = could be IP based, MPLS based, or Ethernet based. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, September 03, 2013 11:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_B4CF12F64861194990FEA0AE39F9B1620EA5923Axmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0AEC5C11463F4E499DDAC927243561DD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Ron,

The encapsulation in this context refers to the service chain specific= dataplane encapsulation (i.e. a service header) used for chaining.  T= hat in turn is wrapped in the overlay (we will strive to be overlay agnosti= c), which in turn is carried via the underlay (we are agnostic here as well).

Let's revise the proposed charter to make sure that it is clear on thi= s point.

Paul

On Sep 4, 2013, at 2:27 PM, Ron Parker <Ron_Parker@affirmednetworks.com> wrote:
Linda,
 
I think that is a fundamental issue for the group to deci= de.   If the goal is a single encapsulation, then IMO it would ha= ve to be IP-based, since that is the most common denominator.   
 
   Ron
 
From= : = nsc-bounces@ietf.org = [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunb= ar
Sent: Wednesday, S= eptember 04, 2013 4:45 PM
To: Jim Guichard (= jguichar); nsc= @ietf.org
Subject: Re: [nsc]= NSC Working Group Charter Proposal
 
One clarification on Work Item #3:
3) Ser= vice Chaining Data Plane: this document will describe on the wire data plan= e encapsulation in support of (2). A single encapsulation will be selected = in order to enable interoperability of data plane components.
 
Is it really =93A single encapsulation=94?
The encapsulation should depend on the underlay networks.= Underlay network could be IP based, MPLS based, or Ethernet based.  <= o:p>
 
Linda
 
From:=  ns= c-bounces@ietf.org [<= a href=3D"mailto:nsc-bounces@ietf.org" style=3D"color: purple; text-decorat= ion: underline; ">mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guicha= rd (jguichar)
Sent: Tuesday, Sep= tember 03, 2013 11:01 AM
To: nsc= @ietf.org
Subject: [nsc] NSC= Working Group Charter Proposal
 
Greeti= ngs,
 =
As we = look forward to the formation of a working group that will focus on network= service chaining, I would like to propose a discussion on this alias to tr= y and reach consensus on an initial charter as requested by the routing area AD's. The following is a first dr= aft of the charter and I invite you to actively participate and provide inp= uts into this process.
 =
Pro= posed NSC WG Charter
 =
Existi= ng service insertion and deployment techniques have not evolved to meet mod= ern network architectures and do not reflect multi-tenancy, virtualization,= elasticity, rich classification, and other network requirements. Networks, servers, storage, and applicatio= ns, have all undergone significant change in recent years: virtualization, = network overlays, and orchestration are increasingly the norm. All of these= have profound effects on network and services design.
 =
Today,= deploying new services, or making changes to existing services, often requ= ires network topology changes. Adding and removing service functions is a c= omplex, risky task, that is tied to operationalizing topological changes leading to mostly-static service defi= nitions. New service insertion and deployment techniques must enable the co= ncept of service functions as shared resources, and enable the linkage of t= hese resources using service chains that represent the abstracted view of the required service functions, and = define the order in which they should be applied. When a service chain is i= nstantiated in a network, specific instances of service functions are selec= ted, and a service topology is created and used for forwarding packets through the service chain.
 =
A basi= c service chain might simply utilize an existing overlay technology to forc= e traffic through the necessary service functions. However, additional info= rmation enables a richer service chain for more advanced composite services. For example, shared information (e.g= ., the result of classification) can be used to offload service function pr= ocessing or inform other service functions about information that would oth= erwise be hard to glean. 
 =
The Ne= twork Service Chaining (NSC) working group focuses on new approaches to ser= vice insertion and deployment, providing a framework for the construction o= f services built using service chains. The WG focuses on the necessary protocols for the creation of service chai= ns, and the passing of metadata from the network to service functions, and = between service functions. When possible, the WG will extend existing proto= cols to provide service chaining functionality, and any protocol extensions will be reviewed by both the Ne= twork Service Chaining WG and by the WG responsible for the protocol being = extended.  
 =
Specif= ically, the Network Service Chaining WG is chartered to deliver the followi= ng work items: 
 =
1) Pro= blem Statement: this document will provide a summary of the problem space t= o be addressed by the Network Service Chaining WG including terminology and= sample use cases.  Additionally, the WG will normalize on nomenclature and definitions for Network Service = Chaining.
 =
2) Sys= tem Architecture: this set of documents will provide a description of the a= rchitecture building blocks and their relationships including interconnecti= on, placement of capabilities, and security models, as well as requirements on the control mechanisms and dat= a plane encapsulation.
 =
3) Ser= vice Chaining Data Plane: this document will describe on the wire data plan= e encapsulation in support of (2).  A single encapsulation will be sel= ected in order to enable interoperability of data plane components.
 =
4) Man= ageability: this document will address service chaining operation, monitori= ng and troubleshooting including relevant service chaining models such as M= IBs or YANG modules, along with relevant OAM capabilities and how they are realized.
 =
Propos= ed Milestones:
 =
Dec 20= 13 Request publication of an Informational document defining the Network Se= rvice Chaining problem statement to the IESG
 =
Mar 20= 14 Request publication of informational documents defining the system archi= tecture including protocol requirements and framework to the IESG
 =
May 20= 14 Request publication of a Standards Track document specifying the data-pl= ane (including metadata) for Service Chaining to IESG
 =
May 20= 14 Request publication of an informational document specifying Service Chai= ning Control Plane requirements to IESG
 =
Dec 20= 14 Request publication of informational documents defining Service Chaining= manageability requirements including MIBs, OAM, and information models to = IESG 
 =
 =
_______________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc<= /a>

--_000_B4CF12F64861194990FEA0AE39F9B1620EA5923Axmbrcdx14ciscoc_-- From lucy.yong@huawei.com Wed Sep 4 14: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 9B41121F9AA8 for ; Wed, 4 Sep 2013 14:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 znZ5mDlZ-1o7 for ; Wed, 4 Sep 2013 14:44:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C772321F969F for ; Wed, 4 Sep 2013 14:44:43 -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.5-GA FastPath queued) with ESMTP id AWX30105; Wed, 04 Sep 2013 21:44:38 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 22:44:22 +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.146.0; Wed, 4 Sep 2013 22:44:38 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 14:44:35 -0700 From: Lucy yong To: "Jim Guichard (jguichar)" , Ken Gray , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1Ee0QgAFMUYCAAAckAIAAD/eAgAAaVYD//43bgA== Date: Wed, 4 Sep 2013 21:44:34 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452B303B@dfweml509-mbx.china.huawei.com> References: <68B171751455884590F8E38E96416F363F6761C4@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6761C4@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.47.155.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 21:44:48 -0000 Service chaining scenarios is not clear to me yet. The problem statement dr= aft (v03) has the section but not content. Suggest giving clear use case fi= rst before spending a lot of time on charter text. If we all clear what is = the use case and problem, will be much easy to agree on the charter scope. Lucy -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Wednesday, September 04, 2013 4:30 PM To: Ken Gray; Melinda Shore; nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Our approach with the charter has been to document a couple of high-level u= se cases within the problem statement if only to educate folks on what the = heck we are talking about. Outside of this we have avoided putting use case= s in the charter as specific work items and taken the approach that if folk= s want to write use case I-D's and submit them to the WG for consideration = then they are free to do so. I believe this is the right and most productiv= e approach for the WG to take. On 9/4/13 3:55 PM, "Ken Gray" wrote: >"Feeding frenzy" is apt. I'm personally hoping we can constrain the=20 >use-case love-fest within it's own document or any document in the WG=20 >to those that illustrate/support specific requirements relevant to the=20 >general specifications of the WG - that is, those that make the case=20 >for specific metadata needs, site relevance to the header discussion, etc = ... > >I expect these could be paragraph-to-page length summaries with=20 >pointers to relevant architectures, drawings, related work (if they are=20 >included in a document at all) - versus sweeping architectural=20 >disgorgement wherein one or two points are actually salient/pertinent=20 >to the overall discussion at hand. > >Having READ the various/numerous/copious use-case whitepapers in other=20 >SDOs/quasi-SDOs/study_groups, I personally think anything longer goes=20 >in the round, can-shaped object on my desktop. > > > >On 9/4/13 2:58 PM, "Melinda Shore" wrote: > >>On 9/4/13 10:33 AM, Joel M. Halpern wrote: >>> Separating the problem statement, framework, requirements, and=20 >>>"design analysis" produces a multiplicity of documents which will=20 >>>divide the WGs efforts without, as far as I can tell, improving=20 >>>clarity. >> >>I agree quite strongly with this. >> >>> Similarly, while I find use case drafts useful information for the=20 >>>WG to consider, I think that arguing about which use cases we should=20 >>>put in an RFC, would not be a good use of the WGs time and energy. >> >>I'm not sure. Noting the feeding frenzy in this space, it may be=20 >>worthwhile to define a few use cases that must be satisfied as a way=20 >>to bring order to the chaos. On the other hand, getting the use cases=20 >>laid out may bring about a slugfest of its own. >>I'm ambivalent about this but I do think it's worth trying to=20 >>anticipate process issues and to think about how to avoid this turning=20 >>into another nvo3. Use cases may or may not be helpful. >> >>Melinda >> >> >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc >> >> > > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From lucy.yong@huawei.com Wed Sep 4 14:52: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 D4FF921F9193 for ; Wed, 4 Sep 2013 14:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.090, 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 2a-ceGMEKU59 for ; Wed, 4 Sep 2013 14:52:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5D54521F8F67 for ; Wed, 4 Sep 2013 14:51:34 -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.5-GA FastPath queued) with ESMTP id AWX30392; Wed, 04 Sep 2013 21:51:33 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 22:51:17 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 22:51:32 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 14:51:21 -0700 From: Lucy yong To: "Paul Quinn (paulq)" , Ron Parker Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtggAALk6CAAFk4AP//rjtg Date: Wed, 4 Sep 2013 21:51:21 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452B305F@dfweml509-mbx.china.huawei.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9D4FB@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.47.155.162] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452B305Fdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Linda Dunbar Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 21:52:11 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452B305Fdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think that this belongs to the first charter. This can be captured = in the requirement, but not a work item in the first charter. Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Paul = Quinn (paulq) Sent: Wednesday, September 04, 2013 4:43 PM To: Ron Parker Cc: nsc@ietf.org; Jim Guichard (jguichar); Linda Dunbar Subject: Re: [nsc] NSC Working Group Charter Proposal Ron, The encapsulation in this context refers to the service chain specific data= plane encapsulation (i.e. a service header) used for chaining. That in tur= n is wrapped in the overlay (we will strive to be overlay agnostic), which = in turn is carried via the underlay (we are agnostic here as well). Let's revise the proposed charter to make sure that it is clear on this poi= nt. Paul On Sep 4, 2013, at 2:27 PM, Ron Parker > wrote: Linda, I think that is a fundamental issue for the group to decide. If the goal = is a single encapsulation, then IMO it would have to be IP-based, since tha= t is the most common denominator. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, September 04, 2013 4:45 PM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal One clarification on Work Item #3: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. Is it really "A single encapsulation"? The encapsulation should depend on the underlay networks. Underlay network = could be IP based, MPLS based, or Ethernet based. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, September 03, 2013 11:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_2691CE0099834E4A9C5044EEC662BB9D452B305Fdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t think that = this belongs to the first charter. This can be captured in the requirement,= but not a work item in the first charter.

Lucy

 <= /p>

From: nsc-boun= ces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Wednesday, September 04, 2013 4:43 PM
To: Ron Parker
Cc: nsc@ietf.org; Jim Guichard (jguichar); Linda Dunbar
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

Ron,

 

The encapsulation in this context refers to the serv= ice chain specific dataplane encapsulation (i.e. a service header) used for= chaining.  That in turn is wrapped in the overlay (we will strive to = be overlay agnostic), which in turn is carried via the underlay (we are agnostic here as well).

 

Let's revise the proposed charter to make sure that = it is clear on this point.

 

Paul

 



Linda,<= /p>

 <= /p>

I think that is a fundame= ntal issue for the group to decide.   If the goal is a single enc= apsulation, then IMO it would have to be IP-based, since that is the most common denominator.   

 <= /p>

   Ron

 <= /p>

From: nsc-bounces@ietf.= org [mailto:ns= c-bounces@= ietf.org] O= n Behalf Of Linda Dunb= ar
Sent: Wednesday, S= eptember 04, 2013 4:45 PM
To: Jim Guichard (= jguichar); nsc@ietf.org
Subject: Re: [nsc]= NSC Working Group Charter Proposal

 

One clarification on Work= Item #3:

3) Service Chaining Data Plane: this doc= ument will describe on the wire data plane encapsulation in support of (2).= A single encapsulation will be selected in order to enable interoperability of data plane components.

 <= /p>

Is it really “A sin= gle encapsulation”?

The encapsulation should = depend on the underlay networks. Underlay network could be IP based, MPLS b= ased, or Ethernet based.  

 <= /p>

Linda

 <= /p>

From: nsc-bounces@ietf.org=  [mailto:nsc-bounces= @ietf.org] = On Behalf Of Jim Guicha= rd (jguichar)
Sent: Tuesday, Sep= tember 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC= Working Group Charter Proposal

 

Greetings,

 

As we look forward to the formation of a= working group that will focus on network service chaining, I would like to= propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area AD's. The following= is a first draft of the charter and I invite you to actively participate a= nd provide inputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion and deploymen= t techniques have not evolved to meet modern network architectures and do n= ot reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, storage= , and applications, have all undergone significant change in recent years: = virtualization, network overlays, and orchestration are increasingly the no= rm. All of these have profound effects on network and services design.

 

Today, deploying new services, or making= changes to existing services, often requires network topology changes. Add= ing and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading to mostly-sta= tic service definitions. New service insertion and deployment techniques mu= st enable the concept of service functions as shared resources, and enable = the linkage of these resources using service chains that represent the abstracted view of the required service = functions, and define the order in which they should be applied. When a ser= vice chain is instantiated in a network, specific instances of service func= tions are selected, and a service topology is created and used for forwarding packets through the service ch= ain.

 

A basic service chain might simply utili= ze an existing overlay technology to force traffic through the necessary se= rvice functions. However, additional information enables a richer service chain for more advanced composite services. For example, = shared information (e.g., the result of classification) can be used to offl= oad service function processing or inform other service functions about inf= ormation that would otherwise be hard to glean. 

 

The Network Service Chaining (NSC) worki= ng group focuses on new approaches to service insertion and deployment, pro= viding a framework for the construction of services built using service chains. The WG focuses on the necessary protocols for the cr= eation of service chains, and the passing of metadata from the network to s= ervice functions, and between service functions. When possible, the WG will= extend existing protocols to provide service chaining functionality, and any protocol extensions will be review= ed by both the Network Service Chaining WG and by the WG responsible for th= e protocol being extended.  

 

Specifically, the Network Service Chaini= ng WG is chartered to deliver the following work items: 

 

1) Problem Statement: this document will= provide a summary of the problem space to be addressed by the Network Serv= ice Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and definitions = for Network Service Chaining.

 

2) System Architecture: this set of docu= ments will provide a description of the architecture building blocks and th= eir relationships including interconnection, placement of capabilities, and security models, as well as requirements on the control = mechanisms and data plane encapsulation.

 

3) Service Chaining Data Plane: this doc= ument will describe on the wire data plane encapsulation in support of (2).=  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this document will add= ress service chaining operation, monitoring and troubleshooting including r= elevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are realized.

 

Proposed Milestones:

 

Dec 2013 Request publication of an Infor= mational document defining the Network Service Chaining problem statement t= o the IESG

 

Mar 2014 Request publication of informat= ional documents defining the system architecture including protocol require= ments and framework to the IESG

 

May 2014 Request publication of a Standa= rds Track document specifying the data-plane (including metadata) for Servi= ce Chaining to IESG

 

May 2014 Request publication of an infor= mational document specifying Service Chaining Control Plane requirements to= IESG

 

Dec 2014 Request publication of informat= ional documents defining Service Chaining manageability requirements includ= ing MIBs, OAM, and information models to IESG 

 

 

_____________________________________= __________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

 

--_000_2691CE0099834E4A9C5044EEC662BB9D452B305Fdfweml509mbxchi_-- From Ron_Parker@affirmednetworks.com Wed Sep 4 14:57: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 C1FB821F9ACA for ; Wed, 4 Sep 2013 14:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.112, 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 mf4ZcYDihYwd for ; Wed, 4 Sep 2013 14:57:34 -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 D7A5A21F8F6D for ; Wed, 4 Sep 2013 14:57:34 -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; Wed, 4 Sep 2013 14:57:33 -0700 From: Ron Parker To: "Paul Quinn (paulq)" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtggAALk6CAAFk4AP//sAWA Date: Wed, 4 Sep 2013 21:57:33 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9D4FB@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: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6D0E44MBX021W3CA2exch_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Linda Dunbar Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 21:57:40 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6D0E44MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Paul. I was thinking of the overlay + chain-specific when I was t= hinking "encapsulation" (e.g., a GRE-with-key like construct). Ron From: Paul Quinn (paulq) [mailto:paulq@cisco.com] Sent: Wednesday, September 04, 2013 5:43 PM To: Ron Parker Cc: Linda Dunbar; Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Ron, The encapsulation in this context refers to the service chain specific data= plane encapsulation (i.e. a service header) used for chaining. That in tur= n is wrapped in the overlay (we will strive to be overlay agnostic), which = in turn is carried via the underlay (we are agnostic here as well). Let's revise the proposed charter to make sure that it is clear on this poi= nt. Paul On Sep 4, 2013, at 2:27 PM, Ron Parker > wrote: Linda, I think that is a fundamental issue for the group to decide. If the goal = is a single encapsulation, then IMO it would have to be IP-based, since tha= t is the most common denominator. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, September 04, 2013 4:45 PM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal One clarification on Work Item #3: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. Is it really "A single encapsulation"? The encapsulation should depend on the underlay networks. Underlay network = could be IP based, MPLS based, or Ethernet based. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, September 03, 2013 11:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6D0E44MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Paul.  = I was thinking of the overlay + chain-specific when I was thinking = 220;encapsulation” (e.g., a GRE-with-key like construct).<= /span>

 <= /p>

   Ron

 <= /p>

From: Paul Q= uinn (paulq) [mailto:paulq@cisco.com]
Sent: Wednesday, September 04, 2013 5:43 PM
To: Ron Parker
Cc: Linda Dunbar; Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

Ron,

 

The encapsulation in this context refers to the serv= ice chain specific dataplane encapsulation (i.e. a service header) used for= chaining.  That in turn is wrapped in the overlay (we will strive to = be overlay agnostic), which in turn is carried via the underlay (we are agnostic here as well).

 

Let's revise the proposed charter to make sure that = it is clear on this point.

 

Paul

 

On Sep 4, 2013, at 2:27 PM, Ron Parker <Ron_Parker@affirmednetworks.com= > wrote:



Linda,<= /p>

 <= /p>

I think that is a fundame= ntal issue for the group to decide.   If the goal is a single enc= apsulation, then IMO it would have to be IP-based, since that is the most common denominator.   

 <= /p>

   Ron

 <= /p>

From: nsc-bounces@ietf.= org [mailto:ns= c-bounces@= ietf.org] O= n Behalf Of Linda Dunb= ar
Sent: Wednesday, S= eptember 04, 2013 4:45 PM
To: Jim Guichard (= jguichar); nsc@ietf.org
Subject: Re: [nsc]= NSC Working Group Charter Proposal

 

One clarification on Work= Item #3:

3) Service Chaining Data Plane: this doc= ument will describe on the wire data plane encapsulation in support of (2).= A single encapsulation will be selected in order to enable interoperability of data plane components.

 <= /p>

Is it really “A sin= gle encapsulation”?

The encapsulation should = depend on the underlay networks. Underlay network could be IP based, MPLS b= ased, or Ethernet based.  

 <= /p>

Linda

 <= /p>

From: nsc-bounces@ietf.org=  [mailto:nsc-bounces= @ietf.org] = On Behalf Of Jim Guicha= rd (jguichar)
Sent: Tuesday, Sep= tember 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC= Working Group Charter Proposal

 

Greetings,

 

As we look forward to the formation of a= working group that will focus on network service chaining, I would like to= propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area AD's. The following= is a first draft of the charter and I invite you to actively participate a= nd provide inputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion and deploymen= t techniques have not evolved to meet modern network architectures and do n= ot reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, storage= , and applications, have all undergone significant change in recent years: = virtualization, network overlays, and orchestration are increasingly the no= rm. All of these have profound effects on network and services design.

 

Today, deploying new services, or making= changes to existing services, often requires network topology changes. Add= ing and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading to mostly-sta= tic service definitions. New service insertion and deployment techniques mu= st enable the concept of service functions as shared resources, and enable = the linkage of these resources using service chains that represent the abstracted view of the required service = functions, and define the order in which they should be applied. When a ser= vice chain is instantiated in a network, specific instances of service func= tions are selected, and a service topology is created and used for forwarding packets through the service ch= ain.

 

A basic service chain might simply utili= ze an existing overlay technology to force traffic through the necessary se= rvice functions. However, additional information enables a richer service chain for more advanced composite services. For example, = shared information (e.g., the result of classification) can be used to offl= oad service function processing or inform other service functions about inf= ormation that would otherwise be hard to glean. 

 

The Network Service Chaining (NSC) worki= ng group focuses on new approaches to service insertion and deployment, pro= viding a framework for the construction of services built using service chains. The WG focuses on the necessary protocols for the cr= eation of service chains, and the passing of metadata from the network to s= ervice functions, and between service functions. When possible, the WG will= extend existing protocols to provide service chaining functionality, and any protocol extensions will be review= ed by both the Network Service Chaining WG and by the WG responsible for th= e protocol being extended.  

 

Specifically, the Network Service Chaini= ng WG is chartered to deliver the following work items: 

 

1) Problem Statement: this document will= provide a summary of the problem space to be addressed by the Network Serv= ice Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and definitions = for Network Service Chaining.

 

2) System Architecture: this set of docu= ments will provide a description of the architecture building blocks and th= eir relationships including interconnection, placement of capabilities, and security models, as well as requirements on the control = mechanisms and data plane encapsulation.

 

3) Service Chaining Data Plane: this doc= ument will describe on the wire data plane encapsulation in support of (2).=  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this document will add= ress service chaining operation, monitoring and troubleshooting including r= elevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are realized.

 

Proposed Milestones:

 

Dec 2013 Request publication of an Infor= mational document defining the Network Service Chaining problem statement t= o the IESG

 

Mar 2014 Request publication of informat= ional documents defining the system architecture including protocol require= ments and framework to the IESG

 

May 2014 Request publication of a Standa= rds Track document specifying the data-plane (including metadata) for Servi= ce Chaining to IESG

 

May 2014 Request publication of an infor= mational document specifying Service Chaining Control Plane requirements to= IESG

 

Dec 2014 Request publication of informat= ional documents defining Service Chaining manageability requirements includ= ing MIBs, OAM, and information models to IESG 

 

 

_____________________________________= __________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6D0E44MBX021W3CA2exch_-- From jguichar@cisco.com Wed Sep 4 15:03: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 2636121F9D52 for ; Wed, 4 Sep 2013 15:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Uf6h66In4fa1 for ; Wed, 4 Sep 2013 15:03:00 -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 2EEFE21F8D29 for ; Wed, 4 Sep 2013 15:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25780; q=dns/txt; s=iport; t=1378332177; x=1379541777; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=bDUDxMRKrSzHFlDZ6vyH2YgMxKlbECVgzhS8zK8Ts1E=; b=J+YeXsyivQeUmI7SNdACp06dBCV3HU5teVO2lhfOZq2pm8V27L2zNfxT j0g0pCVY+v30eApvA+WcYXm4fk3f1AFhAJAmygstQ+K+T0rIUynBDX5BP 0LgFORgPS53jRQS8InBJ9NRbLg1y6Fwp6ttKYP1kTip/WoCynECduhvUl k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAPWsJ1KtJV2c/2dsb2JhbABbgkNENVHBRIEpFnSCJAEBAQQtRRkBCBEBAgEBAQsWBzkUAwYIAgQBEggTh2e6PY4tgQIgFwGDHYEAA5QblUCDIIFpQQ X-IronPort-AV: E=Sophos;i="4.90,1023,1371081600"; d="scan'208,217";a="252684839" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 04 Sep 2013 22:02:56 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r84M2uoA003545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 22:02:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 17:02:55 -0500 From: "Jim Guichard (jguichar)" To: Lucy yong , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtggAAOrPCAABiugA== Date: Wed, 4 Sep 2013 22:02:55 +0000 Message-ID: <68B171751455884590F8E38E96416F363F676386@xmb-rcd-x01.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452B3020@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.254.27] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F676386xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 22:03:06 -0000 --_000_68B171751455884590F8E38E96416F363F676386xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I disagree, this working group must be focused on solutions and not pontifi= cation over terminology or a laundry list of use cases. Having said that yo= u will note in the milestones that the problem statement and requirements a= re the first work items to be delivered followed by the data plane that wil= l support both. It is perfectly acceptable to provide a planned outline of = the WG activities and this is reflected in the charter. From: Lucy yong > Date: Wednesday, September 4, 2013 5:38 PM To: Linda Dunbar >,= Microsoft Office User >, "ns= c@ietf.org" > Subject: Re: [nsc] NSC Working Group Charter Proposal The first charter should focus on the problem statement, architecture, use = case, and requirement; Not on specifying one solution. Therefore, work ite= m #3 should not be in the first charter. Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, September 04, 2013 3:45 PM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal One clarification on Work Item #3: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. Is it really =93A single encapsulation=94? The encapsulation should depend on the underlay networks. Underlay network = could be IP based, MPLS based, or Ethernet based. Linda From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, September 03, 2013 11:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_68B171751455884590F8E38E96416F363F676386xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <209E62C6C2F7C14D9476A144CE8535E8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I disagree, this working group must be focused on solut= ions and not pontification over terminology or a laundry list of use cases.= Having said that you will note in the milestones that the problem statement and requirements are the first w= ork items to be delivered followed by the data plane = that will support both. It is perfectly acceptable to provide a planned out= line of the WG activities and this is reflected in the charter. 

From: Lucy yong <lucy.yong@huawei.com>
Date: Wednesday, September 4, 2013 = 5:38 PM
To: Linda Dunbar <linda.dunbar@huawei.com>, Microsoft Off= ice User <jguichar@cisco.com&g= t;, "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] NSC Working Grou= p Charter Proposal

The first charter should focus on = the problem statement, architecture, use case, and requirement;  Not o= n specifying one solution. Therefore, work item #3 should not be in the first charter.

 

Lucy

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 3:45 PM
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

One clarification on Work Item #3:=

3) Service Chaining Data Pla= ne: this document will describe on the wire data plane encapsulation in sup= port of (2). A single encapsulation will be selected in order to enable interoperability of data plane components.<= o:p>

 

Is it really =93A single encapsula= tion=94?

The encapsulation should depend on= the underlay networks. Underlay network could be IP based, MPLS based, or = Ethernet based.  

 

Linda

 

From:nsc-bounc= es@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, September 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal<= /p>

 

Greetings,

 

As we look forward to the formation of a wor= king group that will focus on network service chaining, I would like to pro= pose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area= AD's. The following is a first draft of the charter and I invite you to ac= tively participate and provide inputs into this process.<= /p>

 

Proposed NSC WG Charter

 

Existing service insertion and deployment te= chniques have not evolved to meet modern network architectures and do not r= eflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks,= servers, storage, and applications, have all undergone significant change = in recent years: virtualization, network overlays, and orchestration are in= creasingly the norm. All of these have profound effects on network and services design.

 

Today, deploying new services, or making cha= nges to existing services, often requires network topology changes. Adding = and removing service functions is a complex, risky task, that is tied to operationalizing topological changes = leading to mostly-static service definitions. New service insertion and dep= loyment techniques must enable the concept of service functions as shared r= esources, and enable the linkage of these resources using service chains that represent the abstracted view= of the required service functions, and define the order in which they shou= ld be applied. When a service chain is instantiated in a network, specific = instances of service functions are selected, and a service topology is created and used for forwarding packet= s through the service chain.

 

A basic service chain might simply utilize a= n existing overlay technology to force traffic through the necessary servic= e functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chaining (NSC) working g= roup focuses on new approaches to service insertion and deployment, providi= ng a framework for the construction of services built using service chains. The WG focuses on the necessary pr= otocols for the creation of service chains, and the passing of metadata fro= m the network to service functions, and between service functions. When pos= sible, the WG will extend existing protocols to provide service chaining functionality, and any protocol exte= nsions will be reviewed by both the Network Service Chaining WG and by the = WG responsible for the protocol being extended.  

 

Specifically, the Network Service Chaining W= G is chartered to deliver the following work items: =

 

1) Problem Statement: this document will pro= vide a summary of the problem space to be addressed by the Network Service = Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclatur= e and definitions for Network Service Chaining.

 

2) System Architecture: this set of document= s will provide a description of the architecture building blocks and their = relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Plane: this documen= t will describe on the wire data plane encapsulation in support of (2). &nb= sp;A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this document will address= service chaining operation, monitoring and troubleshooting including relev= ant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they ar= e realized.

 

Proposed Milestones:

 

Dec 2013 Request publication of an Informati= onal document defining the Network Service Chaining problem statement to th= e IESG

 

Mar 2014 Request publication of informationa= l documents defining the system architecture including protocol requirement= s and framework to the IESG

 

May 2014 Request publication of a Standards = Track document specifying the data-plane (including metadata) for Service C= haining to IESG

 

May 2014 Request publication of an informati= onal document specifying Service Chaining Control Plane requirements to IES= G

 

Dec 2014 Request publication of informationa= l documents defining Service Chaining manageability requirements including = MIBs, OAM, and information models to IESG 

 

 

 --_000_68B171751455884590F8E38E96416F363F676386xmbrcdx01ciscoc_-- From lucy.yong@huawei.com Wed Sep 4 15:13: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 57A4821F9F97 for ; Wed, 4 Sep 2013 15:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.082, 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 4RkQRs1zXwPv for ; Wed, 4 Sep 2013 15:13:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D545A21F9DA8 for ; Wed, 4 Sep 2013 15:13:50 -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.5-GA FastPath queued) with ESMTP id AVB20851; Wed, 04 Sep 2013 22:13:49 +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.146.0; Wed, 4 Sep 2013 23:11:57 +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.146.0; Wed, 4 Sep 2013 23:12:13 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 15:12:03 -0700 From: Lucy yong To: "Jim Guichard (jguichar)" , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtggAAOrPCAABiugP//8GhQ Date: Wed, 4 Sep 2013 22:12:03 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452B30B3@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452B3020@dfweml509-mbx.china.huawei.com> <68B171751455884590F8E38E96416F363F676386@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F676386@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.47.155.162] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452B30B3dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 22:13:57 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452B30B3dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not many people well understand the problem and use case yet. The bof in IE= TF87 does not convey the issues clearly. So the first charter should solve = that first before to work on the solution. The work items listed in the cha= rter do not indicate has the order. The time table clear indicates they wil= l be worked at the same time. I agree that we should standardize one data = plane solution, but don't think the schedule is proper. Lucy From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Wednesday, September 04, 2013 5:03 PM To: Lucy yong; Linda Dunbar; nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal I disagree, this working group must be focused on solutions and not pontifi= cation over terminology or a laundry list of use cases. Having said that yo= u will note in the milestones that the problem statement and requirements a= re the first work items to be delivered followed by the data plane that wil= l support both. It is perfectly acceptable to provide a planned outline of = the WG activities and this is reflected in the charter. From: Lucy yong > Date: Wednesday, September 4, 2013 5:38 PM To: Linda Dunbar >,= Microsoft Office User >, "ns= c@ietf.org" > Subject: Re: [nsc] NSC Working Group Charter Proposal The first charter should focus on the problem statement, architecture, use = case, and requirement; Not on specifying one solution. Therefore, work ite= m #3 should not be in the first charter. Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, September 04, 2013 3:45 PM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal One clarification on Work Item #3: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. Is it really "A single encapsulation"? The encapsulation should depend on the underlay networks. Underlay network = could be IP based, MPLS based, or Ethernet based. Linda From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, September 03, 2013 11:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_2691CE0099834E4A9C5044EEC662BB9D452B30B3dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not many people well unde= rstand the problem and use case yet. The bof in IETF87 does not convey the = issues clearly. So the first charter should solve that first before to work on the solution. The work items listed in the charter do no= t indicate has the order. The time table clear indicates they will be worke= d at the same time.  I agree that we should standardize one data plane= solution, but don’t think the schedule is proper.

 <= /p>

Lucy

 <= /p>

From: Jim Guic= hard (jguichar) [mailto:jguichar@cisco.com]
Sent: Wednesday, September 04, 2013 5:03 PM
To: Lucy yong; Linda Dunbar; nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

I disagree, this working group = must be focused on solutions and not pontification over terminology or a laundry list of u= se cases. Having said that you will = note in the milestones that the problem statement and requirements are the first work items to be delivered followed = ;by the data plane that will support both. It is perfectly acceptable to pr= ovide a planned outline of the WG activities and this is reflected in the c= harter. 

 

From: Lucy yong <lucy.yong@huawei.com>
Date: Wednesday, September 4, 2013 5:38 PM
To: Linda Dunbar <lind= a.dunbar@huawei.com>, Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@iet= f.org>
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

The first charter should = focus on the problem statement, architecture, use case, and requirement; &n= bsp;Not on specifying one solution. Therefore, work item #3 should not be in the first charter.=

 

Lucy

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 3:45 PM
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 =

One clarification on Work= Item #3:

 

Is it really “A sin= gle encapsulation”?

The encapsulation should = depend on the underlay networks. Underlay network could be IP based, MPLS b= ased, or Ethernet based.  

 

Linda

 

From:nsc-bounces@ietf.org= [mailto:nsc-bounces@ietf.org] = On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, September 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal

 =

Greetings,

 

As we look forward to the fo= rmation of a working group that will focus on network service chaining, I w= ould like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area AD'= s. The following is a first draft of the charter and I invite you to active= ly participate and provide inputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion a= nd deployment techniques have not evolved to meet modern network architectu= res and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, st= orage, and applications, have all undergone significant change in recent ye= ars: virtualization, network overlays, and orchestration are increasingly t= he norm. All of these have profound effects on network and services design.=

 

Today, deploying new service= s, or making changes to existing services, often requires network topology = changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o mostly-static service definitions. New service insertion and deployment t= echniques must enable the concept of service functions as shared resources,= and enable the linkage of these resources using service chains that represent the abstracted view of the r= equired service functions, and define the order in which they should be app= lied. When a service chain is instantiated in a network, specific instances= of service functions are selected, and a service topology is created and used for forwarding packets through = the service chain.

 

A basic service chain might = simply utilize an existing overlay technology to force traffic through the = necessary service functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chaining= (NSC) working group focuses on new approaches to service insertion and dep= loyment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary protocols for = the creation of service chains, and the passing of metadata from the networ= k to service functions, and between service functions. When possible, the W= G will extend existing protocols to provide service chaining functionality, and any protocol extensions wil= l be reviewed by both the Network Service Chaining WG and by the WG respons= ible for the protocol being extended.  

 

Specifically, the Network Se= rvice Chaining WG is chartered to deliver the following work items: 

 

1) Problem Statement: this d= ocument will provide a summary of the problem space to be addressed by the = Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.=

 

2) System Architecture: this= set of documents will provide a description of the architecture building b= locks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pla= ne: this document will describe on the wire data plane encapsulation in sup= port of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docum= ent will address service chaining operation, monitoring and troubleshooting= including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are rea= lized.

 

Proposed Milestones:<= span style=3D"color:black">

 

Dec 2013 Request publication= of an Informational document defining the Network Service Chaining problem= statement to the IESG=

 

Mar 2014 Request publication= of informational documents defining the system architecture including prot= ocol requirements and framework to the IESG

 

May 2014 Request publication= of a Standards Track document specifying the data-plane (including metadat= a) for Service Chaining to IESG

 

May 2014 Request publication= of an informational document specifying Service Chaining Control Plane req= uirements to IESG

 

Dec 2014 Request publication= of informational documents defining Service Chaining manageability require= ments including MIBs, OAM, and information models to IESG 

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D452B30B3dfweml509mbxchi_-- From kgray@juniper.net Wed Sep 4 15:38:34 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 E28D321F942D for ; Wed, 4 Sep 2013 15:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=-0.734, 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 Sam89L97Oe0g for ; Wed, 4 Sep 2013 15:38:29 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id 8984221F9E94 for ; Wed, 4 Sep 2013 15:38:28 -0700 (PDT) Received: from mail76-db8-R.bigfish.com (10.174.8.235) by DB8EHSOBE005.bigfish.com (10.174.4.68) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 22:38:27 +0000 Received: from mail76-db8 (localhost [127.0.0.1]) by mail76-db8-R.bigfish.com (Postfix) with ESMTP id 8137EA00087; Wed, 4 Sep 2013 22:38:27 +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: -21 X-BigFish: VPS-21(zz9371Ic85ehdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de097h186068h8275bh8275dhz2fh2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail76-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:(377454003)(189002)(199002)(80976001)(79102001)(76786001)(76796001)(77096001)(83506001)(56816003)(46102001)(561944002)(74366001)(18717965001)(63696002)(36756003)(76176001)(80022001)(47976001)(47736001)(59766001)(77982001)(16236675002)(54356001)(31966008)(65816001)(81542001)(56776001)(50986001)(74662001)(51856001)(15975445006)(54316002)(81342001)(47446002)(76482001)(74502001)(69226001)(15202345003)(19300405004)(81686001)(83072001)(74706001)(74876001)(19580405001)(4396001)(49866001)(53806001)(19580395003)(83322001)(81816001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB083; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail76-db8 (localhost.localdomain [127.0.0.1]) by mail76-db8 (MessageSwitch) id 1378334304463134_11036; Wed, 4 Sep 2013 22:38:24 +0000 (UTC) Received: from DB8EHSMHS032.bigfish.com (unknown [10.174.8.228]) by mail76-db8.bigfish.com (Postfix) with ESMTP id 62C2CB40041; Wed, 4 Sep 2013 22:38:24 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS032.bigfish.com (10.174.4.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 22:38:23 +0000 Received: from BL2PR05MB083.namprd05.prod.outlook.com (10.255.232.26) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 4 Sep 2013 22:38:19 +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.745.25; Wed, 4 Sep 2013 22:38:18 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 22:38:17 +0000 From: Ken Gray To: Lucy yong , "Jim Guichard (jguichar)" , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtggAAOrPCAABiugP//8GhQ///FkQA= Date: Wed, 4 Sep 2013 22:38:17 +0000 Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452B30B3@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 095972DF2F Content-Type: multipart/alternative; boundary="_000_CE4D2BB216AE14kgrayjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 22:38:35 -0000 --_000_CE4D2BB216AE14kgrayjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Please, count me out of "not many people". For the members of "not many people", help save us a year of introspection = and please see the huge amount of use case and best practice gorge in ETSI= documentation or mailing lists, regurgitation in IEEE special work groups = and ONF special work groups, numerous articles restating the position paper= s therein. All easily accessible by using Google, Bing or other engines to= search for "NFV". This may appear sarcastic, but =85 really, it's not int= ended to be overly so (I think "tired of hearing this" is more appropriate)= =85you will be amazed at what has already been writ, spoken and debated in= the name of Service Chaining and Service Virtualization. From: Lucy yong > Date: Wed, 4 Sep 2013 22:12:03 +0000 To: "Jim Guichard (jguichar)" >, Linda Dunbar >,= "nsc@ietf.org" > Subject: Re: [nsc] NSC Working Group Charter Proposal Not many people well understand the problem and use case yet. The bof in IE= TF87 does not convey the issues clearly. So the first charter should solve = that first before to work on the solution. The work items listed in the cha= rter do not indicate has the order. The time table clear indicates they wil= l be worked at the same time. I agree that we should standardize one data = plane solution, but don=92t think the schedule is proper. Lucy From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Wednesday, September 04, 2013 5:03 PM To: Lucy yong; Linda Dunbar; nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal I disagree, this working group must be focused on solutions and not pontifi= cation over terminology or a laundry list of use cases. Having said that yo= u will note in the milestones that the problem statement and requirements a= re the first work items to be delivered followed by the data plane that wil= l support both. It is perfectly acceptable to provide a planned outline of = the WG activities and this is reflected in the charter. From: Lucy yong > Date: Wednesday, September 4, 2013 5:38 PM To: Linda Dunbar >,= Microsoft Office User >, "ns= c@ietf.org" > Subject: Re: [nsc] NSC Working Group Charter Proposal The first charter should focus on the problem statement, architecture, use = case, and requirement; Not on specifying one solution. Therefore, work ite= m #3 should not be in the first charter. Lucy From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, September 04, 2013 3:45 PM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal One clarification on Work Item #3: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. Is it really =93A single encapsulation=94? The encapsulation should depend on the underlay networks. Underlay network = could be IP based, MPLS based, or Ethernet based. Linda From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, September 03, 2013 11:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG _______________________________________________ nsc mailing list nsc@ietf.o= rg https://www.ietf.org/mailman/listinfo/nsc --_000_CE4D2BB216AE14kgrayjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Please, count me out of "not many people".   

For the members of "not many people", help save us a year of= introspection and please see the huge amount of use case  and best pr= actice gorge in ETSI documentation or mailing lists, regurgitation in IEEE = special work groups and ONF special work groups, numerous articles restating the position papers therein.  All easily = accessible by using Google, Bing or other engines to search for "NFV&q= uot;.  This may appear sarcastic, but =85 really, it's not intended to= be overly so (I think "tired of hearing this" is more appropriate) =85you will be amazed at what has already been writ, spoken a= nd debated in the name of Service Chaining and Service Virtualization.

From: Lucy yong <lucy.yong@huawei.com>
Date: Wed, 4 Sep 2013 22:12:03 += ;0000
To: "Jim Guichard (jguichar)&q= uot; <jguichar@cisco.com>, = Linda Dunbar <linda.dunbar@hu= awei.com>, "nsc@ietf.org&qu= ot; <nsc@ietf.org>
Subject: Re: [nsc] NSC Working Grou= p Charter Proposal

Not many people well understand th= e problem and use case yet. The bof in IETF87 does not convey the issues cl= early. So the first charter should solve that first before to work on the solution. The work items listed in the ch= arter do not indicate has the order. The time table clear indicates they wi= ll be worked at the same time.  I agree that we should standardize one= data plane solution, but don=92t think the schedule is proper.

 

Lucy

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Wednesday, September 04, 2013 5:03 PM
To: Lucy yong; Linda Dunbar; nsc@iet= f.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

I disagree, this working group must be focused on solutions and not pontification over terminology or a laundr= y list of use cases. Having said that you will note = in the milestones that the problem statement and requirements are the first work items to be delivered fol= lowed by the data plane that will support both. It is perfectly ac= ceptable to provide a planned outline of the WG activities and this is refl= ected in the charter. 

 

From: Lucy yong <luc= y.yong@huawei.com>
Date: Wednesday, September 4, 2013 5:38 PM
To: Linda Dunbar <lind= a.dunbar@huawei.com>, Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@iet= f.org>
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

The first charter should focus on = the problem statement, architecture, use case, and requirement;  Not o= n specifying one solution. Therefore, work item #3 should not be in the first charter.

 

Lucy

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 3:45 PM
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 =

One clarification on Work Item #3:=

3) Service Cha= ining Data Plane: this document will describe on the wire data plane encaps= ulation in support of (2). A single encapsulation will be selected in order to enable interoperability of data plane compone= nts.

 

Is it really =93A single encapsula= tion=94?

The encapsulation should depend on= the underlay networks. Underlay network could be IP based, MPLS based, or = Ethernet based.  =

 

Linda

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, September 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal

 =

Greetings,

 

As we look forward to the formation of a wor= king group that will focus on network service chaining, I would like to pro= pose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area= AD's. The following is a first draft of the charter and I invite you to ac= tively participate and provide inputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion and deployment te= chniques have not evolved to meet modern network architectures and do not r= eflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks,= servers, storage, and applications, have all undergone significant change = in recent years: virtualization, network overlays, and orchestration are in= creasingly the norm. All of these have profound effects on network and services design.

 

Today, deploying new services, or making cha= nges to existing services, often requires network topology changes. Adding = and removing service functions is a complex, risky task, that is tied to operationalizing topological changes = leading to mostly-static service definitions. New service insertion and dep= loyment techniques must enable the concept of service functions as shared r= esources, and enable the linkage of these resources using service chains that represent the abstracted view= of the required service functions, and define the order in which they shou= ld be applied. When a service chain is instantiated in a network, specific = instances of service functions are selected, and a service topology is created and used for forwarding packet= s through the service chain.<= /span>

 

A basic service chain might simply utilize a= n existing overlay technology to force traffic through the necessary servic= e functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chaining (NSC) working g= roup focuses on new approaches to service insertion and deployment, providi= ng a framework for the construction of services built using service chains. The WG focuses on the necessary pr= otocols for the creation of service chains, and the passing of metadata fro= m the network to service functions, and between service functions. When pos= sible, the WG will extend existing protocols to provide service chaining functionality, and any protocol exte= nsions will be reviewed by both the Network Service Chaining WG and by the = WG responsible for the protocol being extended.  

 

Specifically, the Network Service Chaining W= G is chartered to deliver the following work items: 

 

1) Problem Statement: this document will pro= vide a summary of the problem space to be addressed by the Network Service = Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclatur= e and definitions for Network Service Chaining.

 

2) System Architecture: this set of document= s will provide a description of the architecture building blocks and their = relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Plane: this documen= t will describe on the wire data plane encapsulation in support of (2). &nb= sp;A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this document will address= service chaining operation, monitoring and troubleshooting including relev= ant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they ar= e realized.

 

Proposed Milestones:

 

Dec 2013 Request publication of an Informati= onal document defining the Network Service Chaining problem statement to th= e IESG

 

Mar 2014 Request publication of informationa= l documents defining the system architecture including protocol requirement= s and framework to the IESG

 

May 2014 Request publication of a Standards = Track document specifying the data-plane (including metadata) for Service C= haining to IESG

 

May 2014 Request publication of an informati= onal document specifying Service Chaining Control Plane requirements to IES= G

 

Dec 2014 Request publication of informationa= l documents defining Service Chaining manageability requirements including = MIBs, OAM, and information models to IESG 

 

 

_______________________________________________ nsc mailing list nsc@ietf.org http= s://www.ietf.org/mailman/listinfo/nsc --_000_CE4D2BB216AE14kgrayjunipernet_-- From kgray@juniper.net Wed Sep 4 15:46:30 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FF921F9F6F for ; Wed, 4 Sep 2013 15:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 Z73RVwaG6l93 for ; Wed, 4 Sep 2013 15:46:24 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 46CA321F9F7F for ; Wed, 4 Sep 2013 15:46:23 -0700 (PDT) Received: from mail139-db9-R.bigfish.com (10.174.16.227) by DB9EHSOBE011.bigfish.com (10.174.14.74) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 22:46:22 +0000 Received: from mail139-db9 (localhost [127.0.0.1]) by mail139-db9-R.bigfish.com (Postfix) with ESMTP id 47A354A0206; Wed, 4 Sep 2013 22:46:22 +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(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail139-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:(479174003)(377454003)(51704005)(24454002)(13464003)(189002)(199002)(80976001)(79102001)(76786001)(76796001)(77096001)(83506001)(56816003)(46102001)(74366001)(63696002)(36756003)(76176001)(80022001)(47976001)(47736001)(59766001)(77982001)(54356001)(31966008)(65816001)(81542001)(56776001)(50986001)(74662001)(51856001)(15975445006)(54316002)(81342001)(47446002)(76482001)(74502001)(69226001)(81686001)(83072001)(74706001)(74876001)(19580405001)(4396001)(49866001)(53806001)(19580395003)(83322001)(81816001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB083; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail139-db9 (localhost.localdomain [127.0.0.1]) by mail139-db9 (MessageSwitch) id 1378334779691219_8502; Wed, 4 Sep 2013 22:46:19 +0000 (UTC) Received: from DB9EHSMHS008.bigfish.com (unknown [10.174.16.248]) by mail139-db9.bigfish.com (Postfix) with ESMTP id 992D76007E; Wed, 4 Sep 2013 22:46:19 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS008.bigfish.com (10.174.14.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 22:46:19 +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.353.4; Wed, 4 Sep 2013 22:46:06 +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.745.25; Wed, 4 Sep 2013 22:46:05 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 22:46:05 +0000 From: Ken Gray To: Thomas Nadeau , Linda Dunbar Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqOMZHv0zVYXZE0SHEZHP0mGkNJm0jqkAgAAGpACAAAH1gIAAAJuAgAAFo4CAACDVAIABBEuA///a5gCAAE//gIAAEZOA///tH4A= Date: Wed, 4 Sep 2013 22:46:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 095972DF2F 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: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Thomas Narten , Ron Parker , "adrian@olddog.co.uk" , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 22:46:32 -0000 To add - and that programmability can be policy driven thereby eliminating a lot of the superficial distinctions being made based on the present-day behaviors of service devices like DPI engines and routers/switches - solely because the latter learn and program their forwarding "dynamically" and the former by the hand of a policy engine. =3D8^) On 9/4/13 3:53 PM, "Thomas Nadeau" wrote: > > I2RS is not chartered to do service-chaining explicitly, especially any >data plane changes that might be needed; its chartered to do fast >programmability and topology. > > --Tom > >> Ken,=20 >>=20 >> You brought up a very good point, about I2RS. >>=20 >> I see I2RS as a mechanism to chain L3 service modules. If NSC also >>covers the L3 service function chaining, are the use cases similar to >>I2RS' use cases? Or different? >>=20 >> Linda >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Ken Gray [mailto:kgray@juniper.net] >>> Sent: Wednesday, September 04, 2013 1:04 PM >>> To: Linda Dunbar; Ron Parker; Thomas Nadeau >>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant (stbryant); >>> adrian@olddog.co.uk; Thomas Narten >>> Subject: Re: [nsc] NSC BoF Outcomes >>>=20 >>> In line ... >>>=20 >>> On 9/4/13 12:17 PM, "Linda Dunbar" wrote: >>>=20 >>>> Ron, >>>>=20 >>>> My comments are inserted below: >>>>> -----Original Message----- >>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>> Sent: Tuesday, September 03, 2013 7:46 PM >>>>> To: Linda Dunbar; Thomas Nadeau >>>>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; >>>>> adrian@olddog.co.uk; Stewart Bryant (stbryant) >>>>> Subject: RE: [nsc] NSC BoF Outcomes >>>>>=20 >>>>> Hi, Linda. >>>>>=20 >>>>> With respect to: >>>>>=20 >>>>> - Layer 4 to Layer 7 service functions (or service nodes) are to >>>>> apply actions to data packets traversing through. They don't impact >>>>> overall network topologies/routes/restorations. >>>>>=20 >>>>> Layer 4-7 services can, indeed, impact routing decisions. For >>> example, >>>>> if the service is DPI analysis, then a detected protocol may cause >>> the >>>>> subsequent packets to be policy routed on a path different than the >>> SPF >>>>> path. >>>>=20 >>>> [Linda] Do you call this "DPI" function that re-direct data frames to >>> a >>>> different target (that is not the Destination of the data frame) >>> "Layer >>>> 3" service? >>>> When those "DPI" functions re-direct traffic, do they add another >>>> Destination address to the data frames (i.e. create a tunnel)? Or do >>> they >>>> not touch the destination addresses in the existing data frames and >>>> expect all the nodes along the way to know how to forward the data >>> frames? >>>=20 >>> I fail to see the point of the question. >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Bottom line, those services need to be distinguished from traditional >>>> Layer 3 services, and be distinguished from routers/switches that >>>> dynamically establish topology, establish routes, and restoration >>> paths. >>>=20 >>> Disagree. Bump-in-the-wire - to me, that's what this ALL >>> is ...you >>> are making a distinction that is very temporary and (IMO) unnecessary. >>> What you describe as something "dynamically establish topology" is >>> morphing (heck, with the help of I2RS - sooner rather than later) to >>> some >>> different definition of dynamic than we have today. Bump-in-wire. >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Linda >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Ron >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>> Of >>>>> Linda Dunbar >>>>> Sent: Tuesday, September 03, 2013 6:48 PM >>>>> To: Thomas Nadeau >>>>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten; >>>>> adrian@olddog.co.uk; Stewart Bryant (stbryant) >>>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>>=20 >>>>> Here are some of the reasons that chaining of Layer 2 and 3 service >>>>> functions are different from chaining of Layer 4 to 7 service >>> functions >>>>> (I will add more later): >>>>>=20 >>>>>=20 >>>>> - Layer 4 to Layer 7 service functions (or service nodes) are to >>> apply >>>>> actions to data packets traversing through. They don't impact >>> overall >>>>> network topologies/routes/restorations. >>>>>=20 >>>>> - Layer 4-7 service functions drop, pass, consume, re-initiate >>> packets, >>>>> etc. They don't change network topologies, and they don't impact >>>>> network restoration scheme (e.g. fast re-route). When you move a >>> Layer >>>>> 4 service module from Location A to B, the Layer 2/3 topology is not >>>>> changed, routes/restoration are not changed. >>>>>=20 >>>>> - When chaining Layer 4 to Layer 7 service functions together, like >>> S1- >>>>>> S2->S3->S4, they are overlaying over the underlay network. >>>>>=20 >>>>> - Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to >>>>> dynamically discover topology; forwarding paths; protection paths; >>>>> restoration paths, etc. Today, all routers are connected together by >>>>> links. Their topology is more like a meshed graph than chain. So >>> when >>>>> you chain Router-1<->Router-2<->Router-3, are you talking about >>> source >>>>> routing? Therefore, need a clear definition on what does it really >>> mean >>>>> by chaining Layer 2/3 service nodes. >>>>>=20 >>>>> Linda >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>>> Sent: Tuesday, September 03, 2013 5:28 PM >>>>>> To: Linda Dunbar >>>>>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Stewart Bryant >>> (stbryant); >>>>>> Thomas Narten; adrian@olddog.co.uk >>>>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>>>=20 >>>>>>=20 >>>>>> On Sep 3, 2013:6:25 PM, at 6:25 PM, Linda Dunbar >>>>>> wrote: >>>>>>=20 >>>>>>> Thomas, >>>>>>>=20 >>>>>>> Are you saying that the NSC scope includes chaining Layer 2, >>> Layer >>>>> 3 >>>>>> service functions, Layer 4 to Layer 7 service functions, and >>> various >>>>>> combination of them? >>>>>>=20 >>>>>> I don't define the scope; thats up to the ADs. >>>>>>=20 >>>>>> Could you please answer the question below? >>>>>>=20 >>>>>> --Tom >>>>>>=20 >>>>>>>=20 >>>>>>> Linda >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>>>>> Sent: Tuesday, September 03, 2013 5:19 PM >>>>>>>> To: Linda Dunbar >>>>>>>> Cc: Jim Guichard (jguichar); adrian@olddog.co.uk; nsc@ietf.org; >>>>>>>> Thomas Narten; Stewart Bryant (stbryant) >>>>>>>> Subject: Re: [nsc] NSC BoF Outcomes >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 3, 2013:5:54 PM, at 5:54 PM, Linda Dunbar >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> My comments are inserted below marked by [Linda]: >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> However, it was less clear to me that there is agreement >>> about >>>>>> the >>>>>>>>>> layer >>>>>>>>>>> in >>>>>>>>>>> which service chaining has to be solved. I felt that some >>>>> people >>>>>>>>>>> were talking about service chaining in the application layer, >>>>>> some >>>>>>>>>>> about service chaining based on flows, and some about per- >>>>> packet >>>>>>>>>>> services. The solutions are, >>>>>>>>>> I >>>>>>>>>>> think, >>>>>>>>>>> likely to be very different for the different problems, and >>> it >>>>>>>> would >>>>>>>>>> be >>>>>>>>>>> wrong to >>>>>>>>>>> try to bunch them all together. >>>>>>>>>>=20 >>>>>>>>>> Jim> although there was certainly initial confusion I believe >>>>>>>>>> Jim> this >>>>>>>> is >>>>>>>>>> becoming less and less so as we socialize the basic idea of >>>>>> service >>>>>>>>>> chaining; indeed, as we move forward we will reflect a more >>>>>>>>>> common understanding within the problem statement. >>>>>>>>>=20 >>>>>>>>> It is still not clear which layer service functions are >>> chained >>>>>>>> together. The draft-quinn-nsc-problem-statement-03 discussed >>>>>> chaining >>>>>>>> of service functions that can be a network or application based >>>>>>>> packet treatment,..., to enable a service offered by a network >>>>>> operators. >>>>>>>>=20 >>>>>>>> Why do you think that matters? >>>>>>>>=20 >>>>>>>>> Today, there are many services offered by operators, e.g. >>> L2VPN, >>>>>>>>> L3VPN, P2P paths, etc. So you can interpret NSC as chaining >>> L2/L3 >>>>>>>> service functions (like proxy forwarding, or fragmentation, >>> etc.); >>>>>>>> You can also interpret NSC as chaining L4 (and above) service >>>>>>>> functions; or chaining of mixed L4-L7 service functions (i.e. >>> with >>>>>>>> some service nodes consuming packets and reinitiate new >>> packets). >>>>>>>>=20 >>>>>>>> You can, and people actually do implement this today. >>>>>>>>=20 >>>>>>>>> Is NSC including all chaining of all those services? >>>>>>>>>=20 >>>>>>>>> Layer 2/3 service function chaining might require different >>>>>>>>> schemes >>>>>>>> than Layer 4-7 service chaining. Therefore, it is more >>> effective >>>>> to >>>>>>>> define them separately to make the discussion more focused. >>>>>>>>=20 >>>>>>>> I do not think so. I'd prefer to not make this only as >>>>>> complicated >>>>>>>> as it needs to be, and no more. There are implementations of >>> Layer >>>>>>>> 2 and 3 chaining that are all done with the same >>>>> encap/provisioning >>>>>>>> systems. >>>>>>>>=20 >>>>>>>> --Tom >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Linda Dunbar >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> nsc mailing list >>>>>>>>>> nsc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>> _______________________________________________ >>>>>>>>> nsc mailing list >>>>>>>>> nsc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 > From melinda.shore@gmail.com Wed Sep 4 17:25: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 A7A4811E8214 for ; Wed, 4 Sep 2013 17:25:30 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdlLOAL+5Bqe for ; Wed, 4 Sep 2013 17:25:30 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5114A21F9F51 for ; Wed, 4 Sep 2013 17:25:29 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp13so1147396pab.35 for ; Wed, 04 Sep 2013 17:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9zdLO7PjI+bmKfq93vQlPpJirzUo+zS38y70a+3FX9I=; b=hnLk6T+g2oggh6BNkIgcc9eRVlFITVW73OXMD97B59bbU+vTYj4WfZAhjk1mNUKUjJ OK8qtlrBRpl0mG9CYvE6racXHCGHbOnyvsJtgk1+7BwPDpVbwXgvUTgPKJUaXQYWVOJk yMbO7aDqYnyJPS0yc7Okp25baWsDANm0hOV7YhyXGutkf1kbQ8k6SSXCQnuVqvNqqIfU b2SSPt29kKQsVsRfLK7utg4VYdV0In/1ItW++QkthMWRPhc0hbEPkbYgwVD6gpTWUcMI gd/JREan3cHFT+bCh5QioCEEpbIWKOvcC3e0wJSlqm3OeU94dXcKrYkfS/1O7/TyL14p 0lQA== X-Received: by 10.68.220.1 with SMTP id ps1mr6149514pbc.30.1378340728327; Wed, 04 Sep 2013 17:25:28 -0700 (PDT) Received: from spandex.local (216-67-47-26-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.47.26]) by mx.google.com with ESMTPSA id fk4sm33666352pab.23.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Sep 2013 17:25:27 -0700 (PDT) Message-ID: <5227CF75.6040200@gmail.com> Date: Wed, 04 Sep 2013 16:25:25 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: nsc@ietf.org References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9D4FB@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645B9D56D@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9D56D@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 00:25:30 -0000 On 9/4/13 1:36 PM, Linda Dunbar wrote: > IMO, “single encapsulation” is too limiting. Many of today’s service > provider networks are MPLS based. In addition, there are even Ethernet > based networks (if you venture into IEEE802 or CEF). I think this would be an extraordinary mistake, in the absence of a clear, explicit need. That is to say, somebody needs to explain, with SPECIFICS, why a particular encapsulation is not going to work on a given network. Just because someone's using MPLS for transport doesn't mean that a TCP, UDP, IP, SCTP, or whateverP won't be useful and won't work. This should be no more complicated than necessary. Melinda From tnadeau@lucidvision.com Wed Sep 4 17:45:34 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 6CCE311E821A for ; Wed, 4 Sep 2013 17:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 XQbFCHE4hfg3 for ; Wed, 4 Sep 2013 17:45:29 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 73EF111E8217 for ; Wed, 4 Sep 2013 17:45:18 -0700 (PDT) Received: from [10.125.2.236] (mobile-198-228-196-059.mycingular.net [198.228.196.59]) by lucidvision.com (Postfix) with ESMTP id 174A9255AFE1; Wed, 4 Sep 2013 20:45:17 -0400 (EDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-9E7118D8-280B-4DD3-81C8-5B551A7251AC Content-Transfer-Encoding: 7bit Message-Id: <3D05DF44-87DD-4DB3-B8EA-571473CAEF2B@lucidvision.com> X-Mailer: iPhone Mail (10B350) From: "Thomas D. Nadeau" Date: Wed, 4 Sep 2013 20:45:14 -0400 To: Ken Gray Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Lucy yong , Linda Dunbar Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 00:45:35 -0000 --Apple-Mail-9E7118D8-280B-4DD3-81C8-5B551A7251AC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm with Ken in this one. I was just baffled about that comment. As I said e= arlier, there are real working examples of NFV for sale //now//. one goal i= s to definitely help them work together rather than trying to have them look= like some theoretical thing. Tom=20 Von meinem iPhone gesendet On Sep 4, 2013, at 6:38 PM, Ken Gray wrote: > Please, count me out of "not many people". =20 >=20 > For the members of "not many people", help save us a year of introspection= and please see the huge amount of use case and best practice gorge in ETSI= documentation or mailing lists, regurgitation in IEEE special work groups a= nd ONF special work groups, numerous articles restating the position papers t= herein. All easily accessible by using Google, Bing or other engines to sea= rch for "NFV". This may appear sarcastic, but =E2=80=A6 really, it's not in= tended to be overly so (I think "tired of hearing this" is more appropriate)= =E2=80=A6you will be amazed at what has already been writ, spoken and debat= ed in the name of Service Chaining and Service Virtualization. >=20 > From: Lucy yong > Date: Wed, 4 Sep 2013 22:12:03 +0000 > To: "Jim Guichard (jguichar)" , Linda Dunbar , "nsc@ietf.org" > Subject: Re: [nsc] NSC Working Group Charter Proposal >=20 > Not many people well understand the problem and use case yet. The bof in I= ETF87 does not convey the issues clearly. So the first charter should solve t= hat first before to work on the solution. The work items listed in the chart= er do not indicate has the order. The time table clear indicates they will b= e worked at the same time. I agree that we should standardize one data plan= e solution, but don=E2=80=99t think the schedule is proper. > =20 > Lucy > =20 > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 > Sent: Wednesday, September 04, 2013 5:03 PM > To: Lucy yong; Linda Dunbar; nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal > =20 > I disagree, this working group must be focused on solutions and not pontif= ication over terminology or a laundry list of use cases. Having said that yo= u will note in the milestones that the problem statement and requirements ar= e the first work items to be delivered followed by the data plane that will s= upport both. It is perfectly acceptable to provide a planned outline of the W= G activities and this is reflected in the charter.=20 > =20 > From: Lucy yong > Date: Wednesday, September 4, 2013 5:38 PM > To: Linda Dunbar , Microsoft Office User , "nsc@ietf.org" > Subject: Re: [nsc] NSC Working Group Charter Proposal > =20 > The first charter should focus on the problem statement, architecture, use= case, and requirement; Not on specifying one solution. Therefore, work ite= m #3 should not be in the first charter. > =20 > Lucy > =20 > From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda= Dunbar > Sent: Wednesday, September 04, 2013 3:45 PM > To: Jim Guichard (jguichar); nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal > =20 > One clarification on Work Item #3: > 3) Service Chaining Data Plane: this document will describe on the wire da= ta plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. > =20 > Is it really =E2=80=9CA single encapsulation=E2=80=9D? > The encapsulation should depend on the underlay networks. Underlay network= could be IP based, MPLS based, or Ethernet based. =20 > =20 > Linda > =20 > From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) > Sent: Tuesday, September 03, 2013 11:01 AM > To: nsc@ietf.org > Subject: [nsc] NSC Working Group Charter Proposal > =20 > Greetings, > =20 > As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias t= o try and reach consensus on an initial charter as requested by the routing a= rea AD's. The following is a first draft of the charter and I invite you to a= ctively participate and provide inputs into this process. > =20 > Proposed NSC WG Charter > =20 > Existing service insertion and deployment techniques have not evolved to m= eet modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Netw= orks, servers, storage, and applications, have all undergone significant cha= nge in recent years: virtualization, network overlays, and orchestration are= increasingly the norm. All of these have profound effects on network and se= rvices design. > =20 > Today, deploying new services, or making changes to existing services, oft= en requires network topology changes. Adding and removing service functions i= s a complex, risky task, that is tied to operationalizing topological change= s leading to mostly-static service definitions. New service insertion and de= ployment techniques must enable the concept of service functions as shared r= esources, and enable the linkage of these resources using service chains tha= t represent the abstracted view of the required service functions, and defin= e the order in which they should be applied. When a service chain is instant= iated in a network, specific instances of service functions are selected, an= d a service topology is created and used for forwarding packets through the s= ervice chain. > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc --Apple-Mail-9E7118D8-280B-4DD3-81C8-5B551A7251AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'm with Ken in this one. I was just b= affled about that comment. As I said earlier, there are real working example= s of NFV for sale //now//.  one goal is to definitely help them work to= gether rather than trying to have them look like some theoretical thing.

Tom 


Von meinem iPho= ne gesendet

On Sep 4, 2013, at 6:38 PM, Ken Gray <kgray@juniper.net> wrote:

Please, count me out of "not many people".   

For the members of "not many people", help save us a year of introspect= ion and please see the huge amount of use case  and best practice gorge= in ETSI documentation or mailing lists, regurgitation in IEEE special work g= roups and ONF special work groups, numerous articles restating the position papers therein.  All easily a= ccessible by using Google, Bing or other engines to search for "NFV".  = This may appear sarcastic, but =E2=80=A6 really, it's not intended to be ove= rly so (I think "tired of hearing this" is more appropriate) =E2=80=A6you will be amazed at what has already been writ, spo= ken and debated in the name of Service Chaining and Service Virtualization.<= /div>

From: Lucy yong <lucy.yong@huawei.com>
Date: Wed, 4 Sep 2013 22:12:03 +0000=
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, Linda Dunbar= <linda.dunbar@huawei.com&= gt;, "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] NSC Working Group= Charter Proposal

Not many people well understand the p= roblem and use case yet. The bof in IETF87 does not convey the issues clearl= y. So the first charter should solve that first before to work on the solution. The work items listed in the cha= rter do not indicate has the order. The time table clear indicates they will= be worked at the same time.  I agree that we should standardize one da= ta plane solution, but don=E2=80=99t think the schedule is proper.

 

Lucy

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Wednesday, September 04, 2013 5:03 PM
To: Lucy yong; Linda Dunbar; nsc@ietf= .org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

I disagree, this working group must be focused on solutions and not pontification over terminology or a laundry= list of use cases. Having said that you will note in t= he milestones that the problem statement and requirements are the first work items to be delivered foll= owed by the data plane that will support both. It is perfectly acce= ptable to provide a planned outline of the WG activities and this is reflect= ed in the charter. 

 

From: Lucy yong <lucy.= yong@huawei.com>
Date: Wednesday, September 4, 2013 5:38 PM
To: Linda Dunbar <linda= .dunbar@huawei.com>, Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org><= br> Subject: Re: [nsc] NSC Working Group Charter Proposal

 

The first charter should focus on th= e problem statement, architecture, use case, and requirement;  Not on s= pecifying one solution. Therefore, work item #3 should not be in the first charter.

 

Lucy

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] <= b>On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 3:45 PM
To: Jim Guichard (jguichar); nsc@ietf= .org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 <= /p>

One clarification on Work Item #3:

3) Service Chain= ing Data Plane: this document will describe on the wire data plane encapsula= tion in support of (2). A single encapsulation will be selected in order to enable interoperability of data plane componen= ts.

 

Is it really =E2=80=9CA single encap= sulation=E2=80=9D?

The encapsulation should depend on t= he underlay networks. Underlay network could be IP based, MPLS based, or Eth= ernet based.  

=

 

Linda

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] <= b>On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, September 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal

 <= /p>

Greetings,<= o:p>

 =

As we look forward to the formation of a worki= ng group that will focus on network service chaining, I would like to propos= e a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area A= D's. The following is a first draft of the charter and I invite you to activ= ely participate and provide inputs into this process.

 =

Proposed NSC WG Charter

 =

Existing service insertion and deployment tech= niques have not evolved to meet modern network architectures and do not refl= ect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, s= ervers, storage, and applications, have all undergone significant change in r= ecent years: virtualization, network overlays, and orchestration are increas= ingly the norm. All of these have profound effects on network and services design.

 =

Today, deploying new services, or making chang= es to existing services, often requires network topology changes. Adding and= removing service functions is a complex, risky task, that is tied to operationalizing topological changes l= eading to mostly-static service definitions. New service insertion and deplo= yment techniques must enable the concept of service functions as shared reso= urces, and enable the linkage of these resources using service chains that represent the abstracted view o= f the required service functions, and define the order in which they should b= e applied. When a service chain is instantiated in a network, specific insta= nces of service functions are selected, and a service topology is created and used for forwarding packets= through the service chain.

_________________________________________= ______
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc<= br>
= --Apple-Mail-9E7118D8-280B-4DD3-81C8-5B551A7251AC-- From jiangyuanlong@huawei.com Wed Sep 4 20: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 265AC11E8204 for ; Wed, 4 Sep 2013 20:41:47 -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.000, 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 rMczTqS8iIgF for ; Wed, 4 Sep 2013 20:41:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 97B1F11E8255 for ; Wed, 4 Sep 2013 20:41:39 -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.5-GA FastPath queued) with ESMTP id AVB36119; Thu, 05 Sep 2013 03:41:37 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 04:41:17 +0100 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 04:41:34 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.127]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0146.000; Thu, 5 Sep 2013 11:41:23 +0800 From: Jiangyuanlong To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2WnuQ Date: Thu, 5 Sep 2013 03:41:22 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9@szxema506-mbs.china.huawei.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F672511@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_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 03:41:47 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9szxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, Thanks for the hard work on drafting the charter. In the proposed NSC charter, it says: "4) Manageability: this document will address service chaining operation, m= onitoring and troubleshooting including relevant service chaining models su= ch as MIBs or YANG modules, along with relevant OAM capabilities and how th= ey are realized." Firstly, the relation of "operation, monitoring and troubleshooting" and "O= AM" is not very clear to me. Secondly, though YANG module is a good piece of work, I don't think it shou= ld be put in the list of NSC deliverables, since YANG related specification= used to belong to OPS area. We can transfer it to OPS (after information m= odels are mature enough) and the expertise should be readily found there. I would like to propose the following texts: 4) Manageability: this document will address service chaining management in= cluding relevant service chaining MIBs and information models, and service = chaining OAM. Splitting OAM into a separate item seems another option as it mainly solves= traceability of service chaining. Finally, the proposed timeline is not very practical IMHO (plus one year f= or each item in the Milestone?). Regards, Yuanlong From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Wednesday, September 04, 2013 12:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9szxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,=

 <= /o:p>

Thanks for t= he hard work on drafting the charter.

 <= /o:p>

In the propo= sed NSC charter, it says:

 <= /o:p>

“4) Ma= nageability: this document will address service chaining operation, monitor= ing and troubleshooting including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how= they are realized.”

 <= /o:p>

Firstly, the= relation of “operation, monitoring and troubleshooting” and &#= 8220;OAM” is not very clear to me.

 <= /o:p>

Secondly, th= ough YANG module is a good piece of work, I don’t think it should be = put in the list of NSC deliverables, since YANG related specification used to belong to OPS area. We can transfer it to OPS (after information m= odels are mature enough) and the expertise should be readily found there. &= nbsp;

 <= /o:p>

I would like= to propose the following texts:

 <= /o:p>

4) Manageabi= lity: this document will address service chaining management including rele= vant service chaining MIBs and information models, and service chaining OAM.

 <= /o:p>

Splitting OA= M into a separate item seems another option as it mainly solves traceabilit= y of service chaining.

 <= /o:p>

Finally, &nb= sp;the proposed timeline is not very practical IMHO (plus one year for each= item in the Milestone?).

 <= /o:p>

Regards,

Yuanlong

 = ;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, September 04, 2013 12:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal<= /p>

 

Greetings,

 <= /o:p>

As we look f= orward to the formation of a working group that will focus on network servi= ce chaining, I would like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the= routing area AD's. The following is a first draft of the charter and I inv= ite you to actively participate and provide inputs into this process.<= /o:p>

 <= /o:p>

Proposed = NSC WG Charter

 <= /o:p>

Existing ser= vice insertion and deployment techniques have not evolved to meet modern ne= twork architectures and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks,= servers, storage, and applications, have all undergone significant change = in recent years: virtualization, network overlays, and orchestration are in= creasingly the norm. All of these have profound effects on network and services design.

 <= /o:p>

Today, deplo= ying new services, or making changes to existing services, often requires n= etwork topology changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological cha= nges leading to mostly-static service definitions. New service insertion an= d deployment techniques must enable the concept of service functions as sha= red resources, and enable the linkage of these resources using service chains that represent the abstracted view= of the required service functions, and define the order in which they shou= ld be applied. When a service chain is instantiated in a network, specific = instances of service functions are selected, and a service topology is created and used for forwarding packet= s through the service chain.

 <= /o:p>

A basic serv= ice chain might simply utilize an existing overlay technology to force traf= fic through the necessary service functions. However, additional information enables a richer service chain for more advanced composite ser= vices. For example, shared information (e.g., the result of classification)= can be used to offload service function processing or inform other service= functions about information that would otherwise be hard to glean. 

 <= /o:p>

The Network = Service Chaining (NSC) working group focuses on new approaches to service i= nsertion and deployment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary pr= otocols for the creation of service chains, and the passing of metadata fro= m the network to service functions, and between service functions. When pos= sible, the WG will extend existing protocols to provide service chaining functionality, and any protocol exte= nsions will be reviewed by both the Network Service Chaining WG and by the = WG responsible for the protocol being extended.  

 <= /o:p>

Specifically= , the Network Service Chaining WG is chartered to deliver the following wor= k items: 

 <= /o:p>

1) Problem S= tatement: this document will provide a summary of the problem space to be a= ddressed by the Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomencl= ature and definitions for Network Service Chaining.

 <= /o:p>

2) System Ar= chitecture: this set of documents will provide a description of the archite= cture building blocks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 <= /o:p>

3) Service C= haining Data Plane: this document will describe on the wire data plane enca= psulation in support of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.<= o:p>

 <= /o:p>

4) Manageabi= lity: this document will address service chaining operation, monitoring and= troubleshooting including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how= they are realized.

 <= /o:p>

Proposed Mil= estones:

 <= /o:p>

Dec 2013 Req= uest publication of an Informational document defining the Network Service = Chaining problem statement to the IESG

 <= /o:p>

Mar 2014 Req= uest publication of informational documents defining the system architectur= e including protocol requirements and framework to the IESG

 <= /o:p>

May 2014 Req= uest publication of a Standards Track document specifying the data-plane (i= ncluding metadata) for Service Chaining to IESG

 <= /o:p>

May 2014 Req= uest publication of an informational document specifying Service Chaining C= ontrol Plane requirements to IESG

 <= /o:p>

Dec 2014 Req= uest publication of informational documents defining Service Chaining manag= eability requirements including MIBs, OAM, and information models to IESG 

 <= /o:p>

 <= /o:p>

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9szxema506mbschi_-- From mohamed.boucadair@orange.com Thu Sep 5 00:45: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 2BE1D21E80DF for ; Thu, 5 Sep 2013 00:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.010, 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 3aMLqIpc9fIv for ; Thu, 5 Sep 2013 00:45:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3C49121E80E5 for ; Thu, 5 Sep 2013 00:45:47 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id B964C3241F7; Thu, 5 Sep 2013 09:45:45 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8BD3635C079; Thu, 5 Sep 2013 09:45:45 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 5 Sep 2013 09:45:45 +0200 From: To: Ken Gray , "nsc@ietf.org" Date: Thu, 5 Sep 2013 09:45:44 +0200 Thread-Topic: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt Thread-Index: Ac6fMhIAzIOqddliRk+cqJ/CnVKw9ADv8zVgAZrASQAAKMd+4A== Message-ID: <94C682931C08B048B7A8645303FDC9F36EF03367C6@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EEEE4EC9B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.90030 Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.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, 05 Sep 2013 07:45:59 -0000 Hi Ken, Thank you for the comments. Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Ken Gray [mailto:kgray@juniper.net] >Envoy=E9=A0: mercredi 4 septembre 2013 16:53 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org >Objet=A0: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements- >01.txt > >Heya, Med. > >I gave it a quick read. I have the following questions/observations: > >REQ#2 - The document doesn't specifically say whether we're constraining >our focus on chains that require an "externality" for each link (that is, >ARE we assuming that each "link" will pass through a network/networked >element e.g. Hypervisor switch) - and are thus excluding from discussion >IPC (or RPC) mechanisms between service elements on the same device (which >are much harder to detect, monitor, standardize). [Med] IMHO how service functions are interconnected should be excluded from= the scope. This included both the case where multiple functions are co-loc= ated within the same device or are located in separate ones. I added this s= entence: "Note: Communications between Service Functions co-resident on same Network= Element are considered implementation-specific. These considerations are o= ut of scope of the SFC specification effort." > >REQ#13 is putting a constraint on the header discussion. Is this the >right place to put that, particularly since the requirements there haven't >been fully defined (yet)? [Med] This is mainly motivated by operational needs; the constraint on the = header is just a side effect. From an operational standpoint, this is an im= portant requirement to keep in mind. A typical complications that may arise= is when legacy nodes (no aware of the SFC procedure) discard fragmented pa= ckets. > >REQ#15 - while I fully appreciate your desire to avoid another 80+ part >email thread on whether MPLS is an overlay, I think you make your point >well enough in the main assertion and part "b" is actually redundant. 8^) [Med] I see your point. We initially listed those sub-bullets to provide ad= ditional information and make sure the main requirements is clear enough. W= ill consider how to make this better. Thanks. > >REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22 has >to be a MUST (I think the need for downstream reclassification can be a >normal outcome of the function of an individual service element as it >potentially transforms a header - unless your argument is that we should >avoid this wherever possible by imbedding a clue in the header - in which >case we run into issues with "non-speakers" or legacy devices). [Med] In the new version to be published, we removed REQ#19 (a) and maintai= ned the normative language in REQ#22 as it is. A simple model consists to h= ave one single SFC classification of the packet, and then the packet will b= e forwarding on a per SF Map Index. In such model, no SFC re-classification= would be required. Unlike this simple model, there are voices arguing a SF= C re-classification may be needed. We will have the opportunity to tweak th= e normative language.=20 > >REQ#23 seems to obviate the use of simple route NH manipulation to create >a chain (this is destination address based). So, to be inclusive, I think >that has to be a SHOULD. [Med] The destination address this REQ is referring to is the destination a= ddress of the original packet. We made this change to make: REQ#23: The solution MUST be able to forward the traffic between two Service Functions (involved in the same Service Function Chain) without relying on the original destination address in a data packet. Better? Or you still think this should be modified? Thanks.=20 > >REQ#25 seems to be difficult to require if you don't dictate how the chain >is formed (how the forwarding is instantiated) and should be worded more >like REQ#29, IMO. [Med] We changed the wording for this REQ to make it more specific. The new= wording to appear in the new version is as follow: REQ#25: The solution MUST allow for Operations, Administration, and Maintenance (OAM) features [RFC6291]. In particular, a. Support means to verify the completion of the forwarding actions derived from the contents of the SF Map until the Border Node is reached (see Section 3.4.1 of [RFC5706]). b. Support means to ensure coherent classification rules are installed to all SFC Classifiers. c. Support means to correlate between the classification policies and observed forwarding actions. d. Support in-band liveness and functionality checking of instantiated Service Function Chains. Better? > >REQ#30 I think you're trying to say that static definition/topology of >service functions SHOULD be supported but dynamic MUST (not that every >element has to support dynamic discovery but that the overall goal of the >ongoing architecture should be dynamic with static augmentation for >corner/legacy cases) ...which would be more in alignment with the tenor of >REQ#32. [Med] We used SHOULD in this REQ mainly because the solution can be enabled= in some contexts without requiring dynamic discovery means. Promoting this= REQ to "MUST" would assume this functionality is mandatory to deploy the c= haining solution...which is not true. > >Thanks for kicking it off and reading this drivel ... > > > > > > >On 8/27/13 2:58 AM, "mohamed.boucadair@orange.com" > wrote: > >>Dear all, >> >>A new version of the requirements draft is now available online. The main >>changes in this new version are as follows: >> >>* Enrich the document with inputs from >>draft-li-service-chaining-requirements >>* Welcome authors of draft-li-service-chaining-requirements as co-authors >>* Add new security-related requirements. >>* Re-order the requirements >> >>A more detailed diff is available at: >>http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirement= s-0 >>1.txt >> >>Feel free to share your comments, suggestions and text contributions on >>the list or direct them to the authors. >> >>Cheers, >>Med >> >>-----Message d'origine----- >>De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >>De la part de internet-drafts@ietf.org >>Envoy=E9 : jeudi 22 ao=FBt 2013 14:21 >>=C0 : i-d-announce@ietf.org >>Objet : I-D Action: draft-boucadair-chaining-requirements-01.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : Requirements for Service Function Chaining >> Author(s) : Mohamed Boucadair >> Christian Jacquenet >> Yuanlong Jiang >> Hongyu Li >> Ron Parker >> Filename : draft-boucadair-chaining-requirements-01.txt >> Pages : 10 >> Date : 2013-08-22 >> >>Abstract: >> This document identifies the requirements for the Service Function >> Chaining. >> >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirements >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-boucadair-chaining-requirements-01 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirements-= 01 >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc >> >> > From jguichar@cisco.com Thu Sep 5 04:40:34 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 E00BF11E8125 for ; Thu, 5 Sep 2013 04:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.066, 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 1WxGhhDNgi-B for ; Thu, 5 Sep 2013 04:40:22 -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 3B0D621E80B5 for ; Thu, 5 Sep 2013 04:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27386; q=dns/txt; s=iport; t=1378381222; x=1379590822; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=zebKwjEEU07pg+fKG6CI0ewtmiuj8ETL9uoaL49Fzv8=; b=ahuqt3yn1Ue+l1uA24wZEb99+200O78xSM6ekKjwh+T6O3CsQ7fJptzt MYQ7ypAT62qS71F9rxwynUCjgZO1vxqRIPSnAAzFFl60Kia18vAxwp/tj h2eQ5pZV57+ADvksOXfhm67fTACetY8KzdPeyH6TfX/TXrMoiyu9X5H33 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAF9tKFKtJV2Y/2dsb2JhbABbgkNENVHBR4EoFnSCJAEBAQQtPgcHEgEIEQECAQEBCxYHORQDBggCBAEJBAUIh3q6TI4tgQIgEQYBgx2BAAOUG5VAgyCBaUE X-IronPort-AV: E=Sophos;i="4.90,846,1371081600"; d="scan'208,217";a="255954014" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 05 Sep 2013 11:40:20 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r85BeKIr004088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 11:40:20 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 06:40:19 -0500 From: "Jim Guichard (jguichar)" To: Jiangyuanlong , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2WnuQgAC+LAA= Date: Thu, 5 Sep 2013 11:40:19 +0000 Message-ID: <68B171751455884590F8E38E96416F363F676C10@xmb-rcd-x01.cisco.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9@szxema506-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.246.115] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F676C10xmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 11:40:34 -0000 --_000_68B171751455884590F8E38E96416F363F676C10xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Yuanlong, Many thanks for this and I agree it could be clearer. I have updated the ch= arter to reflect your inputs. From: Jiangyuanlong > Date: Wednesday, September 4, 2013 11:41 PM To: Microsoft Office User >, = "nsc@ietf.org" > Cc: Zhuhengjun > Subject: Re: [nsc] NSC Working Group Charter Proposal Hi Jim, Thanks for the hard work on drafting the charter. In the proposed NSC charter, it says: =934) Manageability: this document will address service chaining operation,= monitoring and troubleshooting including relevant service chaining models = such as MIBs or YANG modules, along with relevant OAM capabilities and how = they are realized.=94 Firstly, the relation of =93operation, monitoring and troubleshooting=94 an= d =93OAM=94 is not very clear to me. Secondly, though YANG module is a good piece of work, I don=92t think it sh= ould be put in the list of NSC deliverables, since YANG related specificati= on used to belong to OPS area. We can transfer it to OPS (after information= models are mature enough) and the expertise should be readily found there. I would like to propose the following texts: 4) Manageability: this document will address service chaining management in= cluding relevant service chaining MIBs and information models, and service = chaining OAM. Splitting OAM into a separate item seems another option as it mainly solves= traceability of service chaining. Finally, the proposed timeline is not very practical IMHO (plus one year f= or each item in the Milestone?). Regards, Yuanlong From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Wednesday, September 04, 2013 12:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_68B171751455884590F8E38E96416F363F676C10xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <42BDB7CC865CB2498F703E3210B77D39@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Yuanlong,

Many thanks for this and I agree it could be clearer. I have updated t= he charter to reflect your inputs. 

From: Jiangyuanlong <jiangyuanlong@huawei.com>
Date: Wednesday, September 4, 2013 = 11:41 PM
To: Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Cc: Zhuhengjun <zhuhengjun@huawei.com>
Subject: Re: [nsc] NSC Working Grou= p Charter Proposal

Hi Jim,

 

Thanks for the hard work on = drafting the charter.

 

In the proposed NSC charter,= it says:

 

=934) Manageability: this do= cument will address service chaining operation, monitoring and troubleshoot= ing including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities = and how they are realized.=94

 

Firstly, the relation of =93= operation, monitoring and troubleshooting=94 and =93OAM=94 is not very clea= r to me.

 

Secondly, though YANG module= is a good piece of work, I don=92t think it should be put in the list of N= SC deliverables, since YANG related specification used to belong to OPS area. We can transfer it to OPS (after information m= odels are mature enough) and the expertise should be readily found there. &= nbsp;

 

I would like to propose the = following texts:

 

4) Manageability: this docum= ent will address service chaining management including relevant service cha= ining MIBs and information models, and service chaining OAM.

 

Splitting OAM into a separat= e item seems another option as it mainly solves traceability of service cha= ining.

 

Finally,  the proposed = timeline is not very practical IMHO (plus one year for each item in the Mil= estone?).

 

Regards,

Yuanlong

 =

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, September 04, 2013 12:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal<= /p>

 

Greetings,=

 

As we look forward to the fo= rmation of a working group that will focus on network service chaining, I w= ould like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the= routing area AD's. The following is a first draft of the charter and I inv= ite you to actively participate and provide inputs into this process.<= /o:p>

 

Proposed NSC WG Charter

 

Existing service insertion a= nd deployment techniques have not evolved to meet modern network architectu= res and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network require= ments. Networks, servers, storage, and applications, have all undergone sig= nificant change in recent years: virtualization, network overlays, and orch= estration are increasingly the norm. All of these have profound effects on network and services design.

 

Today, deploying new service= s, or making changes to existing services, often requires network topology = changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological cha= nges leading to mostly-static service definitions. New service insertion an= d deployment techniques must enable the concept of service functions as sha= red resources, and enable the linkage of these resources using service chains that represent the abstracted view= of the required service functions, and define the order in which they shou= ld be applied. When a service chain is instantiated in a network, specific = instances of service functions are selected, and a service topology is created and used for forwarding packet= s through the service chain.

 

A basic service chain might = simply utilize an existing overlay technology to force traffic through the = necessary service functions. However, additional information enables a richer service chain for more advanced co= mposite services. For example, shared information (e.g., the result of clas= sification) can be used to offload service function processing or inform ot= her service functions about information that would otherwise be hard to glean. 

 

The Network Service Chaining= (NSC) working group focuses on new approaches to service insertion and dep= loyment, providing a framework for the construction of services built using service chains. The WG focuses on the= necessary protocols for the creation of service chains, and the passing of= metadata from the network to service functions, and between service functi= ons. When possible, the WG will extend existing protocols to provide service chaining functionality, and a= ny protocol extensions will be reviewed by both the Network Service Chainin= g WG and by the WG responsible for the protocol being extended.  =

 

Specifically, the Network Se= rvice Chaining WG is chartered to deliver the following work items: 

 

1) Problem Statement: this d= ocument will provide a summary of the problem space to be addressed by the = Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normaliz= e on nomenclature and definitions for Network Service Chaining.<= /span>

 

2) System Architecture: this= set of documents will provide a description of the architecture building b= locks and their relationships including interconnection, placement of capabilities, and security models, as well a= s requirements on the control mechanisms and data plane encapsulation.=

 

3) Service Chaining Data Pla= ne: this document will describe on the wire data plane encapsulation in sup= port of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.<= o:p>

 

4) Manageability: this docum= ent will address service chaining operation, monitoring and troubleshooting= including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how= they are realized.

 

Proposed Milestones:

 

Dec 2013 Request publication= of an Informational document defining the Network Service Chaining problem= statement to the IESG

 

Mar 2014 Request publication= of informational documents defining the system architecture including prot= ocol requirements and framework to the IESG

 

May 2014 Request publication= of a Standards Track document specifying the data-plane (including metadat= a) for Service Chaining to IESG

 

May 2014 Request publication= of an informational document specifying Service Chaining Control Plane req= uirements to IESG

 

Dec 2014 Request publication= of informational documents defining Service Chaining manageability require= ments including MIBs, OAM, and information models to IESG 

 

 

 --_000_68B171751455884590F8E38E96416F363F676C10xmbrcdx01ciscoc_-- From jguichar@cisco.com Thu Sep 5 04:57: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 1AAB011E8178 for ; Thu, 5 Sep 2013 04:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ZLo6ijQeQZfK for ; Thu, 5 Sep 2013 04:56:48 -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 4ABB011E8125 for ; Thu, 5 Sep 2013 04:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12195; q=dns/txt; s=iport; t=1378382203; x=1379591803; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=ZpJMnKzRmRMqBfYymjUpo96CUABvzZF9uw0TXWzksv8=; b=GT9ha4NCqWZYsON3kFQT3VdQox6E81GIaIE1swvVuWnToNsWpTYA7MV3 2oPooe2QhP7B9Z3LbhysWic7dN0EjjfY8Mm3cYOeVp+Q2nAcKrZuBSohE jzjbMEH6Jmj5O3a/DZ4BDjuZTB1AgL6rrY2NhEcCZYxzki4u91+D1S50/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwFAOVwKFKtJV2a/2dsb2JhbABbgkNEgQbBR4EoFnSCJgEEchkBCBIQVhcOAgQbh3qZSaEGji2BAjiDHYEAA5QblUCDIIFpQQ X-IronPort-AV: E=Sophos;i="4.90,846,1371081600"; d="scan'208,217";a="252939167" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 05 Sep 2013 11:56:41 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r85BufT6014177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Sep 2013 11:56:41 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 06:56:40 -0500 From: "Jim Guichard (jguichar)" To: "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiA Date: Thu, 5 Sep 2013 11:56:39 +0000 Message-ID: <68B171751455884590F8E38E96416F363F676C32@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F672511@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.86.246.115] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F676C32xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 11:57:01 -0000 --_000_68B171751455884590F8E38E96416F363F676C32xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Greetings, I have updated the charter as follows based on all comments received thus f= ar. There have been lots of inputs and this charter may not reflect all of = them (hopefully it is pretty close). Please take time to review and continu= e the discussion. Proposed NSC WG Charter =96 Take two Existing service insertion and deployment techniques fail to address new ch= allenging requirements raised by the introduction of emerging technologies = such as multi-tenancy, virtualization, elasticity, and rich classification.= Networks, servers, and other storage technologies, let alone applications,= have all undergone significant change in recent years: virtualization, net= work overlays, and orchestration have increasingly become techniques that c= ount and sometimes prevail. All of these have profound effects on network a= nd services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to massively static configuration procedures for network servic= e delivery or update purposes. The structuring and the delivery of new netw= ork services assume the (smart) combination of various service functions as= shared resources, and enable the linkage of these resources using service = chains that represent the abstracted view of the required service functions= , and define the order in which they should be invoked. Such (smart) combin= ations could be made of heterogeneous service functions which may act at va= rious layers of a protocol stack (network layer, application layer, etc). W= hen a service chain is instantiated in a network, specific instances of ser= vice functions are selected, and a service topology is created and used for= forwarding packets according to the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information that is shared across a subset of service functions may enabl= e a richer service chain for more advanced composite services. For example,= shared information, such as the results of a classification function, may = be passed to downstream service functions to enable the offloading of servi= ce function processing or to share information that would otherwise be hard= to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to network service structuring, insertion, and deployment, providing a fram= ework for the construction of services built using service function chains.= The WG focuses on the necessary protocols for the creation of service chai= ns, and the transmission of network and service-specific information from t= he network to service functions, and between service functions. When possib= le, the WG will extend existing protocols to provide service chaining funct= ionality, and any protocol extensions will be reviewed by both the Network = Service Chaining WG and by the WG responsible for the protocol being extend= ed. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including example h= igh-level use cases. Additionally, the WG will normalize on nomenclature a= nd definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining management in= support of (2) including relevant service chaining MIBs and information mo= dels, and service chaining OAM. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including context data) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of Informational document(s) defining Network = Service Chaining use cases to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability including MIBs, OAM, and information models to IESG --_000_68B171751455884590F8E38E96416F363F676C32xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Greetings,

I have updated the charter as follows based on all comments received t= hus far. There have been lots of inputs and this charter may not reflect al= l of them (hopefully it is pretty close). Please take time to review and co= ntinue the discussion.

Proposed NSC WG Charter =96 Take two

Existing service insertion and deployment techniques fail to address n= ew challenging requirements raised by the introduction of emerging technolo= gies such as multi-tenancy, virtualization, elasticity, and rich classifica= tion. Networks, servers, and other storage technologies, let alone applications, have all undergone significa= nt change in recent years: virtualization, network overlays, and orchestrat= ion have increasingly become techniques that count and sometimes prevail. A= ll of these have profound effects on network and services design.

Today, deploying new services, or making changes to existing services,= often requires network topology changes. Adding and removing service funct= ions is a complex, risky task, that is tied to operationalizing topological= changes leading to massively static configuration procedures for network service delivery or update purposes. = The structuring and the delivery of new network services assume the (smart)= combination of various service functions as shared resources, and enable t= he linkage of these resources using service chains that represent the abstracted view of the required service = functions, and define the order in which they should be invoked. Such (smar= t) combinations could be made of heterogeneous service functions which may = act at various layers of a protocol stack (network layer, application layer, etc). When a service chain is ins= tantiated in a network, specific instances of service functions are selecte= d, and a service topology is created and used for forwarding packets accord= ing to the service chain.

A basic service chain might simply utilize an existing overlay technol= ogy to force traffic through the necessary service functions. However, addi= tional information that is shared across a subset of service functions may = enable a richer service chain for more advanced composite services. For example, shared information, such as= the results of a classification function, may be passed to downstream serv= ice functions to enable the offloading of service function processing or to= share information that would otherwise be hard to glean. 

The Network Service Chaining (NSC) working group focuses on new approa= ches to network service structuring, insertion, and deployment, providing a= framework for the construction of services built using service function ch= ains. The WG focuses on the necessary protocols for the creation of service chains, and the transmission of netw= ork and service-specific information from the network to service functions,= and between service functions. When possible, the WG will extend existing = protocols to provide service chaining functionality, and any protocol extensions will be reviewed by both the Ne= twork Service Chaining WG and by the WG responsible for the protocol being = extended.  

Specifically, the Network Service Chaining WG is chartered to deliver = the following work items: 

1) Problem Statement: this document will provide a summary of the prob= lem space to be addressed by the Network Service Chaining WG including exam= ple high-level use cases.  Additionally, the WG will normalize on nome= nclature and definitions for Network Service Chaining.

2) System Architecture: this set of documents will provide a descripti= on of the architecture building blocks and their relationships including in= terconnection, placement of capabilities, and security models, as well as r= equirements on the control mechanisms and data plane encapsulation.

3) Service Chaining Data Plane: this document will describe on the wir= e data plane encapsulation in support of (2).  A single encapsulation = will be selected in order to enable interoperability of data plane componen= ts.

4) Manageability: this document will address service chaining manageme= nt in support of (2) including relevant service chaining MIBs and informati= on models, and service chaining OAM.

Proposed Milestones:

Dec 2013 Request publication of an Informational document defining the= Network Service Chaining problem statement to the IESG

Mar 2014 Request publication of informational documents defining the s= ystem architecture including protocol requirements and framework to the IES= G

May 2014 Request publication of a Standards Track document specifying = the data-plane (including context data) for Service Chaining to IESG

May 2014 Request publication of an informational document specifying S= ervice Chaining Control Plane requirements to IESG

Dec 2014 Request publication of Informational document(s) defining Net= work Service Chaining use cases to IESG

Dec 2014 Request publication of informational documents defining Servi= ce Chaining manageability including MIBs, OAM, and information models to IE= SG 



 
 --_000_68B171751455884590F8E38E96416F363F676C32xmbrcdx01ciscoc_-- From jmh@joelhalpern.com Thu Sep 5 05:05:45 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759CD11E811B for ; Thu, 5 Sep 2013 05:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 BYBEym8FPqAT for ; Thu, 5 Sep 2013 05:05:39 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id DC88811E8137 for ; Thu, 5 Sep 2013 05:05:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9A82B1C0447; Thu, 5 Sep 2013 05:05:32 -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 166621C02FE; Thu, 5 Sep 2013 05:05:30 -0700 (PDT) Message-ID: <5228738C.4020703@joelhalpern.com> Date: Thu, 05 Sep 2013 08:05:32 -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: Jiangyuanlong References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9@szxema506-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9@szxema506-mbs.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 12:05:45 -0000 Small clarification. While all YANG models have been done by netmod to date, it seems extremely unlikely that anyone expects taht to remain the case. Certainly and YANG modules produced would need review by YANG experts, but just as SNMP MIB modules are normally produced by the topic group, not an SNMP working group, a similar approach makes sense for YANG modules. Yours, Joel On 9/4/13 11:41 PM, Jiangyuanlong wrote: > Hi Jim, > > Thanks for the hard work on drafting the charter. > > In the proposed NSC charter, it says: > > “4) Manageability: this document will address service chaining > operation, monitoring and troubleshooting including relevant service > chaining models such as MIBs or YANG modules, along with relevant OAM > capabilities and how they are realized.” > > Firstly, the relation of “operation, monitoring and troubleshooting” and > “OAM” is not very clear to me. > > Secondly, though YANG module is a good piece of work, I don’t think it > should be put in the list of NSC deliverables, since YANG related > specification used to belong to OPS area. We can transfer it to OPS > (after information models are mature enough) and the expertise should be > readily found there. > > I would like to propose the following texts: > > 4) Manageability: this document will address service chaining management > including relevant service chaining MIBs and information models, and > service chaining OAM. > > Splitting OAM into a separate item seems another option as it mainly > solves traceability of service chaining. > > Finally, the proposed timeline is not very practical IMHO (plus one > year for each item in the Milestone?). > > Regards, > > Yuanlong > > *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf Of > *Jim Guichard (jguichar) > *Sent:* Wednesday, September 04, 2013 12:01 AM > *To:* nsc@ietf.org > *Subject:* [nsc] NSC Working Group Charter Proposal > > Greetings, > > As we look forward to the formation of a working group that will focus > on network service chaining, I would like to propose a discussion on > this alias to try and reach consensus on an initial charter as requested > by the routing area AD's. The following is a first draft of the charter > and I invite you to actively participate and provide inputs into this > process. > > _Proposed NSC WG Charter_ > > Existing service insertion and deployment techniques have not evolved to > meet modern network architectures and do not reflect multi-tenancy, > virtualization, elasticity, rich classification, and other network > requirements. Networks, servers, storage, and applications, have all > undergone significant change in recent years: virtualization, network > overlays, and orchestration are increasingly the norm. All of these have > profound effects on network and services design. > > Today, deploying new services, or making changes to existing services, > often requires network topology changes. Adding and removing service > functions is a complex, risky task, that is tied to operationalizing > topological changes leading to mostly-static service definitions. New > service insertion and deployment techniques must enable the concept of > service functions as shared resources, and enable the linkage of these > resources using service chains that represent the abstracted view of the > required service functions, and define the order in which they should be > applied. When a service chain is instantiated in a network, specific > instances of service functions are selected, and a service topology is > created and used for forwarding packets through the service chain. > > A basic service chain might simply utilize an existing overlay > technology to force traffic through the necessary service functions. > However, additional information enables a richer service chain for more > advanced composite services. For example, shared information (e.g., the > result of classification) can be used to offload service function > processing or inform other service functions about information that > would otherwise be hard to glean. > > The Network Service Chaining (NSC) working group focuses on new > approaches to service insertion and deployment, providing a framework > for the construction of services built using service chains. The WG > focuses on the necessary protocols for the creation of service chains, > and the passing of metadata from the network to service functions, and > between service functions. When possible, the WG will extend existing > protocols to provide service chaining functionality, and any protocol > extensions will be reviewed by both the Network Service Chaining WG and > by the WG responsible for the protocol being extended. > > Specifically, the Network Service Chaining WG is chartered to deliver > the following work items: > > 1) Problem Statement: this document will provide a summary of the > problem space to be addressed by the Network Service Chaining WG > including terminology and sample use cases. Additionally, the WG will > normalize on nomenclature and definitions for Network Service Chaining. > > 2) System Architecture: this set of documents will provide a description > of the architecture building blocks and their relationships including > interconnection, placement of capabilities, and security models, as well > as requirements on the control mechanisms and data plane encapsulation. > > 3) Service Chaining Data Plane: this document will describe on the wire > data plane encapsulation in support of (2). A single encapsulation will > be selected in order to enable interoperability of data plane components. > > 4) Manageability: this document will address service chaining operation, > monitoring and troubleshooting including relevant service chaining > models such as MIBs or YANG modules, along with relevant OAM > capabilities and how they are realized. > > Proposed Milestones: > > Dec 2013 Request publication of an Informational document defining the > Network Service Chaining problem statement to the IESG > > Mar 2014 Request publication of informational documents defining the > system architecture including protocol requirements and framework to the > IESG > > May 2014 Request publication of a Standards Track document specifying > the data-plane (including metadata) for Service Chaining to IESG > > May 2014 Request publication of an informational document specifying > Service Chaining Control Plane requirements to IESG > > Dec 2014 Request publication of informational documents defining Service > Chaining manageability requirements including MIBs, OAM, and information > models to IESG > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From tnadeau@lucidvision.com Thu Sep 5 05:20: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 13E9A11E8194 for ; Thu, 5 Sep 2013 05:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.199, 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 vl8AYDByvFqs for ; Thu, 5 Sep 2013 05:20:07 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A878E11E818F for ; Thu, 5 Sep 2013 05:20:03 -0700 (PDT) Received: from [172.28.132.200] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id ABF4C255BAA0; Thu, 5 Sep 2013 08:20:00 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_283B5810-8262-4928-BDBD-DD24F198F08A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9@szxema506-mbs.china.huawei.com> Date: Thu, 5 Sep 2013 08:19:59 -0400 Message-Id: <62FEC71F-777B-4B7D-B8E2-FF84FA208D23@lucidvision.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9@szxema506-mbs.china.huawei.com> To: Jiangyuanlong X-Mailer: Apple Mail (2.1508) Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 12:20:13 -0000 --Apple-Mail=_283B5810-8262-4928-BDBD-DD24F198F08A Content-Type: multipart/alternative; boundary="Apple-Mail=_25A9E91E-3D51-4EDC-9B4F-F296DA83C231" --Apple-Mail=_25A9E91E-3D51-4EDC-9B4F-F296DA83C231 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 4, 2013:11:41 PM, at 11:41 PM, Jiangyuanlong = wrote: > Hi Jim, > =20 > Thanks for the hard work on drafting the charter. > =20 > In the proposed NSC charter, it says: > =20 > =934) Manageability: this document will address service chaining = operation, monitoring and troubleshooting including relevant service = chaining models such as MIBs or YANG modules, along with relevant OAM = capabilities and how they are realized.=94 > =20 > Firstly, the relation of =93operation, monitoring and troubleshooting=94= and =93OAM=94 is not very clear to me. > =20 > Secondly, though YANG module is a good piece of work, I don=92t think = it should be put in the list of NSC deliverables, since YANG related = specification used to belong to OPS area. We can transfer it to OPS = (after information models are mature enough) and the expertise should be = readily found there. =20 It is included because Yang modules, like MIB modules, are very = appropriate for any working group to deliver as part of their work = items. > I would like to propose the following texts: > =20 > 4) Manageability: this document will address service chaining = management including relevant service chaining MIBs and information = models, and service chaining OAM. > =20 > Splitting OAM into a separate item seems another option as it mainly = solves traceability of service chaining. > =20 > Finally, the proposed timeline is not very practical IMHO (plus one = year for each item in the Milestone?). The timelines are not set in stone and are ultimately decided by = the ADs; they are just place holders now. --Tom > =20 > Regards, > Yuanlong > =20 > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of = Jim Guichard (jguichar) > Sent: Wednesday, September 04, 2013 12:01 AM > To: nsc@ietf.org > Subject: [nsc] NSC Working Group Charter Proposal > =20 > Greetings, > =20 > As we look forward to the formation of a working group that will focus = on network service chaining, I would like to propose a discussion on = this alias to try and reach consensus on an initial charter as requested = by the routing area AD's. The following is a first draft of the charter = and I invite you to actively participate and provide inputs into this = process. > =20 > Proposed NSC WG Charter > =20 > Existing service insertion and deployment techniques have not evolved = to meet modern network architectures and do not reflect multi-tenancy, = virtualization, elasticity, rich classification, and other network = requirements. Networks, servers, storage, and applications, have all = undergone significant change in recent years: virtualization, network = overlays, and orchestration are increasingly the norm. All of these have = profound effects on network and services design. > =20 > Today, deploying new services, or making changes to existing services, = often requires network topology changes. Adding and removing service = functions is a complex, risky task, that is tied to operationalizing = topological changes leading to mostly-static service definitions. New = service insertion and deployment techniques must enable the concept of = service functions as shared resources, and enable the linkage of these = resources using service chains that represent the abstracted view of the = required service functions, and define the order in which they should be = applied. When a service chain is instantiated in a network, specific = instances of service functions are selected, and a service topology is = created and used for forwarding packets through the service chain. > =20 > A basic service chain might simply utilize an existing overlay = technology to force traffic through the necessary service functions. = However, additional information enables a richer service chain for more = advanced composite services. For example, shared information (e.g., the = result of classification) can be used to offload service function = processing or inform other service functions about information that = would otherwise be hard to glean.=20 > =20 > The Network Service Chaining (NSC) working group focuses on new = approaches to service insertion and deployment, providing a framework = for the construction of services built using service chains. The WG = focuses on the necessary protocols for the creation of service chains, = and the passing of metadata from the network to service functions, and = between service functions. When possible, the WG will extend existing = protocols to provide service chaining functionality, and any protocol = extensions will be reviewed by both the Network Service Chaining WG and = by the WG responsible for the protocol being extended. =20 > =20 > Specifically, the Network Service Chaining WG is chartered to deliver = the following work items:=20 > =20 > 1) Problem Statement: this document will provide a summary of the = problem space to be addressed by the Network Service Chaining WG = including terminology and sample use cases. Additionally, the WG will = normalize on nomenclature and definitions for Network Service Chaining. > =20 > 2) System Architecture: this set of documents will provide a = description of the architecture building blocks and their relationships = including interconnection, placement of capabilities, and security = models, as well as requirements on the control mechanisms and data plane = encapsulation. > =20 > 3) Service Chaining Data Plane: this document will describe on the = wire data plane encapsulation in support of (2). A single encapsulation = will be selected in order to enable interoperability of data plane = components. > =20 > 4) Manageability: this document will address service chaining = operation, monitoring and troubleshooting including relevant service = chaining models such as MIBs or YANG modules, along with relevant OAM = capabilities and how they are realized. > =20 > Proposed Milestones: > =20 > Dec 2013 Request publication of an Informational document defining the = Network Service Chaining problem statement to the IESG > =20 > Mar 2014 Request publication of informational documents defining the = system architecture including protocol requirements and framework to the = IESG > =20 > May 2014 Request publication of a Standards Track document specifying = the data-plane (including metadata) for Service Chaining to IESG > =20 > May 2014 Request publication of an informational document specifying = Service Chaining Control Plane requirements to IESG > =20 > Dec 2014 Request publication of informational documents defining = Service Chaining manageability requirements including MIBs, OAM, and = information models to IESG=20 > =20 > =20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc --Apple-Mail=_25A9E91E-3D51-4EDC-9B4F-F296DA83C231 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Sep 4, = 2013:11:41 PM, at 11:41 PM, Jiangyuanlong <jiangyuanlong@huawei.com> = wrote:

Hi = Jim,
 
Thanks for the hard work on drafting the = charter.
 
In the proposed NSC charter, it = says:
 
=934) Manageability: this document will address service = chaining operation, monitoring and troubleshooting including relevant = service chaining models such as MIBs or YANG modules, along with = relevant OAM capabilities and how they are = realized.=94
 
Firstly, the relation of =93operation, monitoring and = troubleshooting=94 and =93OAM=94 is not very clear to = me.
 
Secondly, though YANG module is a good piece of work, I = don=92t think it should be put in the list of NSC deliverables, since = YANG related specification used to belong to OPS area. We can transfer = it to OPS (after information models are mature enough) and the expertise = should be readily found there. =  

It is = included because Yang modules, like MIB modules, are very appropriate = for any working group to deliver as part of their work = items.

I would = like to propose the following texts:
 
4) Manageability: this document will address service = chaining management including relevant service chaining MIBs and = information models, and service chaining = OAM.
 
Splitting OAM into a separate item seems another option as = it mainly solves traceability of service = chaining.
 
Finally,  the proposed timeline is not very practical = IMHO (plus one year for each item in the = Milestone?).

The = timelines are not set in stone and are ultimately decided by the ADs; = they are just place holders now.

= --Tom

 
Regards,
Yuanlong
 nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard = (jguichar)
Sent: Wednesday, September 04, = 2013 12:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group = Charter Proposal
 
 
As we look forward to the formation of a working group = that will focus on network service chaining, I would like to propose a = discussion on this alias to try and reach consensus on an initial = charter as requested by the routing area AD's. The following is a first = draft of the charter and I invite you to actively participate and = provide inputs into this = process.
 
Proposed NSC WG = Charter 
Existing service insertion and deployment = techniques have not evolved to meet modern network architectures and do = not reflect multi-tenancy, virtualization, elasticity, rich = classification, and other network requirements. Networks, servers, = storage, and applications, have all undergone significant change in = recent years: virtualization, network overlays, and orchestration are = increasingly the norm. All of these have profound effects on network and = services design.
 
Today, deploying new services, or making changes = to existing services, often requires network topology changes. Adding = and removing service functions  is a complex, risky task, = that is tied to operationalizing topological changes leading to = mostly-static service definitions. New service insertion and deployment = techniques must enable the concept of service functions as shared = resources, and enable the linkage of these resources using service = chains that represent the abstracted view of the required service = functions, and define the order in which they should be applied. When a = service chain is instantiated in a network, specific instances of = service functions are selected, and a service topology is created and = used for forwarding packets through the service = chain.
 
A basic service chain might simply utilize an existing = overlay technology to force traffic through the necessary service = functions. However, additional information enables a richer service = chain for more advanced composite services. For example, shared = information (e.g., the result of classification) can be used to offload = service function processing or inform other service functions about = information that would otherwise be hard to = glean. 
 
The Network Service Chaining (NSC) working group focuses = on new approaches to service insertion and deployment, providing a = framework for the construction of services built using service chains. = The WG focuses on the necessary protocols for the creation of service = chains, and the passing of metadata from the network to service = functions, and between service functions. When possible, the WG will = extend existing protocols to provide service chaining functionality, and = any protocol extensions will be reviewed by both the Network Service = Chaining WG and by the WG responsible for the protocol being extended. =  
 
Specifically, the Network Service Chaining WG is chartered = to deliver the following work = items: 
 
1) Problem Statement: this document will provide a summary = of the problem space to be addressed by the Network Service Chaining WG = including terminology and sample use cases.  Additionally, the WG = will normalize on nomenclature and definitions for Network Service = Chaining.
 
2) System Architecture: this set of documents will provide = a description of the architecture building blocks and their = relationships including interconnection, placement of capabilities, and = security models, as well as requirements on the control mechanisms and = data plane encapsulation.
 
3) Service Chaining Data Plane: this = document will describe on the wire data plane encapsulation in support = of (2).  A single encapsulation will be selected in order to enable = interoperability of data plane = components.
 
4) Manageability: this document will address service = chaining operation, monitoring and troubleshooting including relevant = service chaining models such as MIBs or YANG modules, along with = relevant OAM capabilities and how they are = realized.
 
Proposed = Milestones:
 
Dec 2013 Request publication of an Informational document = defining the Network Service Chaining problem statement to the = IESG
 
Mar 2014 Request publication of informational documents = defining the system architecture including protocol requirements and = framework to the IESG
 
May 2014 Request publication of a = Standards Track document specifying the data-plane (including metadata) = for Service Chaining to IESG
 
May 2014 Request publication of an = informational document specifying Service Chaining Control Plane = requirements to IESG
 
Dec 2014 Request publication of = informational documents defining Service Chaining manageability = requirements including MIBs, OAM, and information  models to = IESG 
 
 
___________________________________= ____________
nsc mailing list
Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2WnuQgAAuWwCAAJD+0A== Date: Thu, 5 Sep 2013 12:56:50 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A2B17@szxema506-mbs.china.huawei.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9@szxema506-mbs.china.huawei.com> <5228738C.4020703@joelhalpern.com> In-Reply-To: <5228738C.4020703@joelhalpern.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 12:57:21 -0000 Hi Joel, Not sure what happened during the last few weeks, but at least the minutes = of NETMOD WG in IETF 87th clearly showed it is too early to say "extremely = unlikely that anyone expects taht to remain the case ". =20 Regards, Yuanlong -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Thursday, September 05, 2013 8:06 PM To: Jiangyuanlong Cc: Jim Guichard (jguichar); nsc@ietf.org; Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal Small clarification. While all YANG models have been done by netmod to date, it seems=20 extremely unlikely that anyone expects taht to remain the case.=20 Certainly and YANG modules produced would need review by YANG experts,=20 but just as SNMP MIB modules are normally produced by the topic group,=20 not an SNMP working group, a similar approach makes sense for YANG modules. Yours, Joel On 9/4/13 11:41 PM, Jiangyuanlong wrote: > Hi Jim, > > Thanks for the hard work on drafting the charter. > > In the proposed NSC charter, it says: > > "4) Manageability: this document will address service chaining > operation, monitoring and troubleshooting including relevant service > chaining models such as MIBs or YANG modules, along with relevant OAM > capabilities and how they are realized." > > Firstly, the relation of "operation, monitoring and troubleshooting" and > "OAM" is not very clear to me. > > Secondly, though YANG module is a good piece of work, I don't think it > should be put in the list of NSC deliverables, since YANG related > specification used to belong to OPS area. We can transfer it to OPS > (after information models are mature enough) and the expertise should be > readily found there. > > I would like to propose the following texts: > > 4) Manageability: this document will address service chaining management > including relevant service chaining MIBs and information models, and > service chaining OAM. > > Splitting OAM into a separate item seems another option as it mainly > solves traceability of service chaining. > > Finally, the proposed timeline is not very practical IMHO (plus one > year for each item in the Milestone?). > > Regards, > > Yuanlong > > *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf Of > *Jim Guichard (jguichar) > *Sent:* Wednesday, September 04, 2013 12:01 AM > *To:* nsc@ietf.org > *Subject:* [nsc] NSC Working Group Charter Proposal > > Greetings, > > As we look forward to the formation of a working group that will focus > on network service chaining, I would like to propose a discussion on > this alias to try and reach consensus on an initial charter as requested > by the routing area AD's. The following is a first draft of the charter > and I invite you to actively participate and provide inputs into this > process. > > _Proposed NSC WG Charter_ > > Existing service insertion and deployment techniques have not evolved to > meet modern network architectures and do not reflect multi-tenancy, > virtualization, elasticity, rich classification, and other network > requirements. Networks, servers, storage, and applications, have all > undergone significant change in recent years: virtualization, network > overlays, and orchestration are increasingly the norm. All of these have > profound effects on network and services design. > > Today, deploying new services, or making changes to existing services, > often requires network topology changes. Adding and removing service > functions is a complex, risky task, that is tied to operationalizing > topological changes leading to mostly-static service definitions. New > service insertion and deployment techniques must enable the concept of > service functions as shared resources, and enable the linkage of these > resources using service chains that represent the abstracted view of the > required service functions, and define the order in which they should be > applied. When a service chain is instantiated in a network, specific > instances of service functions are selected, and a service topology is > created and used for forwarding packets through the service chain. > > A basic service chain might simply utilize an existing overlay > technology to force traffic through the necessary service functions. > However, additional information enables a richer service chain for more > advanced composite services. For example, shared information (e.g., the > result of classification) can be used to offload service function > processing or inform other service functions about information that > would otherwise be hard to glean. > > The Network Service Chaining (NSC) working group focuses on new > approaches to service insertion and deployment, providing a framework > for the construction of services built using service chains. The WG > focuses on the necessary protocols for the creation of service chains, > and the passing of metadata from the network to service functions, and > between service functions. When possible, the WG will extend existing > protocols to provide service chaining functionality, and any protocol > extensions will be reviewed by both the Network Service Chaining WG and > by the WG responsible for the protocol being extended. > > Specifically, the Network Service Chaining WG is chartered to deliver > the following work items: > > 1) Problem Statement: this document will provide a summary of the > problem space to be addressed by the Network Service Chaining WG > including terminology and sample use cases. Additionally, the WG will > normalize on nomenclature and definitions for Network Service Chaining. > > 2) System Architecture: this set of documents will provide a description > of the architecture building blocks and their relationships including > interconnection, placement of capabilities, and security models, as well > as requirements on the control mechanisms and data plane encapsulation. > > 3) Service Chaining Data Plane: this document will describe on the wire > data plane encapsulation in support of (2). A single encapsulation will > be selected in order to enable interoperability of data plane components. > > 4) Manageability: this document will address service chaining operation, > monitoring and troubleshooting including relevant service chaining > models such as MIBs or YANG modules, along with relevant OAM > capabilities and how they are realized. > > Proposed Milestones: > > Dec 2013 Request publication of an Informational document defining the > Network Service Chaining problem statement to the IESG > > Mar 2014 Request publication of informational documents defining the > system architecture including protocol requirements and framework to the > IESG > > May 2014 Request publication of a Standards Track document specifying > the data-plane (including metadata) for Service Chaining to IESG > > May 2014 Request publication of an informational document specifying > Service Chaining Control Plane requirements to IESG > > Dec 2014 Request publication of informational documents defining Service > Chaining manageability requirements including MIBs, OAM, and information > models to IESG > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From Ron_Parker@affirmednetworks.com Thu Sep 5 06:03: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 B79AF1F0C6D for ; Thu, 5 Sep 2013 06:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Z8ohipf0PdBp for ; Thu, 5 Sep 2013 06:03:54 -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 07CBD1F0C55 for ; Thu, 5 Sep 2013 06:03:54 -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; Thu, 5 Sep 2013 06:03:52 -0700 From: Ron Parker To: Jiangyuanlong , "Joel M. Halpern" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2WnuQgAEp0ACAAA5WAP//jC8A Date: Thu, 5 Sep 2013 13:03:52 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9@szxema506-mbs.china.huawei.com> <5228738C.4020703@joelhalpern.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A2B17@szxema506-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A2B17@szxema506-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 13:03:58 -0000 Although I far prefer the expressiveness and readability of YANG, it is cer= tainly possible to create semantically equivalent MIBs and YANG modules. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jiang= yuanlong Sent: Thursday, September 05, 2013 8:57 AM To: Joel M. Halpern Cc: nsc@ietf.org; Jim Guichard (jguichar); Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal Hi Joel, Not sure what happened during the last few weeks, but at least the minutes = of NETMOD WG in IETF 87th clearly showed it is too early to say "extremely = unlikely that anyone expects taht to remain the case ". =20 Regards, Yuanlong -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, September 05, 2013 8:06 PM To: Jiangyuanlong Cc: Jim Guichard (jguichar); nsc@ietf.org; Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal Small clarification. While all YANG models have been done by netmod to date, it seems extremely = unlikely that anyone expects taht to remain the case.=20 Certainly and YANG modules produced would need review by YANG experts, but = just as SNMP MIB modules are normally produced by the topic group, not an S= NMP working group, a similar approach makes sense for YANG modules. Yours, Joel On 9/4/13 11:41 PM, Jiangyuanlong wrote: > Hi Jim, > > Thanks for the hard work on drafting the charter. > > In the proposed NSC charter, it says: > > "4) Manageability: this document will address service chaining=20 > operation, monitoring and troubleshooting including relevant service=20 > chaining models such as MIBs or YANG modules, along with relevant OAM=20 > capabilities and how they are realized." > > Firstly, the relation of "operation, monitoring and troubleshooting"=20 > and "OAM" is not very clear to me. > > Secondly, though YANG module is a good piece of work, I don't think it=20 > should be put in the list of NSC deliverables, since YANG related=20 > specification used to belong to OPS area. We can transfer it to OPS=20 > (after information models are mature enough) and the expertise should=20 > be readily found there. > > I would like to propose the following texts: > > 4) Manageability: this document will address service chaining=20 > management including relevant service chaining MIBs and information=20 > models, and service chaining OAM. > > Splitting OAM into a separate item seems another option as it mainly=20 > solves traceability of service chaining. > > Finally, the proposed timeline is not very practical IMHO (plus one=20 > year for each item in the Milestone?). > > Regards, > > Yuanlong > > *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf=20 > Of *Jim Guichard (jguichar) > *Sent:* Wednesday, September 04, 2013 12:01 AM > *To:* nsc@ietf.org > *Subject:* [nsc] NSC Working Group Charter Proposal > > Greetings, > > As we look forward to the formation of a working group that will focus=20 > on network service chaining, I would like to propose a discussion on=20 > this alias to try and reach consensus on an initial charter as=20 > requested by the routing area AD's. The following is a first draft of=20 > the charter and I invite you to actively participate and provide=20 > inputs into this process. > > _Proposed NSC WG Charter_ > > Existing service insertion and deployment techniques have not evolved=20 > to meet modern network architectures and do not reflect multi-tenancy,=20 > virtualization, elasticity, rich classification, and other network=20 > requirements. Networks, servers, storage, and applications, have all=20 > undergone significant change in recent years: virtualization, network=20 > overlays, and orchestration are increasingly the norm. All of these=20 > have profound effects on network and services design. > > Today, deploying new services, or making changes to existing services,=20 > often requires network topology changes. Adding and removing service=20 > functions is a complex, risky task, that is tied to operationalizing=20 > topological changes leading to mostly-static service definitions. New=20 > service insertion and deployment techniques must enable the concept of=20 > service functions as shared resources, and enable the linkage of these=20 > resources using service chains that represent the abstracted view of=20 > the required service functions, and define the order in which they=20 > should be applied. When a service chain is instantiated in a network,=20 > specific instances of service functions are selected, and a service=20 > topology is created and used for forwarding packets through the service c= hain. > > A basic service chain might simply utilize an existing overlay=20 > technology to force traffic through the necessary service functions. > However, additional information enables a richer service chain for=20 > more advanced composite services. For example, shared information=20 > (e.g., the result of classification) can be used to offload service=20 > function processing or inform other service functions about=20 > information that would otherwise be hard to glean. > > The Network Service Chaining (NSC) working group focuses on new=20 > approaches to service insertion and deployment, providing a framework=20 > for the construction of services built using service chains. The WG=20 > focuses on the necessary protocols for the creation of service chains,=20 > and the passing of metadata from the network to service functions, and=20 > between service functions. When possible, the WG will extend existing=20 > protocols to provide service chaining functionality, and any protocol=20 > extensions will be reviewed by both the Network Service Chaining WG=20 > and by the WG responsible for the protocol being extended. > > Specifically, the Network Service Chaining WG is chartered to deliver=20 > the following work items: > > 1) Problem Statement: this document will provide a summary of the=20 > problem space to be addressed by the Network Service Chaining WG=20 > including terminology and sample use cases. Additionally, the WG will=20 > normalize on nomenclature and definitions for Network Service Chaining. > > 2) System Architecture: this set of documents will provide a=20 > description of the architecture building blocks and their=20 > relationships including interconnection, placement of capabilities,=20 > and security models, as well as requirements on the control mechanisms an= d data plane encapsulation. > > 3) Service Chaining Data Plane: this document will describe on the=20 > wire data plane encapsulation in support of (2). A single=20 > encapsulation will be selected in order to enable interoperability of dat= a plane components. > > 4) Manageability: this document will address service chaining=20 > operation, monitoring and troubleshooting including relevant service=20 > chaining models such as MIBs or YANG modules, along with relevant OAM=20 > capabilities and how they are realized. > > Proposed Milestones: > > Dec 2013 Request publication of an Informational document defining the=20 > Network Service Chaining problem statement to the IESG > > Mar 2014 Request publication of informational documents defining the=20 > system architecture including protocol requirements and framework to=20 > the IESG > > May 2014 Request publication of a Standards Track document specifying=20 > the data-plane (including metadata) for Service Chaining to IESG > > May 2014 Request publication of an informational document specifying=20 > Service Chaining Control Plane requirements to IESG > > Dec 2014 Request publication of informational documents defining=20 > Service Chaining manageability requirements including MIBs, OAM, and=20 > information models to IESG > > > > _______________________________________________ > nsc mailing 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 jiangyuanlong@huawei.com Thu Sep 5 06:11: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 03DDA1F0C55 for ; Thu, 5 Sep 2013 06:11:09 -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.000, 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 0I1VzRtrtyU1 for ; Thu, 5 Sep 2013 06:11:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8C821F9BAB for ; Thu, 5 Sep 2013 06:11:02 -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.5-GA FastPath queued) with ESMTP id AWX96079; Thu, 05 Sep 2013 13:11:01 +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.146.0; Thu, 5 Sep 2013 14:10:42 +0100 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 14:10:58 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.127]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0146.000; Thu, 5 Sep 2013 21:10:45 +0800 From: Jiangyuanlong To: Thomas Nadeau Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2WnuQgAAyZYCAAJE9AA== Date: Thu, 5 Sep 2013 13:10:43 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A2B3C@szxema506-mbs.china.huawei.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9@szxema506-mbs.china.huawei.com> <62FEC71F-777B-4B7D-B8E2-FF84FA208D23@lucidvision.com> In-Reply-To: <62FEC71F-777B-4B7D-B8E2-FF84FA208D23@lucidvision.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_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A2B3Cszxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 13:11:09 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A2B3Cszxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Thursday, September 05, 2013 8:20 PM To: Jiangyuanlong Cc: Jim Guichard (jguichar); nsc@ietf.org; Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal On Sep 4, 2013:11:41 PM, at 11:41 PM, Jiangyuanlong > wrote: Hi Jim, Thanks for the hard work on drafting the charter. In the proposed NSC charter, it says: "4) Manageability: this document will address service chaining operation, m= onitoring and troubleshooting including relevant service chaining models su= ch as MIBs or YANG modules, along with relevant OAM capabilities and how th= ey are realized." Firstly, the relation of "operation, monitoring and troubleshooting" and "O= AM" is not very clear to me. Secondly, though YANG module is a good piece of work, I don't think it shou= ld be put in the list of NSC deliverables, since YANG related specification= used to belong to OPS area. We can transfer it to OPS (after information m= odels are mature enough) and the expertise should be readily found there. It is included because Yang modules, like MIB modules, are very appr= opriate for any working group to deliver as part of their work items. [JY] Just as Joel said, unlike MIB, Yang modules are used to be specified i= n NETMOD WG. I would like to propose the following texts: 4) Manageability: this document will address service chaining management in= cluding relevant service chaining MIBs and information models, and service = chaining OAM. Splitting OAM into a separate item seems another option as it mainly solves= traceability of service chaining. Finally, the proposed timeline is not very practical IMHO (plus one year f= or each item in the Milestone?). The timelines are not set in stone and are ultimately decided by the= ADs; they are just place holders now. [JY] Yes, I understand the whole charter is not set in stone, but maybe we = can save our ADs some work as they have been so busy already:) --Tom Regards, Yuanlong From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Wednesday, September 04, 2013 12:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological cha= nges leading to mostly-static service definitions. New service insertion an= d deployment techniques must enable the concept of service functions as sha= red resources, and enable the linkage of these resources using service chai= ns that represent the abstracted view of the required service functions, an= d define the order in which they should be applied. When a service chain is= instantiated in a network, specific instances of service functions are sel= ected, and a service topology is created and used for forwarding packets th= rough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mod= els to IESG _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A2B3Cszxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 = ;

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Thursday, September 05, 2013 8:20 PM
To: Jiangyuanlong
Cc: Jim Guichard (jguichar); nsc@ietf.org; Zhuhengjun
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

 



Hi Jim,

 

Thanks for the hard work= on drafting the charter.

 

In the proposed NSC char= ter, it says:

 

“4) Manageability:= this document will address service chaining operation, monitoring and trou= bleshooting including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are rea= lized.”

 

Firstly, the relation of= “operation, monitoring and troubleshooting” and “OAMR= 21; is not very clear to me.<= /p>

 

Secondly, though YANG mo= dule is a good piece of work, I don’t think it should be put in the l= ist of NSC deliverables, since YANG related specification used to belong to OPS area. We can transfer it to OPS (after information models ar= e mature enough) and the expertise should be readily found there.  

 

=        It is included because Yang modules, like MIB m= odules, are very appropriate for any working group to deliver as part of th= eir work items.

[JY] Ju= st as Joel said, unlike MIB, Yang modules are used to be specified in NETMO= D WG.

I would like to propose = the following texts:

 

4) Manageability: this d= ocument will address service chaining management including relevant service= chaining MIBs and information models, and service chaining OAM.

 

Splitting OAM into a sep= arate item seems another option as it mainly solves traceability of service= chaining.

 

Finally,  the propo= sed timeline is not very practical IMHO (plus one year for each item in the= Milestone?).

 

=        The timelines are not set in stone and are ulti= mately decided by the ADs; they are just place holders now.

[JY] Ye= s, I understand the whole charter is not set in stone, but maybe we can sav= e our ADs some work as they have been so busy alreadyJ

 = ;

=        --Tom



 

Regards,

Yuanlong

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guicha= rd (jguichar)
Sent: Wednesday, S= eptember 04, 2013 12:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC= Working Group Charter Proposal

 

Greetings,

 

As we look forward to th= e formation of a working group that will focus on network service chaining,= I would like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area= AD's. The following is a first draft of the charter and I invite you to ac= tively participate and provide inputs into this process.

 

Proposed NSC WG Chart= er

 

Existing service inserti= on and deployment techniques have not evolved to meet modern network archit= ectures and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks,= servers, storage, and applications, have all undergone significant change = in recent years: virtualization, network overlays, and orchestration are in= creasingly the norm. All of these have profound effects on network and services design.

 

Today, deploying new ser= vices, or making changes to existing services, often requires network topol= ogy changes. Adding and removing service functions  is a complex, risky task, that is tied to operationalizing topological cha= nges leading to mostly-static service definitions. New service insertion an= d deployment techniques must enable the concept of service functions as sha= red resources, and enable the linkage of these resources using service chains that represent the abstracted view= of the required service functions, and define the order in which they shou= ld be applied. When a service chain is instantiated in a network, specific = instances of service functions are selected, and a service topology is created and used for forwarding packet= s through the service chain.<= /p>

 

A basic service chain mi= ght simply utilize an existing overlay technology to force traffic through = the necessary service functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chai= ning (NSC) working group focuses on new approaches to service insertion and= deployment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary proto= cols for the creation of service chains, and the passing of metadata from t= he network to service functions, and between service functions. When possib= le, the WG will extend existing protocols to provide service chaining functionality, and any protocol exte= nsions will be reviewed by both the Network Service Chaining WG and by the = WG responsible for the protocol being extended.  

 

Specifically, the Networ= k Service Chaining WG is chartered to deliver the following work items:&nbs= p;

 

1) Problem Statement: th= is document will provide a summary of the problem space to be addressed by = the Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclatur= e and definitions for Network Service Chaining.=

 

2) System Architecture: = this set of documents will provide a description of the architecture buildi= ng blocks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data= Plane: this document will describe on the wire data plane encapsulation in= support of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this d= ocument will address service chaining operation, monitoring and troubleshoo= ting including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are rea= lized.

 

Proposed Milestones:

 

Dec 2013 Request publica= tion of an Informational document defining the Network Service Chaining pro= blem statement to the IESG

 

Mar 2014 Request publica= tion of informational documents defining the system architecture including = protocol requirements and framework to the IESG=

 

May 2014 Request publica= tion of a Standards Track document specifying the data-plane (including met= adata) for Service Chaining to IESG<= /span>

 

May 2014 Request publica= tion of an informational document specifying Service Chaining Control Plane= requirements to IESG

 

Dec 2014 Request publica= tion of informational documents defining Service Chaining manageability req= uirements including MIBs, OAM, and information  models to IESG 

 

 

______________________= _________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

 

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A2B3Cszxema506mbschi_-- From kgray@juniper.net Thu Sep 5 06:12: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 EBF7F21E80B0 for ; Thu, 5 Sep 2013 06:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 1ln3dXC4m6jk for ; Thu, 5 Sep 2013 06:12:22 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id DD4EB21F9FE5 for ; Thu, 5 Sep 2013 06:12:21 -0700 (PDT) Received: from mail162-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 13:12:21 +0000 Received: from mail162-ch1 (localhost [127.0.0.1]) by mail162-ch1-R.bigfish.com (Postfix) with ESMTP id 3DCB2140169; Thu, 5 Sep 2013 13:12:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -74 X-BigFish: VPS-74(zzbb2dI98dI9371Ic89bh936eI1454I148cI1432I15caKJ1447Ia706lzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail162-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(52604005)(51704005)(377424004)(189002)(377454003)(199002)(55784002)(24454002)(51914003)(52044002)(51856001)(19580405001)(83322001)(46102001)(19580395003)(47976001)(65816001)(47736001)(80022001)(69226001)(4396001)(49866001)(50986001)(81342001)(81542001)(74502001)(47446002)(74662001)(31966008)(83072001)(80976001)(76796001)(76786001)(36756003)(63696002)(54356001)(56776001)(74366001)(53806001)(15975445006)(54316002)(76176001)(77982001)(59766001)(77096001)(76482001)(56816003)(15202345003)(83506001)(74706001)(81816001)(74876001)(79102001)(81686001)(427584002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB082; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail162-ch1 (localhost.localdomain [127.0.0.1]) by mail162-ch1 (MessageSwitch) id 137838673918532_22826; Thu, 5 Sep 2013 13:12:19 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail162-ch1.bigfish.com (Postfix) with ESMTP id F25F44601A5; Thu, 5 Sep 2013 13:12:18 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 13:12:18 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 5 Sep 2013 13:11:56 +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.745.25; Thu, 5 Sep 2013 13:11:55 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) with mapi id 15.00.0745.000; Thu, 5 Sep 2013 13:11:55 +0000 From: Ken Gray To: "mohamed.boucadair@orange.com" , "nsc@ietf.org" Thread-Topic: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt Thread-Index: Ac6fMhIAzIOqddliRk+cqJ/CnVKw9ADv8zVgAZrASQAAKMd+4AAF/ZcA Date: Thu, 5 Sep 2013 13:11:55 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF03367C6@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 096029FF66 Content-Type: text/plain; charset="iso-8859-1" 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% Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.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, 05 Sep 2013 13:12:27 -0000 A couple in-lines back. Thanks for the response ... On 9/5/13 3:45 AM, "mohamed.boucadair@orange.com" wrote: >Hi Ken, > >Thank you for the comments. Please see inline. > >Cheers, >Med > >>-----Message d'origine----- >>De : Ken Gray [mailto:kgray@juniper.net] >>Envoy=E9 : mercredi 4 septembre 2013 16:53 >>=C0 : BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org >>Objet : Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements- >>01.txt >> >>Heya, Med. >> >>I gave it a quick read. I have the following questions/observations: >> >>REQ#2 - The document doesn't specifically say whether we're constraining >>our focus on chains that require an "externality" for each link (that is, >>ARE we assuming that each "link" will pass through a network/networked >>element e.g. Hypervisor switch) - and are thus excluding from discussion >>IPC (or RPC) mechanisms between service elements on the same device >>(which >>are much harder to detect, monitor, standardize). > >[Med] IMHO how service functions are interconnected should be excluded >from the scope. This included both the case where multiple functions are >co-located within the same device or are located in separate ones. I >added this sentence: >"Note: Communications between Service Functions co-resident on same >Network Element are considered implementation-specific. These >considerations are out of scope of the SFC specification effort." We'll probably have to agree to disagree, though it's just a nit. Seems to me that most of what will be specify/standardized this is unique ARE externalities (packet headers and discovery/registration ...metadata not so much). =3D8^) > >> >>REQ#13 is putting a constraint on the header discussion. Is this the >>right place to put that, particularly since the requirements there >>haven't >>been fully defined (yet)? > >[Med] This is mainly motivated by operational needs; the constraint on >the header is just a side effect. From an operational standpoint, this is >an important requirement to keep in mind. A typical complications that >may arise is when legacy nodes (no aware of the SFC procedure) discard >fragmented packets. > >> >>REQ#15 - while I fully appreciate your desire to avoid another 80+ part >>email thread on whether MPLS is an overlay, I think you make your point >>well enough in the main assertion and part "b" is actually redundant. >>8^) > >[Med] I see your point. We initially listed those sub-bullets to provide >additional information and make sure the main requirements is clear >enough. Will consider how to make this better. Thanks. > >> >>REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22 has >>to be a MUST (I think the need for downstream reclassification can be a >>normal outcome of the function of an individual service element as it >>potentially transforms a header - unless your argument is that we should >>avoid this wherever possible by imbedding a clue in the header - in which >>case we run into issues with "non-speakers" or legacy devices). > >[Med] In the new version to be published, we removed REQ#19 (a) and >maintained the normative language in REQ#22 as it is. A simple model >consists to have one single SFC classification of the packet, and then >the packet will be forwarding on a per SF Map Index. In such model, no >SFC re-classification would be required. Unlike this simple model, there >are voices arguing a SFC re-classification may be needed. We will have >the opportunity to tweak the normative language. Okay, we can leave it for later. >=20 > >> >>REQ#23 seems to obviate the use of simple route NH manipulation to create >>a chain (this is destination address based). So, to be inclusive, I >>think >>that has to be a SHOULD. > >[Med] The destination address this REQ is referring to is the destination >address of the original packet. We made this change to make: > > REQ#23: The solution MUST be able to forward the traffic between two > Service Functions (involved in the same Service Function > Chain) without relying on the original destination address > in a data packet. > >Better? Or you still think this should be modified? Thanks. Better. >=20 > >> >>REQ#25 seems to be difficult to require if you don't dictate how the >>chain >>is formed (how the forwarding is instantiated) and should be worded more >>like REQ#29, IMO. > >[Med] We changed the wording for this REQ to make it more specific. The >new wording to appear in the new version is as follow: > > REQ#25: The solution MUST allow for Operations, Administration, and > Maintenance (OAM) features [RFC6291]. In particular, > > a. Support means to verify the completion of the forwarding > actions derived from the contents of the SF Map until > the Border Node is reached (see Section 3.4.1 of > [RFC5706]). > > b. Support means to ensure coherent classification rules > are installed to all SFC Classifiers. > > c. Support means to correlate between the classification > policies and observed forwarding actions. > > d. Support in-band liveness and functionality checking of > instantiated Service Function Chains. > >Better? Yes. > >> >>REQ#30 I think you're trying to say that static definition/topology of >>service functions SHOULD be supported but dynamic MUST (not that every >>element has to support dynamic discovery but that the overall goal of the >>ongoing architecture should be dynamic with static augmentation for >>corner/legacy cases) ...which would be more in alignment with the tenor >>of >>REQ#32. > >[Med] We used SHOULD in this REQ mainly because the solution can be >enabled in some contexts without requiring dynamic discovery means. >Promoting this REQ to "MUST" would assume this functionality is mandatory >to deploy the chaining solution...which is not true. I think we're saying the same thing, just getting hung on the nomenclature specific to a goal vs an implementation. To me, the goal must be to develop a dynamic mechanism (otherwise, what's the point) while allowing static/manual. When you flip it to implementation, then I'd agree with your point of view. > >> >>Thanks for kicking it off and reading this drivel ... >> >> >> >> >> >> >>On 8/27/13 2:58 AM, "mohamed.boucadair@orange.com" >> wrote: >> >>>Dear all, >>> >>>A new version of the requirements draft is now available online. The >>>main >>>changes in this new version are as follows: >>> >>>* Enrich the document with inputs from >>>draft-li-service-chaining-requirements >>>* Welcome authors of draft-li-service-chaining-requirements as >>>co-authors >>>* Add new security-related requirements. >>>* Re-order the requirements >>> >>>A more detailed diff is available at: >>>http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requiremen= ts >>>-0 >>>1.txt >>> >>>Feel free to share your comments, suggestions and text contributions on >>>the list or direct them to the authors. >>> >>>Cheers, >>>Med >>> >>>-----Message d'origine----- >>>De : i-d-announce-bounces@ietf.org >>>[mailto:i-d-announce-bounces@ietf.org] >>>De la part de internet-drafts@ietf.org >>>Envoy=E9 : jeudi 22 ao=FBt 2013 14:21 >>>=C0 : i-d-announce@ietf.org >>>Objet : I-D Action: draft-boucadair-chaining-requirements-01.txt >>> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> >>> >>> Title : Requirements for Service Function Chaining >>> Author(s) : Mohamed Boucadair >>> Christian Jacquenet >>> Yuanlong Jiang >>> Hongyu Li >>> Ron Parker >>> Filename : draft-boucadair-chaining-requirements-01.txt >>> Pages : 10 >>> Date : 2013-08-22 >>> >>>Abstract: >>> This document identifies the requirements for the Service Function >>> Chaining. >>> >>> >>> >>>The IETF datatracker status page for this draft is: >>>https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirements >>> >>>There's also a htmlized version available at: >>>http://tools.ietf.org/html/draft-boucadair-chaining-requirements-01 >>> >>>A diff from the previous version is available at: >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirements= -0 >>>1 >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission >>>until the htmlized version and diff are available at tools.ietf.org. >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>_______________________________________________ >>>I-D-Announce mailing list >>>I-D-Announce@ietf.org >>>https://www.ietf.org/mailman/listinfo/i-d-announce >>>Internet-Draft directories: http://www.ietf.org/shadow.html >>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >>> >>> >> > > > From linda.dunbar@huawei.com Thu Sep 5 07:24: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 9142711E80EC for ; Thu, 5 Sep 2013 07:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.405, 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 ER6DcNmnRuDS for ; Thu, 5 Sep 2013 07:24:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B16DC21E80B0 for ; Thu, 5 Sep 2013 07:24:23 -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.5-GA FastPath queued) with ESMTP id AVB91132; Thu, 05 Sep 2013 14:24:18 +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.146.0; Thu, 5 Sep 2013 15:23:58 +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.146.0; Thu, 5 Sep 2013 15:24:15 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Thu, 5 Sep 2013 07:24:05 -0700 From: Linda Dunbar To: Thomas Nadeau , Jiangyuanlong Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqjI9rXOZ2m/vBEG19boxgCQmQ5m3MjeQ Date: Thu, 5 Sep 2013 14:24:04 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9DB59@dfweml509-mbx.china.huawei.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9@szxema506-mbs.china.huawei.com> <62FEC71F-777B-4B7D-B8E2-FF84FA208D23@lucidvision.com> In-Reply-To: <62FEC71F-777B-4B7D-B8E2-FF84FA208D23@lucidvision.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.59] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B9DB59dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 14:24:40 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645B9DB59dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like Tom's suggestion of splitting OAM from Manageability. I see Manageab= ility as ways to conveniently configure the chaining of services, whereas O= AM is more for monitoring and trouble shooting. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Nadeau Sent: Thursday, September 05, 2013 7:20 AM To: Jiangyuanlong Cc: nsc@ietf.org; Jim Guichard (jguichar); Zhuhengjun Subject: Re: [nsc] NSC Working Group Charter Proposal On Sep 4, 2013:11:41 PM, at 11:41 PM, Jiangyuanlong > wrote: Hi Jim, Thanks for the hard work on drafting the charter. In the proposed NSC charter, it says: "4) Manageability: this document will address service chaining operation, m= onitoring and troubleshooting including relevant service chaining models su= ch as MIBs or YANG modules, along with relevant OAM capabilities and how th= ey are realized." Firstly, the relation of "operation, monitoring and troubleshooting" and "O= AM" is not very clear to me. Secondly, though YANG module is a good piece of work, I don't think it shou= ld be put in the list of NSC deliverables, since YANG related specification= used to belong to OPS area. We can transfer it to OPS (after information m= odels are mature enough) and the expertise should be readily found there. It is included because Yang modules, like MIB modules, are very a= ppropriate for any working group to deliver as part of their work items. I would like to propose the following texts: 4) Manageability: this document will address service chaining management in= cluding relevant service chaining MIBs and information models, and service = chaining OAM. Splitting OAM into a separate item seems another option as it mainly solves= traceability of service chaining. Finally, the proposed timeline is not very practical IMHO (plus one year f= or each item in the Milestone?). The timelines are not set in stone and are ultimately decided by = the ADs; they are just place holders now. --Tom Regards, Yuanlong From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Wednesday, September 04, 2013 12:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological cha= nges leading to mostly-static service definitions. New service insertion an= d deployment techniques must enable the concept of service functions as sha= red resources, and enable the linkage of these resources using service chai= ns that represent the abstracted view of the required service functions, an= d define the order in which they should be applied. When a service chain is= instantiated in a network, specific instances of service functions are sel= ected, and a service topology is created and used for forwarding packets th= rough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mod= els to IESG _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_4A95BA014132FF49AE685FAB4B9F17F645B9DB59dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like Tom’s sugges= tion of splitting OAM from Manageability. I see Manageability as ways to co= nveniently configure the chaining of services, whereas OAM is more for monitoring and trouble shooting.

 <= /p>

Linda

 <= /p>

From: nsc-boun= ces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thomas Nadeau
Sent: Thursday, September 05, 2013 7:20 AM
To: Jiangyuanlong
Cc: nsc@ietf.org; Jim Guichard (jguichar); Zhuhengjun
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

 

On Sep 4, 2013:11:41 PM, at 11:41 PM, Jiangyuanlong = <jiangyuanlong@huawei.com> wrote:



Hi Jim,

 

Thanks for the hard work on drafting th= e charter.

 

In the proposed NSC charter, it says:

 

“4) Manageability: this document = will address service chaining operation, monitoring and troubleshooting inc= luding relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are realized.”

 

Firstly, the relation of “operati= on, monitoring and troubleshooting” and “OAM” is not very= clear to me.

 

Secondly, though YANG module is a good = piece of work, I don’t think it should be put in the list of NSC deli= verables, since YANG related specification used to belong to OPS area. We can transfer it to OPS (after information models are mature enoug= h) and the expertise should be readily found there.  

 

   &nb= sp;      It is included because Yang module= s, like MIB modules, are very appropriate for any working group to deliver = as part of their work items.



I would like to propose the following t= exts:

 

4) Manageability: this document will ad= dress service chaining management including relevant service chaining MIBs = and information models, and service chaining OAM.

 

Splitting OAM into a separate item seem= s another option as it mainly solves traceability of service chaining.

 

Finally,  the proposed timeline is= not very practical IMHO (plus one year for each item in the Milestone?).

 

   &nb= sp;      The timelines are not set in stone= and are ultimately decided by the ADs; they are just place holders now.

 

   &nb= sp;      --Tom



 

Regards,

Yuanlong

 <= /p>

From: nsc-bounces@ietf.org=  [mailto:nsc-<= a href=3D"mailto:bounces@ietf.org">bounces@iet= f.org] On Behalf Of Jim Guicha= rd (jguichar)
Sent: Wednesday, S= eptember 04, 2013 12:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC= Working Group Charter Proposal

 

Greetings,

 

As we look forward to the formation of = a working group that will focus on network service chaining, I would like t= o propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area AD's. The following= is a first draft of the charter and I invite you to actively participate a= nd provide inputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion and deployme= nt techniques have not evolved to meet modern network architectures and do = not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, storage= , and applications, have all undergone significant change in recent years: = virtualization, network overlays, and orchestration are increasingly the no= rm. All of these have profound effects on network and services design.

 

Today, deploying new services, or makin= g changes to existing services, often requires network topology changes. Ad= ding and removing service functions&n= bsp; is a complex, risky task, that is tied to operationalizing topological cha= nges leading to mostly-static service definitions. New service insertion an= d deployment techniques must enable the concept of service functions as sha= red resources, and enable the linkage of these resources using service chains that represent the abstracted view= of the required service functions, and define the order in which they shou= ld be applied. When a service chain is instantiated in a network, specific = instances of service functions are selected, and a service topology is created and used for forwarding packet= s through the service chain.

 

A basic service chain might simply util= ize an existing overlay technology to force traffic through the necessary s= ervice functions. However, additional information enables a richer service chain for more advanced composite services. For example, = shared information (e.g., the result of classification) can be used to offl= oad service function processing or inform other service functions about inf= ormation that would otherwise be hard to glean. 

 

The Network Service Chaining (NSC) work= ing group focuses on new approaches to service insertion and deployment, pr= oviding a framework for the construction of services built using service chains. The WG focuses on the necessary protocols for the cr= eation of service chains, and the passing of metadata from the network to s= ervice functions, and between service functions. When possible, the WG will= extend existing protocols to provide service chaining functionality, and any protocol extensions will be review= ed by both the Network Service Chaining WG and by the WG responsible for th= e protocol being extended.  

 

Specifically, the Network Service Chain= ing WG is chartered to deliver the following work items: <= /o:p>

 

1) Problem Statement: this document wil= l provide a summary of the problem space to be addressed by the Network Ser= vice Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and definitions = for Network Service Chaining.

 

2) System Architecture: this set of doc= uments will provide a description of the architecture building blocks and t= heir relationships including interconnection, placement of capabilities, and security models, as well as requirements on the contr= ol mechanisms and data plane encapsulation.

 

3) Service Chaining Data Plane: this do= cument will describe on the wire data plane encapsulation in support of (2)= .  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this document will ad= dress service chaining operation, monitoring and troubleshooting including = relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are realized.

 

Proposed Milestones:<= /p>

 

Dec 2013 Request publication of an Info= rmational document defining the Network Service Chaining problem statement = to the IESG

 

Mar 2014 Request publication of informa= tional documents defining the system architecture including protocol requir= ements and framework to the IESG

 

May 2014 Request publication of a Stand= ards Track document specifying the data-plane (including metadata) for Serv= ice Chaining to IESG

 

May 2014 Request publication of an info= rmational document specifying Service Chaining Control Plane requirements t= o IESG

 

Dec 2014 Request publication of informa= tional documents defining Service Chaining manageability requirements inclu= ding MIBs, OAM, and information = models to IESG 

 

 

_____________________________________= __________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645B9DB59dfweml509mbxchi_-- From linda.dunbar@huawei.com Thu Sep 5 07:45:43 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A367921E80C1 for ; Thu, 5 Sep 2013 07:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.386, 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 UPd10u8-EiSQ for ; Thu, 5 Sep 2013 07:45:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 406F821E8096 for ; Thu, 5 Sep 2013 07:45:26 -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.5-GA FastPath queued) with ESMTP id AWY03810; Thu, 05 Sep 2013 14:45:24 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 15:44:55 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 15:45:12 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Thu, 5 Sep 2013 07:45:07 -0700 From: Linda Dunbar To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGA= Date: Thu, 5 Sep 2013 14:45:07 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9DBA7@dfweml509-mbx.china.huawei.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <68B171751455884590F8E38E96416F363F676C32@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F676C32@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.192.11.59] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B9DBA7dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 14:45:44 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645B9DBA7dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, This version hasn't addressed the comments on Bullet 3 of requiring a singl= e encapsulation being too limiting or may not even be realistic. Several people on other email thread (i.e. "outcome of NSC BoF") stated tha= t the "services" in the NSC context can be Layer 2-3 services or Layer 4-7 = services. For Layer 2-3 services, IETF has standardized Explicit Routing Object (ERO)= to dictate data flows traversing a pre-determined sequence of Layer 3 node= s, or using BGP control plane to dictate next hop. I am not advocating that policy based routing (e.g. ERO) should be in the = scope of NSC. But I can't see how the current proposed scope excludes tho= se policy based routing schemes that have been deployed in the industry. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Thursday, September 05, 2013 6:57 AM To: nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Greetings, I have updated the charter as follows based on all comments received thus f= ar. There have been lots of inputs and this charter may not reflect all of = them (hopefully it is pretty close). Please take time to review and continu= e the discussion. Proposed NSC WG Charter - Take two Existing service insertion and deployment techniques fail to address new ch= allenging requirements raised by the introduction of emerging technologies = such as multi-tenancy, virtualization, elasticity, and rich classification.= Networks, servers, and other storage technologies, let alone applications,= have all undergone significant change in recent years: virtualization, net= work overlays, and orchestration have increasingly become techniques that c= ount and sometimes prevail. All of these have profound effects on network a= nd services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to massively static configuration procedures for network servic= e delivery or update purposes. The structuring and the delivery of new netw= ork services assume the (smart) combination of various service functions as= shared resources, and enable the linkage of these resources using service = chains that represent the abstracted view of the required service functions= , and define the order in which they should be invoked. Such (smart) combin= ations could be made of heterogeneous service functions which may act at va= rious layers of a protocol stack (network layer, application layer, etc). W= hen a service chain is instantiated in a network, specific instances of ser= vice functions are selected, and a service topology is created and used for= forwarding packets according to the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information that is shared across a subset of service functions may enabl= e a richer service chain for more advanced composite services. For example,= shared information, such as the results of a classification function, may = be passed to downstream service functions to enable the offloading of servi= ce function processing or to share information that would otherwise be hard= to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to network service structuring, insertion, and deployment, providing a fram= ework for the construction of services built using service function chains.= The WG focuses on the necessary protocols for the creation of service chai= ns, and the transmission of network and service-specific information from t= he network to service functions, and between service functions. When possib= le, the WG will extend existing protocols to provide service chaining funct= ionality, and any protocol extensions will be reviewed by both the Network = Service Chaining WG and by the WG responsible for the protocol being extend= ed. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including example h= igh-level use cases. Additionally, the WG will normalize on nomenclature a= nd definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining management in= support of (2) including relevant service chaining MIBs and information mo= dels, and service chaining OAM. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including context data) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of Informational document(s) defining Network = Service Chaining use cases to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability including MIBs, OAM, and information models to IESG --_000_4A95BA014132FF49AE685FAB4B9F17F645B9DBA7dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim,

 <= /p>

This version hasn’t= addressed the comments on Bullet 3 of requiring a single encapsulation bei= ng too limiting or may not even be realistic.

 <= /p>

Several people on other e= mail thread (i.e. “outcome of NSC BoF”) stated that the “= services” in the NSC context can be Layer 2-3 services or Layer 4-7 s= ervices.

 <= /p>

For Layer 2-3 services, I= ETF has standardized Explicit Routing Object (ERO) to dictate data flows tr= aversing a pre-determined sequence of Layer 3 nodes, or using BGP control plane to dictate next hop.  

 <= /p>

I am not advocating that = policy based routing (e.g. ERO)  should be in the scope of NSC.  = But I can’t see how the current proposed scope excludes  those p= olicy based routing schemes that have been deployed in the industry. =

 <= /p>

Linda

 <= /p>

 <= /p>

 <= /p>

From: nsc-boun= ces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, September 05, 2013 6:57 AM
To: nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

Greetings,=

 

I have updated the charter a= s follows based on all comments received thus far. There have been lots of = inputs and this charter may not reflect all of them (hopefully it is pretty close). Please take time to review and continue the discussio= n.

 

Proposed NSC WG Charter &= #8211; Take two

 

Existing service insertion a= nd deployment techniques fail to address new challenging requirements raise= d by the introduction of emerging technologies such as multi-tenancy, virtualization, elasticity, and rich classification. Networks, servers, an= d other storage technologies, let alone applications, have all undergone si= gnificant change in recent years: virtualization, network overlays, and orc= hestration have increasingly become techniques that count and sometimes prevail. All of these have profound ef= fects on network and services design.

 

Today, deploying new service= s, or making changes to existing services, often requires network topology = changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o massively static configuration procedures for network service delivery or= update purposes. The structuring and the delivery of new network services = assume the (smart) combination of various service functions as shared resources, and enable the linkage of t= hese resources using service chains that represent the abstracted view of t= he required service functions, and define the order in which they should be= invoked. Such (smart) combinations could be made of heterogeneous service functions which may act at various = layers of a protocol stack (network layer, application layer, etc). When a = service chain is instantiated in a network, specific instances of service f= unctions are selected, and a service topology is created and used for forwarding packets according to the servi= ce chain.

 

A basic service chain might = simply utilize an existing overlay technology to force traffic through the = necessary service functions. However, additional information that is shared across a subset of service functions may enable a richer se= rvice chain for more advanced composite services. For example, shared infor= mation, such as the results of a classification function, may be passed to = downstream service functions to enable the offloading of service function processing or to share informati= on that would otherwise be hard to glean. 

 

The Network Service Chaining= (NSC) working group focuses on new approaches to network service structuri= ng, insertion, and deployment, providing a framework for the construction of services built using service function chains. The WG f= ocuses on the necessary protocols for the creation of service chains, and t= he transmission of network and service-specific information from the networ= k to service functions, and between service functions. When possible, the WG will extend existing protocols to= provide service chaining functionality, and any protocol extensions will b= e reviewed by both the Network Service Chaining WG and by the WG responsibl= e for the protocol being extended.  

 

Specifically, the Network Se= rvice Chaining WG is chartered to deliver the following work items: 

 

1) Problem Statement: this d= ocument will provide a summary of the problem space to be addressed by the = Network Service Chaining WG including example high-level use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.

 

2) System Architecture: this= set of documents will provide a description of the architecture building b= locks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pla= ne: this document will describe on the wire data plane encapsulation in sup= port of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docum= ent will address service chaining management in support of (2) including re= levant service chaining MIBs and information models, and service chaining OAM.

 

Proposed Milestones:

 

Dec 2013 Request publication= of an Informational document defining the Network Service Chaining problem= statement to the IESG

 

Mar 2014 Request publication= of informational documents defining the system architecture including prot= ocol requirements and framework to the IESG

 

May 2014 Request publication= of a Standards Track document specifying the data-plane (including context= data) for Service Chaining to IESG

 

May 2014 Request publication= of an informational document specifying Service Chaining Control Plane req= uirements to IESG

 

Dec 2014 Request publication= of Informational document(s) defining Network Service Chaining use cases t= o IESG

 

Dec 2014 Request publication= of informational documents defining Service Chaining manageability includi= ng MIBs, OAM, and information models to IESG 

 

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645B9DBA7dfweml509mbxchi_-- From mohamed.boucadair@orange.com Thu Sep 5 07:50: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 C52E821E80FB for ; Thu, 5 Sep 2013 07:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rocMA+eZ0wUN for ; Thu, 5 Sep 2013 07:50:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 098F621E80C1 for ; Thu, 5 Sep 2013 07:50:52 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E7D1632413A; Thu, 5 Sep 2013 16:50:50 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C078135C0B9; Thu, 5 Sep 2013 16:50:50 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 5 Sep 2013 16:50:50 +0200 From: To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Date: Thu, 5 Sep 2013 16:50:49 +0200 Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1Ee0QgADYD4CAAVD8UA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EF06D03B0@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F675870@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F675870@xmb-rcd-x01.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF06D03B0PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.5.135415 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 14:50:59 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF06D03B0PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jim, I have nothing against the word "metadata" itself. You can maintain it if you prefer, but it seems odd to call only that techn= ical aspect for that milestone. Cheers, Med De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mercredi 4 septembre 2013 19:37 =C0 : BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org Objet : Re: NSC Working Group Charter Proposal Hi Med, Comment inline .. From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Wednesday, September 4, 2013 10:05 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: NSC Working Group Charter Proposal Hi Jim, Thank you for preparing the text. I fully agree that, for the sake of interoperability, one standard track so= lution must be specified by the working group. I'm fully supportive to ment= ion this in the charter and avoid that during the lifetime of the working g= roup multiple solutions are envisaged. I have some comments about the proposed deliverables and the proposed timin= g: (1) I don't think it is a good idea to split the requirements into multiple= documents. For the sake of consistency and also to have the big picture, I= suggest only one single document be chartered to record the requirements. = The requirements document should include functional requirements, manageabi= lity requirements (as per RFC5706) and security requirements. The full set = of requirements should be taken into account during the design phase. (2) The specification effort should start once the requirements are almost = stable, not before. (3) I would remove the word "metadata" from the milestones. Jim> this wording is directly associated to REQ#24 of draft-boucadair-chain= ing-requirements so would a replacement of "metadata" with "context data" w= ork for you? If not please suggest an alternative, other than removal ;-). (4) I personally don't see a value to add dedicated items for detailed use = cases. There is already an undergoing effort in other fora; no need to have= redundant effort in this space. Having an abstract description level in th= e Problem Statement is sufficient IMHO. (5) I suggest to add a "Analysis and Design Choices" document: Details rate= d to design motivations and justifications will be recorded in the analysis= document while the specification document(s) focuses exclusively on the sp= ecification part. Past experience has shown that some questions are raised = multiple times during the lifetime of the wg and it is not sometimes obviou= s to find where the decision was made and for what reason. This kind of det= ails are hard (sometime) to find: either you need to check mailing list arc= hives, or contact the authors. I see the design analysis document as a form= al tool to record the consensus on controversial design issues. The documen= t can also answer to "why not my favourite solution" solve the problem(s). (6) We don't know at this stage how many specification documents will be ne= eded. Perhaps only one Standard Track document will be required. I suggest = we leave the decision on the exact number of Standard Track documents open. To sum up: my suggestion is to go for this set of deliverables: (a) Problem Statement document (b) Framework document (terminology, functional elements, architecture, and= overall procedure) (c) Requirements document (d) Design Analysis document (e) Specification document(s) I wouldn't object if the first charter of the future WG covers only items (= a) to (d). An updated charter can be envisaged once the future WG has more = visibility on the detailed set of specification documents. Cheers, Med De : nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] De la part de Jim Guichard (jguichar) Envoy=E9 : mardi 3 septembre 2013 18:01 =C0 : nsc@ietf.org Objet : [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_94C682931C08B048B7A8645303FDC9F36EF06D03B0PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jim,=

 

You can maintain it if you prefer, but it se= ems odd to call only that technical aspect for that milestone. <= /span>

 

Cheers,

Med

<= p class=3DMsoNormal> 

De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mercredi 4 septembre 2013 19:37
=C0 : BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org
Objet : = Re: NSC Working Group Charter Proposal

 

Hi Me= d,

 

Comment inline ..

 

Hi Jim,

 

Thank you for preparing t= he text.

 

<= p class=3DMsoNormal>I fully agree that, for the sake of interoperability, one= standard track solution must be specified by the working group. I’m = fully supportive to mention this in the charter and avoid that during the l= ifetime of the working group multiple solutions are envisaged.

 

I ha= ve some comments about the proposed deliverables and the proposed timing:

&= nbsp;

(1) I don’t think it is a good idea to split the requirements i= nto multiple documents. For the sake of consistency and also to have the bi= g picture, I suggest only one single document be chartered to record the re= quirements. The requirements document should include functional requirement= s, manageability requirements (as per RFC5706) and security requirements. T= he full set of requirements should be taken into account during the design = phase.

 

(2) The specification effort should start once the requiremen= ts are almost stable, not before.

 =

(3) I would remove the word “= ;metadata” from the milestones.

 

(4) I persona= lly don’t see a value to add dedicated items for detailed use cases. = There is already an undergoing effort in other fora; no need to have redund= ant effort in this space. Having an abstract description level in the Probl= em Statement is sufficient IMHO.

 <= o:p>

(5) I suggest to add a “Analy= sis and Design Choices” document: Details rated to design motivations= and justifications will be recorded in the analysis document while the spe= cification document(s) focuses exclusively on the specification part. Past = experience has shown that some questions are raised multiple times during t= he lifetime of the wg and it is not sometimes obvious to find where the dec= ision was made and for what reason. This kind of details are hard (sometime= ) to find: either you need to check mailing list archives, or contact the a= uthors. I see the design analysis document as a formal tool to record the c= onsensus on controversial design issues. The document can also answer to &#= 8220;why not my favourite solution” solve the problem(s).

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'>(6)= We don’t know at this stage how many specification documents will be= needed. Perhaps only one Standard Track document will be required. I sugge= st we leave the decision on the exact number of Standard Track documents op= en.

 

To sum up: my suggestion is to go for this set of deliverables:=

 

(a) Problem Statement document

(b) Framework document (terminology,= functional elements, architecture, and overall procedure)

(c) Re= quirements document

(d) Design Analysis document

(e) Sp= ecification document(s)

 =

I wouldn’t object if the fir= st charter of the future WG covers only items (a) to (d). An updated charte= r can be envisaged once the future WG has more visibility on the detailed s= et of specification documents.

 

Cheers,

Med

=  

 

De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]= De la part de Jim Guichard (jguichar)
Envoy=E9 : mar= di 3 septembre 2013 18:01
=C0 : nsc@ietf.org
Objet : [nsc] NSC = Working Group Charter Proposal

&n= bsp;

Greetings,

 

As we look forward to the format= ion of a working group that will focus on network service chaining, I would= like to propose a discussion on this alias to try and reach consensus on a= n initial charter as requested by the routing area AD's. The following is a= first draft of the charter and I invite you to actively participate and pr= ovide inputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion and deployment techniques have not evo= lved to meet modern network architectures and do not reflect multi-tenancy,= virtualization, elasticity, rich classification, and other network require= ments. Networks, servers, storage, and applications, have all undergone sig= nificant change in recent years: virtualization, network overlays, and orch= estration are increasingly the norm. All of these have profound effects on = network and services design.<= /span>

 

Tod= ay, deploying new services, or making changes to existing services, often r= equires network topology changes. Adding and removing service functions is = a complex, risky task, that is tied to operationalizing topological changes= leading to mostly-static service definitions. New service insertion and de= ployment techniques must enable the concept of service functions as shared = resources, and enable the linkage of these resources using service chains t= hat represent the abstracted view of the required service functions, and de= fine the order in which they should be applied. When a service chain is ins= tantiated in a network, specific instances of service functions are selecte= d, and a service topology is created and used for forwarding packets throug= h the service chain.

 

A basic ser= vice chain might simply utilize an existing overlay technology to force tra= ffic through the necessary service functions. However, additional informati= on enables a richer service chain for more advanced composite services. For= example, shared information (e.g., the result of classification) can be us= ed to offload service function processing or inform other service functions= about information that would otherwise be hard to glean. 

 

The Network Service Chaining (NSC) working = group focuses on new approaches to service insertion and deployment, provid= ing a framework for the construction of services built using service chains= . The WG focuses on the necessary protocols for the creation of service cha= ins, and the passing of metadata from the network to service functions, and= between service functions. When possible, the WG will extend existing prot= ocols to provide service chaining functionality, and any protocol extension= s will be reviewed by both the Network Service Chaining WG and by the WG re= sponsible for the protocol being extended.  

 =

Specifically, the Network Service Chaining WG is charter= ed to deliver the following work items: 

 

1) Problem Statement: this document will provide a summary of= the problem space to be addressed by the Network Service Chaining WG inclu= ding terminology and sample use cases.  Additionally, the WG will norm= alize on nomenclature and definitions for Network Service Chaining.<= span style=3D'color:black'>

 

<= /div>

2) System Architecture: this set of doc= uments will provide a description of the architecture building blocks and t= heir relationships including interconnection, placement of capabilities, an= d security models, as well as requirements on the control mechanisms and da= ta plane encapsulation.

 

3) Ser= vice Chaining Data Plane: this document will describe on the wire data plan= e encapsulation in support of (2).  A single encapsulation will be sel= ected in order to enable interoperability of data plane components.<= span style=3D'color:black'>

 

<= /div>

4) Manageability: this document will ad= dress service chaining operation, monitoring and troubleshooting including = relevant service chaining models such as MIBs or YANG modules, along with r= elevant OAM capabilities and how they are realized.

 = ;

Proposed Milestones:=

 

Dec 2013 Request publication of an Informational document defining= the Network Service Chaining problem statement to the IESG

 

Mar 2014 Request publication of informational d= ocuments defining the system architecture including protocol requirements a= nd framework to the IESG

 

May 20= 14 Request publication of a Standards Track document specifying the data-pl= ane (including metadata) for Service Chaining to IESG

&nb= sp;

May 2014 Request publication of an informational docu= ment specifying Service Chaining Control Plane requirements to IESG<= span style=3D'color:black'>

 

<= /div>

Dec 2014 Request publication of informa= tional documents defining Service Chaining manageability requirements inclu= ding MIBs, OAM, and information models to IESG 

&nbs= p;

 

= --_000_94C682931C08B048B7A8645303FDC9F36EF06D03B0PUEXCB1Bnante_-- From mohamed.boucadair@orange.com Thu Sep 5 07:56: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 86C5321E8104 for ; Thu, 5 Sep 2013 07:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOKp2nOFaSzK for ; Thu, 5 Sep 2013 07:56:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8A411E80EC for ; Thu, 5 Sep 2013 07:56:32 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id A7F012DC729; Thu, 5 Sep 2013 16:56:31 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 89F1E23813C; Thu, 5 Sep 2013 16:56:31 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 5 Sep 2013 16:56:31 +0200 From: To: "Paul Quinn (paulq)" Date: Thu, 5 Sep 2013 16:56:29 +0200 Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1Ee0QgAEeZYCAAQzVsA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EF06D03BB@PUEXCB1B.nanterre.francetelecom.fr> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF06D03BBPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 14:56:55 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF06D03BBPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul, Please see inline. Cheers, Med De : Paul Quinn (paulq) [mailto:paulq@cisco.com] Envoy=E9 : mercredi 4 septembre 2013 19:49 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Jim Guichard (jguichar); nsc@ietf.org Objet : Re: [nsc] NSC Working Group Charter Proposal Hi Med, Comments inline... Thanks! Paul On Sep 4, 2013, at 7:05 AM, mohamed.boucadair@orange.com wrote: Hi Jim, Thank you for preparing the text. I fully agree that, for the sake of interoperability, one standard track so= lution must be specified by the working group. I'm fully supportive to ment= ion this in the charter and avoid that during the lifetime of the working g= roup multiple solutions are envisaged. I have some comments about the proposed deliverables and the proposed timin= g: (1) I don't think it is a good idea to split the requirements into multiple= documents. For the sake of consistency and also to have the big picture, I= suggest only one single document be chartered to record the requirements. = The requirements document should include functional requirements, manageabi= lity requirements (as per RFC5706) and security requirements. The full set = of requirements should be taken into account during the design phase. (2) The specification effort should start once the requirements are almost = stable, not before. (3) I would remove the word "metadata" from the milestones. (4) I personally don't see a value to add dedicated items for detailed use = cases. There is already an undergoing effort in other fora; no need to have= redundant effort in this space. Having an abstract description level in th= e Problem Statement is sufficient IMHO. (5) I suggest to add a "Analysis and Design Choices" document: Details rate= d to design motivations and justifications will be recorded in the analysis= document while the specification document(s) focuses exclusively on the sp= ecification part. Past experience has shown that some questions are raised = multiple times during the lifetime of the wg and it is not sometimes obviou= s to find where the decision was made and for what reason. This kind of det= ails are hard (sometime) to find: either you need to check mailing list arc= hives, or contact the authors. I see the design analysis document as a form= al tool to record the consensus on controversial design issues. The documen= t can also answer to "why not my favourite solution" solve the problem(s). PQ> This space is moving quickly, with a lot of vendor and operator activi= ty. We need this WG to be at the forefront of service chaining, consequent= ly, we should focus on a few, focused deliverables. Between the problem st= atement and the requirements documents (along with use cases as needed), we= have plenty to drive the designs. [Med] As I mentioned above, I don't see a need to have detailed use case do= cuments (this is already done in other for a). We will need anyway some kin= d of analysis to agree on the design choice as I'm naively assuming that th= e group will be open to other proposals than what we have on the table and = there will be a need to answer to "why not my favorite approach". The analy= sis document is a tool to help in advancing the specification effort. In or= der to better see what I have in mind for the analysis document, you may re= fer to this effort we initiated with Ron: http://tools.ietf.org/html/draft-= boucadair-chaining-design-analysis-00. (6) We don't know at this stage how many specification documents will be ne= eded. Perhaps only one Standard Track document will be required. I suggest = we leave the decision on the exact number of Standard Track documents open. PQ> I think the current charter defines the one we know we need now. This= can certainly certainly evolve over time but the WG must be chartered to d= eliver protocol documents to be truly effective at driving interoperability= . To sum up: my suggestion is to go for this set of deliverables: (a) Problem Statement document (b) Framework document (terminology, functional elements, architecture, and= overall procedure) (c) Requirements document (d) Design Analysis document (e) Specification document(s) I wouldn't object if the first charter of the future WG covers only items (= a) to (d). An updated charter can be envisaged once the future WG has more = visibility on the detailed set of specification documents. Cheers, Med De : nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] De la part de Jim Guichard (jguichar) Envoy=E9 : mardi 3 septembre 2013 18:01 =C0 : nsc@ietf.org Objet : [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_94C682931C08B048B7A8645303FDC9F36EF06D03BBPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

Please see inline.

Cheers,<= /o:p>

Med

 

<= b>De : Paul Quinn (paulq) [mailto:paulq@cisco.com]
= Envoy=E9 : mercredi 4 septembre 2013 19:49
=C0 := BOUCADAIR Mohamed IMT/OLN
Cc : Jim Guichard (jguichar); nsc= @ietf.org
Objet : Re: [nsc] NSC Working Group Charter Propos= al

 <= /p>

Hi Med,

 

Comments inline…

 

Thanks!

Paul

 

<= div>

On Sep 4, 2013, at 7:05 AM, mohamed.boucadair@orange.com wrote:=



Hi Jim,

= &n= bsp;

Thank you for prepa= ring the text.

 

I fully agree that, for th= e sake of interoperability, one standard track solution must be specified b= y the working group. I’m fully supportive to mention this in the char= ter and avoid that during the lifetime of the working group multiple soluti= ons are envisaged.

 = ;

I have some comments a= bout the proposed deliverables and the proposed timing:

 

(1) I don’t think it is a good idea to split the requi= rements into multiple documents. For the sake of consistency and also to ha= ve the big picture, I suggest only one single document be chartered to reco= rd the requirements. The requirements document should include functional re= quirements, manageability requirements (as per RFC5706) and security requir= ements. The full set of requirements should be taken into account during th= e design phase.

 

(2) The specification eff= ort should start once the requirements are almost stable, not before.

 

<= /div>

(3) I would remove the word “metadata= 221; from the milestones.

(4) I persona= lly don’t see a value to add dedicated items for detailed use cases. = There is already an undergoing effort in other fora; no need to have redund= ant effort in this space. Having an abstract description level in the Probl= em Statement is sufficient IMHO.

 

(5) I = suggest to add a “Analysis and Design Choices” document: Detail= s rated to design motivations and justifications will be recorded in the an= alysis document while the specification document(s) focuses exclusively on = the specification part. Past experience has shown that some questions are r= aised multiple times during the lifetime of the wg and it is not sometimes = obvious to find where the decision was made and for what reason. This kind = of details are hard (sometime) to find: either you need to check mailing li= st archives, or contact the authors. I see the design analysis document as = a formal tool to record the consensus on controversial design issues. The d= ocument can also answer to “why not my favourite solution” solv= e the problem(s).

 

PQ>  This sp= ace is moving quickly, with a lot of vendor and operator activity.  We= need this WG to be at the forefront of service chaining, consequently, we = should focus on a few, focused deliverables.  Between the problem stat= ement and the requirements documents (along with use cases as needed), we h= ave plenty to drive the designs. <= /span>

[Med] As I mentioned above, I don&= #8217;t see a need to have detailed use case documents (this is already don= e in other for a). We will need anyway some kind of analysis to agree on th= e design choice as I’m naively assuming that the group will be open t= o other proposals than what we have on the table and there will be a need t= o answer to “why not my favorite approach”. The analysis docume= nt is a tool to help in advancing the specification effort. In order to bet= ter see what I have in mind for the analysis document, you may refer to thi= s effort we initiated with Ron: http://tools.ietf.org/html/draft-bo= ucadair-chaining-design-analysis-00.

<= /p>

 

(6) We don’t know at this stage how many specification= documents will be needed. Perhaps only one Standard Track document will be= required. I suggest we leave the decision on the exact number of Standard = Track documents open.

 

PQ>  I t= hink the current charter defines the one we know we need now.  This ca= n certainly certainly evolve over time but the WG must be chartered to deli= ver protocol documents to be truly effective at driving interoperability. &= nbsp;

 

 



 

To sum up: my suggestion is to go for= this set of deliverables:

 

(a) Problem S= tatement document

(b) Fr= amework document (terminology, functional elements, architecture, and overa= ll procedure)

= (c) Requirements document

(d) Design Analysis document

(e) Specification document(s)<= /p>

 

I wouldn’t object if the first charter of t= he future WG covers only items (a) to (d). An updated charter can be envisa= ged once the future WG has more visibility on the detailed set of specifica= tion documents.

 

Cheers,

Med

 

<= /div>

 

De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoy=E9 : mardi 3 septembre 2013 18:01
=C0 : nsc@ietf.org=
Objet : = ;[nsc] NSC Working Group Charter Proposal

 

Greetings,

<= p class=3DMsoNormal> 

As we look forward to the formation of a working group that will focus on= network service chaining, I would like to propose a discussion on this ali= as to try and reach consensus on an initial charter as requested by the rou= ting area AD's. The following is a first draft of the charter and I invite = you to actively participate and provide inputs into this process.

 

Proposed NSC WG Charter

 =

Existing service inserti= on and deployment techniques have not evolved to meet modern network archit= ectures and do not reflect multi-tenancy, virtualization, elasticity, rich = classification, and other network requirements. Networks, servers, storage,= and applications, have all undergone significant change in recent years: v= irtualization, network overlays, and orchestration are increasingly the nor= m. All of these have profound effects on network and services design.

 

Today, deploying new services, or = making changes to existing services, often requires network topology change= s. Adding and removing service functions is a complex, risky task, that is = tied to operationalizing topological changes leading to mostly-static servi= ce definitions. New service insertion and deployment techniques must enable= the concept of service functions as shared resources, and enable the linka= ge of these resources using service chains that represent the abstracted vi= ew of the required service functions, and define the order in which they sh= ould be applied. When a service chain is instantiated in a network, specifi= c instances of service functions are selected, and a service topology is cr= eated and used for forwarding packets through the service chain.

 

=

A basic service chain might simply util= ize an existing overlay technology to force traffic through the necessary s= ervice functions. However, additional information enables a richer service = chain for more advanced composite services. For example, shared information= (e.g., the result of classification) can be used to offload service functi= on processing or inform other service functions about information that woul= d otherwise be hard to glean. 

<= div>

 

The Network Service Chaining (NSC) working group focuses on new appr= oaches to service insertion and deployment, providing a framework for the c= onstruction of services built using service chains. The WG focuses on the n= ecessary protocols for the creation of service chains, and the passing of m= etadata from the network to service functions, and between service function= s. When possible, the WG will extend existing protocols to provide service = chaining functionality, and any protocol extensions will be reviewed by bot= h the Network Service Chaining WG and by the WG responsible for the protoco= l being extended.  

 

Spec= ifically, the Network Service Chaining WG is chartered to deliver the follo= wing work items: 

 

1) Pr= oblem Statement: this document will provide a summary of the problem space = to be addressed by the Network Service Chaining WG including terminology an= d sample use cases.  Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining.

 

2) System Architecture: this set of documents will prov= ide a description of the architecture building blocks and their relationshi= ps including interconnection, placement of capabilities, and security model= s, as well as requirements on the control mechanisms and data plane encapsu= lation.

 

3) Service Chaining D= ata Plane: this document will describe on the wire data plane encapsulation= in support of (2).  A single encapsulation will be selected in order = to enable interoperability of data plane components.

<= /div>

 

=

4) Manageability: this document will address servic= e chaining operation, monitoring and troubleshooting including relevant ser= vice chaining models such as MIBs or YANG modules, along with relevant OAM = capabilities and how they are realized.

 

Proposed Milestones:

=

 

Dec 2013 Request publication of an Informational document defining the N= etwork Service Chaining problem statement to the IESG

=

 

Mar 2014 Request publication of informational docu= ments defining the system architecture including protocol requirements and = framework to the IESG

 

May 2= 014 Request publication of a Standards Track document specifying the data-p= lane (including metadata) for Service Chaining to IESG

 

May 2014 Request publication of an informational = document specifying Service Chaining Control Plane requirements to IESG

 

Dec 2014 Request publication of = informational documents defining Service Chaining manageability requirement= s including MIBs, OAM, and information models to IESG 

 

 

_______________________________________________
= nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listi= nfo/nsc

 

= --_000_94C682931C08B048B7A8645303FDC9F36EF06D03BBPUEXCB1Bnante_-- From mohamed.boucadair@orange.com Thu Sep 5 08: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 7CB4A11E81B1 for ; Thu, 5 Sep 2013 08:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, 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 NgJKWIHxW9nv for ; Thu, 5 Sep 2013 08:03:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 90C3D21F9D44 for ; Thu, 5 Sep 2013 08:03:08 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id BDA702AD7B1; Thu, 5 Sep 2013 17:03:07 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 979B31580D3; Thu, 5 Sep 2013 17:03:07 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 5 Sep 2013 17:03:07 +0200 From: To: "Joel M. Halpern" Date: Thu, 5 Sep 2013 17:03:05 +0200 Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: Ac6pnTcN4bs5dbtTR1GXJLXN6DIWuQAquiQw Message-ID: <94C682931C08B048B7A8645303FDC9F36EF06D03C6@PUEXCB1B.nanterre.francetelecom.fr> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> <52277CE1.60805@joelhalpern.com> In-Reply-To: <52277CE1.60805@joelhalpern.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.5.132414 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 15:03:14 -0000 Hi Joel, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] >Envoy=E9=A0: mercredi 4 septembre 2013 20:33 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: Jim Guichard (jguichar); nsc@ietf.org >Objet=A0: Re: [nsc] NSC Working Group Charter Proposal > >Clipping for focus... > >On 9/4/13 10:05 AM, mohamed.boucadair@orange.com wrote: >> Hi Jim, >> >> Thank you for preparing the text. >... >> To sum up: my suggestion is to go for this set of deliverables: >> >> (a) Problem Statement document >> >> (b) Framework document (terminology, functional elements, architecture, >> and overall procedure) >> >> (c) Requirements document >> >> (d) Design Analysis document >> >> (e) Specification document(s) >> >> I wouldn't object if the first charter of the future WG covers only >> items (a) to (d). An updated charter can be envisaged once the future WG >> has more visibility on the detailed set of specification documents. >> >> Cheers, >> >> Med > >I find this list difficult to understand. And the omissions of certain >items from the previous proposal cause me personally some concern. > >Separating the problem statement, framework, requirements, and "design >analysis" produces a multiplicity of documents which will divide the WGs >efforts without, as far as I can tell, improving clarity. > >I also find the notion of a Design Analysis odd. [Med] The motivation for such analysis document are explained in the core o= f my message. But to have something concrete, what I have in mind is someth= ing close to the effort available at: http://tools.ietf.org/html/draft-bouc= adair-chaining-design-analysis-00.=20 What we need is an >architecture or design to drive the protocol effort.=20 [Med] We are in full agreement here. This is what I meant by the framework = document.=20 From where I sit, >we need to pick an approach to the problem, and document that pick. In >many ways, it is quite likely that we will have to pick simply because a >choice is needed, not because one is universally better than another. I >would strongly prefer that the focus of the document be on the actual >answer. > >Similarly, while I find use case drafts useful information for the WG to >consider, I think that arguing about which use cases we should put in an >RFC, would not be a good use of the WGs time and energy.=20 [Med] My suggestion is not charter any item for the use cases.. but provide= a high level description in the problem statement. Some >discussion of importance is inevitable as we decide which pieces of the >problem to solve well, which pieces to solve awkwardly, and which pieces >not to solve. [Med] That's part of the design considerations & analysis effort imho.=20 From jmh@joelhalpern.com Thu Sep 5 08:05: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 B264411E81B9 for ; Thu, 5 Sep 2013 08:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 QDletOqIAgEv for ; Thu, 5 Sep 2013 08:05:06 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id A154611E80EC for ; Thu, 5 Sep 2013 08:05:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id ABB901C07BB; Thu, 5 Sep 2013 08:05:02 -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 B09BD1C02FE; Thu, 5 Sep 2013 08:05:00 -0700 (PDT) Message-ID: <52289D9D.7010605@joelhalpern.com> Date: Thu, 05 Sep 2013 11:05:01 -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: Linda Dunbar References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6A29F9@szxema506-mbs.china.huawei.com> <62FEC71F-777B-4B7D-B8E2-FF84FA208D23@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645B9DB59@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9DB59@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "nsc@ietf.org" , Thomas Nadeau , Jiangyuanlong , Zhuhengjun , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 15:05:12 -0000 While it is true that manageability and OAM are two different things, that does not inevitably lead to the conclusion that we need two documents. In fact, the two are related, and my guess is that we would be better served with one document describing both. If we have to develop new OAM protocol mechanisms then that would probably mean we need separate documents. It would also suggest we are making mistakes. Yours, Joel On 9/5/13 10:24 AM, Linda Dunbar wrote: > I like Tom’s suggestion of splitting OAM from Manageability. I see > Manageability as ways to conveniently configure the chaining of > services, whereas OAM is more for monitoring and trouble shooting. > > Linda > > *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf Of > *Thomas Nadeau > *Sent:* Thursday, September 05, 2013 7:20 AM > *To:* Jiangyuanlong > *Cc:* nsc@ietf.org; Jim Guichard (jguichar); Zhuhengjun > *Subject:* Re: [nsc] NSC Working Group Charter Proposal > > On Sep 4, 2013:11:41 PM, at 11:41 PM, Jiangyuanlong > > wrote: > > > > Hi Jim, > > Thanks for the hard work on drafting the charter. > > In the proposed NSC charter, it says: > > “4) Manageability: this document will address service chaining > operation, monitoring and troubleshooting including relevant service > chaining models such as MIBs or YANG modules, along with relevant OAM > capabilities and how they are realized.” > > Firstly, the relation of “operation, monitoring and troubleshooting” and > “OAM” is not very clear to me. > > Secondly, though YANG module is a good piece of work, I don’t think it > should be put in the list of NSC deliverables, since YANG related > specification used to belong to OPS area. We can transfer it to OPS > (after information models are mature enough) and the expertise should be > readily found there. > > It is included because Yang modules, like MIB modules, are very > appropriate for any working group to deliver as part of their work items. > > > > I would like to propose the following texts: > > 4) Manageability: this document will address service chaining management > including relevant service chaining MIBs and information models, and > service chaining OAM. > > Splitting OAM into a separate item seems another option as it mainly > solves traceability of service chaining. > > Finally, the proposed timeline is not very practical IMHO (plus one > year for each item in the Milestone?). > > The timelines are not set in stone and are ultimately decided by the > ADs; they are just place holders now. > > --Tom > > > > Regards, > > Yuanlong > > *From:*nsc-bounces@ietf.org > [mailto:nsc-bounces@ietf.org > ]*On Behalf Of*Jim Guichard (jguichar) > *Sent:*Wednesday, September 04, 2013 12:01 AM > *To:*nsc@ietf.org > *Subject:*[nsc] NSC Working Group Charter Proposal > > Greetings, > > As we look forward to the formation of a working group that will focus > on network service chaining, I would like to propose a discussion on > this alias to try and reach consensus on an initial charter as requested > by the routing area AD's. The following is a first draft of the charter > and I invite you to actively participate and provide inputs into this > process. > > _Proposed NSC WG Charter_ > > Existing service insertion and deployment techniques have not evolved to > meet modern network architectures and do not reflect multi-tenancy, > virtualization, elasticity, rich classification, and other network > requirements. Networks, servers, storage, and applications, have all > undergone significant change in recent years: virtualization, network > overlays, and orchestration are increasingly the norm. All of these have > profound effects on network and services design. > > Today, deploying new services, or making changes to existing services, > often requires network topology changes. Adding and removing service > functionsis a complex, risky task, that is tied to operationalizing > topological changes leading to mostly-static service definitions. New > service insertion and deployment techniques must enable the concept of > service functions as shared resources, and enable the linkage of these > resources using service chains that represent the abstracted view of the > required service functions, and define the order in which they should be > applied. When a service chain is instantiated in a network, specific > instances of service functions are selected, and a service topology is > created and used for forwarding packets through the service chain. > > A basic service chain might simply utilize an existing overlay > technology to force traffic through the necessary service functions. > However, additional information enables a richer service chain for more > advanced composite services. For example, shared information (e.g., the > result of classification) can be used to offload service function > processing or inform other service functions about information that > would otherwise be hard to glean. > > The Network Service Chaining (NSC) working group focuses on new > approaches to service insertion and deployment, providing a framework > for the construction of services built using service chains. The WG > focuses on the necessary protocols for the creation of service chains, > and the passing of metadata from the network to service functions, and > between service functions. When possible, the WG will extend existing > protocols to provide service chaining functionality, and any protocol > extensions will be reviewed by both the Network Service Chaining WG and > by the WG responsible for the protocol being extended. > > Specifically, the Network Service Chaining WG is chartered to deliver > the following work items: > > 1) Problem Statement: this document will provide a summary of the > problem space to be addressed by the Network Service Chaining WG > including terminology and sample use cases. Additionally, the WG will > normalize on nomenclature and definitions for Network Service Chaining. > > 2) System Architecture: this set of documents will provide a description > of the architecture building blocks and their relationships including > interconnection, placement of capabilities, and security models, as well > as requirements on the control mechanisms and data plane encapsulation. > > 3) Service Chaining Data Plane: this document will describe on the wire > data plane encapsulation in support of (2). A single encapsulation will > be selected in order to enable interoperability of data plane components. > > 4) Manageability: this document will address service chaining operation, > monitoring and troubleshooting including relevant service chaining > models such as MIBs or YANG modules, along with relevant OAM > capabilities and how they are realized. > > Proposed Milestones: > > Dec 2013 Request publication of an Informational document defining the > Network Service Chaining problem statement to the IESG > > Mar 2014 Request publication of informational documents defining the > system architecture including protocol requirements and framework to the > IESG > > May 2014 Request publication of a Standards Track document specifying > the data-plane (including metadata) for Service Chaining to IESG > > May 2014 Request publication of an informational document specifying > Service Chaining Control Plane requirements to IESG > > Dec 2014 Request publication of informational documents defining Service > Chaining manageability requirements including MIBs, OAM, and > informationmodels to IESG > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From mohamed.boucadair@orange.com Thu Sep 5 08:05: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 E0BDA11E80EC for ; Thu, 5 Sep 2013 08:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ehISw+th+Qj for ; Thu, 5 Sep 2013 08:05:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id F366111E81B2 for ; Thu, 5 Sep 2013 08:05:05 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id C35F63B5934; Thu, 5 Sep 2013 17:05:03 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 999A2C812C; Thu, 5 Sep 2013 17:05:03 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 5 Sep 2013 17:05:03 +0200 From: To: Linda Dunbar , Ron Parker , "Jim Guichard (jguichar)" , "nsc@ietf.org" Date: Thu, 5 Sep 2013 17:05:02 +0200 Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtggAALk6CAAAI3kIAArVlg Message-ID: <94C682931C08B048B7A8645303FDC9F36EF06D03CA@PUEXCB1B.nanterre.francetelecom.fr> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9D4FB@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645B9D56D@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9D56D@dfweml509-mbx.china.huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF06D03CAPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.5.142415 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 15:05:13 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF06D03CAPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Linda, For the sake of interoperability, I vote for having one single encapsulatio= n scheme in the standard track. Opening the door for multiple alternatives = will induce an extra complexity. We should avoid that. Cheers, Med De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Linda= Dunbar Envoy=E9 : mercredi 4 septembre 2013 23:36 =C0 : Ron Parker; Jim Guichard (jguichar); nsc@ietf.org Objet : Re: [nsc] NSC Working Group Charter Proposal IMO, "single encapsulation" is too limiting. Many of today's service provi= der networks are MPLS based. In addition, there are even Ethernet based net= works (if you venture into IEEE802 or CEF). How about: "A single encapsulation per underlay network will be selected.."= ? Linda From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, September 04, 2013 4:27 PM To: Linda Dunbar; Jim Guichard (jguichar); nsc@ietf.org Subject: RE: NSC Working Group Charter Proposal Linda, I think that is a fundamental issue for the group to decide. If the goal = is a single encapsulation, then IMO it would have to be IP-based, since tha= t is the most common denominator. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, September 04, 2013 4:45 PM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal One clarification on Work Item #3: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be sel= ected in order to enable interoperability of data plane components. Is it really "A single encapsulation"? The encapsulation should depend on the underlay networks. Underlay network = could be IP based, MPLS based, or Ethernet based. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, September 03, 2013 11:01 AM To: nsc@ietf.org Subject: [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_94C682931C08B048B7A8645303FDC9F36EF06D03CAPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

For the sake of interoperability, I vote for having one single encapsul= ation scheme in the standard track. Opening the door for multiple alternati= ves will induce an extra complexity. We should avoid that.

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#993366'>Che= ers,

Med

 

 

De : nsc-bounce= s@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Linda Dunbar<= br>Envoy=E9 : mercredi 4 septembre 2013 23:36
=C0 :<= /b> Ron Parker; Jim Guichard (jguichar); nsc@ietf.org
Objet&= nbsp;: Re: [nsc] NSC Working Group Charter Proposal

 

IMO, “single encapsulation” is too  limiting. Man= y of today’s service provider networks are MPLS based. In addition, t= here are even Ethernet based networks (if you  venture into IEEE802 or= CEF).

 <= /span>

How about: “A single encapsulati= on per underlay network will be selected..”?=

 

Linda

=  

From: R= on Parker [mailto:Ron_Pa= rker@affirmednetworks.com]
Sent: Wednesday, September 04, 20= 13 4:27 PM
To: Linda Dunbar; Jim Guichard (jguichar); nsc@ietf.org
Subject: RE: NSC Working Gr= oup Charter Proposal

=  

Linda,

 

I think that is a fundamental issue for the group to decide.&nbs= p;  If the goal is a single encapsulation, then IMO it would have to b= e IP-based, since that is the most common denominator.   

 

   Ron

 

 

One clarification on Work Item= #3:

3) Ser= vice Chaining Data Plane: this document will describe on the wire data plan= e encapsulation in support of (2). A single encapsulation will be selected = in order to enable interoperability of data plane components.

 

Is it really “A single encapsulation”?

The encapsulation should depend = on the underlay networks. Underlay network could be IP based, MPLS based, o= r Ethernet based.  

<= o:p> 

Linda

 <= /span>

From: = nsc-bounces@ietf.org [mailto:ns= c-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
S= ent: Tuesday, September 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Grou= p Charter Proposal

 

Greetings,=

 

=

As we look forward to the formation of = a working group that will focus on network service chaining, I would like t= o propose a discussion on this alias to try and reach consensus on an initi= al charter as requested by the routing area AD's. The following is a first = draft of the charter and I invite you to actively participate and provide i= nputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion and deployment techniques ha= ve not evolved to meet modern network architectures and do not reflect mult= i-tenancy, virtualization, elasticity, rich classification, and other netwo= rk requirements. Networks, servers, storage, and applications, have all und= ergone significant change in recent years: virtualization, network overlays= , and orchestration are increasingly the norm. All of these have profound e= ffects on network and services design.

 

Today, deploying new services, or making changes to existing serv= ices, often requires network topology changes. Adding and removing service = functions is a complex, risky task, that is tied to operationalizing topolo= gical changes leading to mostly-static service definitions. New service ins= ertion and deployment techniques must enable the concept of service functio= ns as shared resources, and enable the linkage of these resources using ser= vice chains that represent the abstracted view of the required service func= tions, and define the order in which they should be applied. When a service= chain is instantiated in a network, specific instances of service function= s are selected, and a service topology is created and used for forwarding p= ackets through the service chain.

 

A basic service chain might simply utilize an existing overlay techno= logy to force traffic through the necessary service functions. However, add= itional information enables a richer service chain for more advanced compos= ite services. For example, shared information (e.g., the result of classifi= cation) can be used to offload service function processing or inform other = service functions about information that would otherwise be hard to glean.&= nbsp;

 <= /o:p>

The Network Service Cha= ining (NSC) working group focuses on new approaches to service insertion an= d deployment, providing a framework for the construction of services built = using service chains. The WG focuses on the necessary protocols for the cre= ation of service chains, and the passing of metadata from the network to se= rvice functions, and between service functions. When possible, the WG will = extend existing protocols to provide service chaining functionality, and an= y protocol extensions will be reviewed by both the Network Service Chaining= WG and by the WG responsible for the protocol being extended.  <= /o:p>

 

Specifically, the Network Service = Chaining WG is chartered to deliver the following work items: 

 <= /p>

1) Problem Statement: this document = will provide a summary of the problem space to be addressed by the Network = Service Chaining WG including terminology and sample use cases.  Addit= ionally, the WG will normalize on nomenclature and definitions for Network = Service Chaining.

=  

2) System A= rchitecture: this set of documents will provide a description of the archit= ecture building blocks and their relationships including interconnection, p= lacement of capabilities, and security models, as well as requirements on t= he control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Plane: this document will d= escribe on the wire data plane encapsulation in support of (2).  A sin= gle encapsulation will be selected in order to enable interoperability of d= ata plane components.

=  

4) Mana= geability: this document will address service chaining operation, monitorin= g and troubleshooting including relevant service chaining models such as MI= Bs or YANG modules, along with relevant OAM capabilities and how they are r= ealized.

&n= bsp;

Proposed Milestone= s:

 

Dec 2013 Request publicati= on of an Informational document defining the Network Service Chaining probl= em statement to the IESG

 

Mar = 2014 Request publication of informational documents defining the system arc= hitecture including protocol requirements and framework to the IESG

 <= /p>

May 2014 Request publication of a St= andards Track document specifying the data-plane (including metadata) for S= ervice Chaining to IESG

 

May 2= 014 Request publication of an informational document specifying Service Cha= ining Control Plane requirements to IESG

 

Dec 2014 Request publication of informational documents definin= g Service Chaining manageability requirements including MIBs, OAM, and info= rmation models to IESG 

 

=  

= --_000_94C682931C08B048B7A8645303FDC9F36EF06D03CAPUEXCB1Bnante_-- From jmh@joelhalpern.com Thu Sep 5 08:07: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 EFCEA11E81BE for ; Thu, 5 Sep 2013 08:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 gCSAqDOL-St6 for ; Thu, 5 Sep 2013 08:07:45 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id ECDCA11E80EC for ; Thu, 5 Sep 2013 08:07:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DF0FB1C02FE; Thu, 5 Sep 2013 08:07:44 -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 172F11C07D1; Thu, 5 Sep 2013 08:07:42 -0700 (PDT) Message-ID: <52289E40.3030802@joelhalpern.com> Date: Thu, 05 Sep 2013 11:07:44 -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: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> <52277CE1.60805@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36EF06D03C6@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF06D03C6@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 15:07:51 -0000 From this note, it sounds like you want to fold the actual architecture into the Framework. I suppose that we could call it "Framework and Architecture". My thought in calling it "Architecture was to focus on the part we really need to deliver, and not title the document about the supporting material. Yours, Joel On 9/5/13 11:03 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : mercredi 4 septembre 2013 20:33 >> À : BOUCADAIR Mohamed IMT/OLN >> Cc : Jim Guichard (jguichar); nsc@ietf.org >> Objet : Re: [nsc] NSC Working Group Charter Proposal >> >> Clipping for focus... >> >> On 9/4/13 10:05 AM, mohamed.boucadair@orange.com wrote: >>> Hi Jim, >>> >>> Thank you for preparing the text. >> ... >>> To sum up: my suggestion is to go for this set of deliverables: >>> >>> (a) Problem Statement document >>> >>> (b) Framework document (terminology, functional elements, architecture, >>> and overall procedure) >>> >>> (c) Requirements document >>> >>> (d) Design Analysis document >>> >>> (e) Specification document(s) >>> >>> I wouldn't object if the first charter of the future WG covers only >>> items (a) to (d). An updated charter can be envisaged once the future WG >>> has more visibility on the detailed set of specification documents. >>> >>> Cheers, >>> >>> Med >> >> I find this list difficult to understand. And the omissions of certain >> items from the previous proposal cause me personally some concern. >> >> Separating the problem statement, framework, requirements, and "design >> analysis" produces a multiplicity of documents which will divide the WGs >> efforts without, as far as I can tell, improving clarity. >> >> I also find the notion of a Design Analysis odd. > > [Med] The motivation for such analysis document are explained in the core of my message. But to have something concrete, what I have in mind is something close to the effort available at: http://tools.ietf.org/html/draft-boucadair-chaining-design-analysis-00. > > > What we need is an >> architecture or design to drive the protocol effort. > > [Med] We are in full agreement here. This is what I meant by the framework document. > > From where I sit, >> we need to pick an approach to the problem, and document that pick. In >> many ways, it is quite likely that we will have to pick simply because a >> choice is needed, not because one is universally better than another. I >> would strongly prefer that the focus of the document be on the actual >> answer. >> >> Similarly, while I find use case drafts useful information for the WG to >> consider, I think that arguing about which use cases we should put in an >> RFC, would not be a good use of the WGs time and energy. > > [Med] My suggestion is not charter any item for the use cases.. but provide a high level description in the problem statement. > > > Some >> discussion of importance is inevitable as we decide which pieces of the >> problem to solve well, which pieces to solve awkwardly, and which pieces >> not to solve. > > [Med] That's part of the design considerations & analysis effort imho. > > From andre.beliveau@ericsson.com Thu Sep 5 08: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 EE7FB21E80C3 for ; Thu, 5 Sep 2013 08:08:48 -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 9ePBv3Y8Zuxz for ; Thu, 5 Sep 2013 08:08:42 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3B16321E80BD for ; Thu, 5 Sep 2013 08:08:41 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-a9-52289e77bd7a Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7C.FA.09414.77E98225; Thu, 5 Sep 2013 17:08:39 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Thu, 5 Sep 2013 11:08:29 -0400 From: Andre Beliveau To: "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: Ac6qR+sHgzL0ctdRQuK48hgJf0btpA== Date: Thu, 5 Sep 2013 15:08:28 +0000 Message-ID: <3049626EAC5C3E43866CD2692A7E19AC1C21EDA6@eusaamb103.ericsson.se> 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: multipart/alternative; boundary="_000_3049626EAC5C3E43866CD2692A7E19AC1C21EDA6eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyuXSPt275PI0gg/bPChbH9+1nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtTHqxkL9jhX9O+8yNbAeM66i5GDQ0LARGLLxbIuRk4gU0zi wr31bF2MXBxCAkcZJeY9Wc0C4SxjlHh5sY8VpIpNwEji/ZVJjCDNIgKKEjvfpICEhQW0Jd7e OswEYosIGEjc+fSZBcLWk1j99SAbiM0ioCJxuHsuO4jNK+ArsWfCL2YQm1FAVmLDxG9g9cwC 4hK3nsxngjhIQGLJnvPMELaoxMvH/1ghbGWJJU/2Q9XnS8z/9Y8NYqagxMmZT1gmMArNQjJq FpKyWUjKIOJ6EjemTmGDsLUlli18zQxh60rM+HeIBVl8ASP7KkaO0uLUstx0I4NNjMCwPybB pruDcc9Ly0OM0hwsSuK8q/TOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpg3LnZJ+h5kJlq /+f3qlOnTlWQ//NY5Hpc+HUHvd9p72o/qwVqBFxbd/MkG6/RdAWG5NagyXIaP6/OKHwVHPBj dviJZ/bxSbo8e+csrN0iW+aj+zCm+cft37Myk7vuP5v29Nlvy60bPs28OWmBxKML7Y2sZaVf f+79nL7+4xsv33IpTqbaL3obgpRYijMSDbWYi4oTAXBfEeJJAgAA Subject: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 15:08:49 -0000 --_000_3049626EAC5C3E43866CD2692A7E19AC1C21EDA6eusaamb103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jim, Some comments on Take Two of the charter: In the paragraph: The Network Service Chaining (NSC) working group focuses on new approaches = to network service structuring, insertion, and deployment, providing a fram= ework for the construction of services built using service function chains.= The WG focuses on the necessary protocols for the creation of service chai= ns, and the transmission of network and service-specific information from t= he network to service functions, and between service functions. Could we be more generic and not limit to "creation" of service chains. We= could write the last sentence as "The WG focuses on the necessary protocol= s for management (e.g. create, delete, monitor) of service chains, and the = transmission of network and service-specific information from the network t= o service functions, and between service functions." I would also propose to be more specific when we write "focuses on new appr= oaches", so it gives guidance for the solution. Following the key points h= ighlighted by operators in their presentations at IETF 87, I would be more = specific and write "working group focuses on new and simpler approaches to.= ..". It's important that the outcome of the WG will result in implementati= ons which will reduce the complexity to manage Service Chains. Regarding the manageability, I'm quite happy to see specific deliverables a= s item 4). I'd like it to be more specific, but we have not seen any solut= ion proposals for managing Service Chains which would guide us in a more sp= ecific deliverable. Regards, Andr=E9 B=E9liveau, Ing. Expert, Software and System Architecture Ericsson Research, Packet Technologies Tel.: +1 (514) 345 2708 Mobile: +1 (514) 502 9592 mailto:andre.beliveau@ericsson.com --_000_3049626EAC5C3E43866CD2692A7E19AC1C21EDA6eusaamb103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 

Some comments on Take Two of the charter:

 

In the paragraph:

The Network Service Chaining (NSC) working group focuses on new app= roaches to network service structuring, insertion, and deployment, providin= g a framework for the construction of services built using service function chains. The WG focuses on the necess= ary protocols for the creation of service chains, and the transmission of n= etwork and service-specific information from the network to service functio= ns, and between service functions.

 

Could we be more generic and not limit to “creation” of= service chains.  We could write the last sentence as “The WG fo= cuses on the necessary protocols for management (e.g. create, delete, monitor) of service chains, and the transmission of network and se= rvice-specific information from the network to service functions, and betwe= en service functions.”

 

I would also propose to be more specific when we write “focus= es on new approaches”, so it gives guidance for the solution.  F= ollowing the key points highlighted by operators in their presentations at IETF 87, I would be more specific and write “workin= g group focuses on new and simpler approaches to…”.  It= 217;s important that the outcome of the WG will result in implementations w= hich will reduce the complexity to manage Service Chains.=

 

Regarding the manageability, I&= #8217;m quite happy to see specific deliverables as item 4).  I’= d like it to be more specific, but we have not seen any solution proposals = for managing Service Chains which would guide us in a more specific deliverable.

 

Regards,

 

Andr=E9 B=E9liveau, Ing.

Expert, Software and System Architecture<= /span>=

Ericsson Research, Packet Technologies

Tel.: +1 (514) 345 2708

Mobile: +1 (514) 502 9= 592  mailto:andre.beliveau@ericsson.com

 

--_000_3049626EAC5C3E43866CD2692A7E19AC1C21EDA6eusaamb103erics_-- From mohamed.boucadair@orange.com Thu Sep 5 08:13: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 17BC421F9C66 for ; Thu, 5 Sep 2013 08:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.038, 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 whJz1W6sdpfn for ; Thu, 5 Sep 2013 08:13:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id AFC1C21F9BF0 for ; Thu, 5 Sep 2013 08:13:09 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id EFE64C1676; Thu, 5 Sep 2013 17:13:08 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id C57E9158132; Thu, 5 Sep 2013 17:13:08 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 5 Sep 2013 17:13:08 +0200 From: To: "Joel M. Halpern" Date: Thu, 5 Sep 2013 17:13:06 +0200 Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: Ac6qSa9KDGMQpgFHQPaaTXBRoxV2EAAAI4nQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EF06D03DA@PUEXCB1B.nanterre.francetelecom.fr> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> <52277CE1.60805@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36EF06D03C6@PUEXCB1B.nanterre.francetelecom.fr> <52289E40.3030802@joelhalpern.com> In-Reply-To: <52289E40.3030802@joelhalpern.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.5.142415 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 15:13:14 -0000 Re-, Yes, "Framework and Architecture" is better.=20 Thanks Joel. Cheers, Med >-----Message d'origine----- >De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] >Envoy=E9=A0: jeudi 5 septembre 2013 17:08 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: Jim Guichard (jguichar); nsc@ietf.org >Objet=A0: Re: [nsc] NSC Working Group Charter Proposal > > From this note, it sounds like you want to fold the actual architecture >into the Framework. I suppose that we could call it "Framework and >Architecture". My thought in calling it "Architecture was to focus on >the part we really need to deliver, and not title the document about the >supporting material. > >Yours, >Joel > >On 9/5/13 11:03 AM, mohamed.boucadair@orange.com wrote: >> Hi Joel, >> >> Please see inline. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Envoy=E9 : mercredi 4 septembre 2013 20:33 >>> =C0 : BOUCADAIR Mohamed IMT/OLN >>> Cc : Jim Guichard (jguichar); nsc@ietf.org >>> Objet : Re: [nsc] NSC Working Group Charter Proposal >>> >>> Clipping for focus... >>> >>> On 9/4/13 10:05 AM, mohamed.boucadair@orange.com wrote: >>>> Hi Jim, >>>> >>>> Thank you for preparing the text. >>> ... >>>> To sum up: my suggestion is to go for this set of deliverables: >>>> >>>> (a) Problem Statement document >>>> >>>> (b) Framework document (terminology, functional elements, architecture= , >>>> and overall procedure) >>>> >>>> (c) Requirements document >>>> >>>> (d) Design Analysis document >>>> >>>> (e) Specification document(s) >>>> >>>> I wouldn't object if the first charter of the future WG covers only >>>> items (a) to (d). An updated charter can be envisaged once the future >WG >>>> has more visibility on the detailed set of specification documents. >>>> >>>> Cheers, >>>> >>>> Med >>> >>> I find this list difficult to understand. And the omissions of certain >>> items from the previous proposal cause me personally some concern. >>> >>> Separating the problem statement, framework, requirements, and "design >>> analysis" produces a multiplicity of documents which will divide the WG= s >>> efforts without, as far as I can tell, improving clarity. >>> >>> I also find the notion of a Design Analysis odd. >> >> [Med] The motivation for such analysis document are explained in the cor= e >of my message. But to have something concrete, what I have in mind is >something close to the effort available at: >http://tools.ietf.org/html/draft-boucadair-chaining-design-analysis-00. >> >> >> What we need is an >>> architecture or design to drive the protocol effort. >> >> [Med] We are in full agreement here. This is what I meant by the >framework document. >> >> From where I sit, >>> we need to pick an approach to the problem, and document that pick. In >>> many ways, it is quite likely that we will have to pick simply because = a >>> choice is needed, not because one is universally better than another. = I >>> would strongly prefer that the focus of the document be on the actual >>> answer. >>> >>> Similarly, while I find use case drafts useful information for the WG t= o >>> consider, I think that arguing about which use cases we should put in a= n >>> RFC, would not be a good use of the WGs time and energy. >> >> [Med] My suggestion is not charter any item for the use cases.. but >provide a high level description in the problem statement. >> >> >> Some >>> discussion of importance is inevitable as we decide which pieces of the >>> problem to solve well, which pieces to solve awkwardly, and which piece= s >>> not to solve. >> >> [Med] That's part of the design considerations & analysis effort imho. >> >> From mohamed.boucadair@orange.com Thu Sep 5 08:19: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 C381221E80C3 for ; Thu, 5 Sep 2013 08:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.009, 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 74vW0ujnvB37 for ; Thu, 5 Sep 2013 08:19:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 77A4D21E80BE for ; Thu, 5 Sep 2013 08:19:17 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id C758918C418 for ; Thu, 5 Sep 2013 17:19:16 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id AE4FE4C150 for ; Thu, 5 Sep 2013 17:19:16 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 5 Sep 2013 17:19:16 +0200 From: To: "nsc@ietf.org" Date: Thu, 5 Sep 2013 17:19:14 +0200 Thread-Topic: I-D Action: draft-boucadair-chaining-requirements-02.txt Thread-Index: Ac6qDHsm3G6gZnoCRkaov3sSMkajFQAPqfdA Message-ID: <94C682931C08B048B7A8645303FDC9F36EF06D03E8@PUEXCB1B.nanterre.francetelecom.fr> References: <20130905074917.8889.34958.idtracker@ietfa.amsl.com> In-Reply-To: <20130905074917.8889.34958.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.5.142415 Subject: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-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: Thu, 05 Sep 2013 15:19:21 -0000 Dear all, This new version integrates the comments received so far.=20 A detailed diff is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-b= oucadair-chaining-requirements-02=20 Feel free to review and contribute. Cheers, Med -----Message d'origine----- De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= De la part de internet-drafts@ietf.org Envoy=E9=A0: jeudi 5 septembre 2013 09:49 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-chaining-requirements-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Requirements for Service Function Chaining Author(s) : Mohamed Boucadair Christian Jacquenet Yuanlong Jiang Ron Parker Carlos Pignataro Filename : draft-boucadair-chaining-requirements-02.txt Pages : 10 Date : 2013-09-05 Abstract: This document identifies the requirements for the Service Function Chaining. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-chaining-requirements-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-chaining-requirements-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From jguichar@cisco.com Thu Sep 5 08:51: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 85C5021E80DC for ; Thu, 5 Sep 2013 08:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.054, 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 tNmY4EnYHf9n for ; Thu, 5 Sep 2013 08:51:38 -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 2D09821E813A for ; Thu, 5 Sep 2013 08:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10176; q=dns/txt; s=iport; t=1378396279; x=1379605879; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=S8c/u/8bvKP8PtpbSQ42wCIT5kdIcINlA9Qx2stYz6A=; b=QxzwGNqWY6rbT1ggcXUEZTqaTdisMzghRD/wKRcOM/NgA2mT73WnKEtr 3Mw/+NaNrWdAX5wt0y2e51kL6xKgnv/Tb02urW1EOWg0Jn9bqZqIsEtkq vr4xplEGBtQzb1K6tKl5a0Xck7bsNNcKPLHrkdMjjORd4CoGOqTmis6Bg c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAPSnKFKtJXHB/2dsb2JhbABYA4JDRDVRwUqBKRZ0giQBAQEELT4gAQgRAQIBAgsdORQDBggBAQQBEggTh2e6RY4igQ0gARYBEYMMgQADk1qWAYMggWlB X-IronPort-AV: E=Sophos;i="4.90,847,1371081600"; d="scan'208,217";a="256023853" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 05 Sep 2013 15:51:17 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r85FpHvU000767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 15:51:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 10:51:16 -0500 From: "Jim Guichard (jguichar)" To: Andre Beliveau , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: Ac6qR+sHrXOZ2m/vBEG19boxgCQmQwAEDYaA Date: Thu, 5 Sep 2013 15:51:16 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6771F2@xmb-rcd-x01.cisco.com> In-Reply-To: <3049626EAC5C3E43866CD2692A7E19AC1C21EDA6@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.246.115] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F6771F2xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 15:51:44 -0000 --_000_68B171751455884590F8E38E96416F363F6771F2xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Andre for this input. I agree that the second sentence and the si= mplicity angle are appropriate changes and I have updated the charter accor= dingly. From: Andre Beliveau > Date: Thursday, September 5, 2013 11:08 AM To: "nsc@ietf.org" > Subject: [nsc] NSC Working Group Charter Proposal Hi Jim, Some comments on Take Two of the charter: In the paragraph: The Network Service Chaining (NSC) working group focuses on new approaches = to network service structuring, insertion, and deployment, providing a fram= ework for the construction of services built using service function chains.= The WG focuses on the necessary protocols for the creation of service chai= ns, and the transmission of network and service-specific information from t= he network to service functions, and between service functions. Could we be more generic and not limit to =93creation=94 of service chains.= We could write the last sentence as =93The WG focuses on the necessary pr= otocols for management (e.g. create, delete, monitor) of service chains, an= d the transmission of network and service-specific information from the net= work to service functions, and between service functions.=94 I would also propose to be more specific when we write =93focuses on new ap= proaches=94, so it gives guidance for the solution. Following the key poin= ts highlighted by operators in their presentations at IETF 87, I would be m= ore specific and write =93working group focuses on new and simpler approach= es to=85=94. It=92s important that the outcome of the WG will result in im= plementations which will reduce the complexity to manage Service Chains. Regarding the manageability, I=92m quite happy to see specific deliverables= as item 4). I=92d like it to be more specific, but we have not seen any s= olution proposals for managing Service Chains which would guide us in a mor= e specific deliverable. Regards, Andr=E9 B=E9liveau, Ing. Expert, Software and System Architecture Ericsson Research, Packet Technologies Tel.: +1 (514) 345 2708 Mobile: +1 (514) 502 9592 mailto:andre.beliveau@ericsson.com --_000_68B171751455884590F8E38E96416F363F6771F2xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thank you Andre for this input. I agree that the second sentence and t= he simplicity angle are appropriate changes and I have updated the charter = accordingly. 

From: Andre Beliveau <andre.beliveau@ericsson.com> Date: Thursday, September 5, 2013 1= 1:08 AM
To: "nsc@ietf.org" <nsc@ietf.= org>
Subject: [nsc] NSC Working Group Ch= arter Proposal

Hi Jim,

 

Some comments on Take Two of the charter:

 

In the paragraph:

The Network Service Chaining (NSC) working group focuses on new app= roaches to network service structuring, insertion, and deployment, providin= g a framework for the construction of services built using service function chains. The WG focuses on the necess= ary protocols for the creation of service chains, and the transmission of n= etwork and service-specific information from the network to service functio= ns, and between service functions.

 

Could we be more generic and not limit to =93creation=94 of service= chains.  We could write the last sentence as =93The WG focuses on the= necessary protocols for management (e.g. create, delete, monitor) of service chains, and the transmission of network and se= rvice-specific information from the network to service functions, and betwe= en service functions.=94

 

I would also propose to be more specific when we write =93focuses o= n new approaches=94, so it gives guidance for the solution.  Following= the key points highlighted by operators in their presentations at IETF 87, I would be more specific and write =93working gr= oup focuses on new and simpler approaches to=85=94.  It=92s important = that the outcome of the WG will result in implementations which will reduce= the complexity to manage Service Chains.

 

Regarding the manageability, I= =92m quite happy to see specific deliverables as item 4).  I=92d like = it to be more specific, but we have not seen any solution proposals for man= aging Service Chains which would guide us in a more specific deliverable.

 

Regards,

 

Andr=E9 B=E9liveau, Ing.

Expert, Software and System Architecture

Ericsson Research, Packet Technologies

Tel.: +1 (514) 345 2708

Mobile: +1 (514) 502 9592  mailto:andre.beliveau@ericsson.com

 

--_000_68B171751455884590F8E38E96416F363F6771F2xmbrcdx01ciscoc_-- From jguichar@cisco.com Thu Sep 5 09:00: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 DA29F11E81AB for ; Thu, 5 Sep 2013 09:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 l6qGT-8+Ig-T for ; Thu, 5 Sep 2013 09:00:37 -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 CFA1011E8169 for ; Thu, 5 Sep 2013 09:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26551; q=dns/txt; s=iport; t=1378396837; x=1379606437; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=rPYWEBjMcZSnZ02h/k3mV7WmVgGkvpocjLPlYiyWx+E=; b=jg6Nzq3TWDvUkr2a1jKiSEtInzQYc2LzJCOJOl8FuMR3uhJf88mjxRCh cU7leWll1UoIz1TflBtsjpywtrt2DoEdWxBlWAGBCsKE7JKGZY9oM/7eB P9GeA/Bi83pA5dC2ySX3G/Uur4RB0HAfQSAxOcxWJp7abX2wWZVF/Kes7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAE2qKFKtJV2Y/2dsb2JhbABbgkNENVHBSoEpFnSCJAEBAQQtRRkBCBEBAgEBAQsWBzkUAwYIAgQBEgiHerpDjhcWgQIgFwGDHYEAA5QblUCDIIFpCBci X-IronPort-AV: E=Sophos;i="4.90,847,1371081600"; d="scan'208,217";a="256060644" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 05 Sep 2013 16:00:36 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r85G0ZpJ017013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 16:00:35 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 11:00:35 -0500 From: "Jim Guichard (jguichar)" To: Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAACnbAA== Date: Thu, 5 Sep 2013 16:00:35 +0000 Message-ID: <68B171751455884590F8E38E96416F363F677263@xmb-rcd-x01.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9DBA7@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.246.115] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F677263xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 16:00:46 -0000 --_000_68B171751455884590F8E38E96416F363F677263xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Linda, The service chaining effort has nothing to do with traffic engineering and = I am puzzled as to why you would think so. We have been back and forth on t= he discussion of layering and from what I can see there is consensus on the= list that we need not stall this effort through pontification of terminolo= gy or causing confusion where there is none to the majority of participants= on the alias. From: Linda Dunbar = > Date: Thursday, September 5, 2013 10:45 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: [nsc] NSC Working Group Charter Proposal Jim, This version hasn=92t addressed the comments on Bullet 3 of requiring a sin= gle encapsulation being too limiting or may not even be realistic. Several people on other email thread (i.e. =93outcome of NSC BoF=94) stated= that the =93services=94 in the NSC context can be Layer 2-3 services or La= yer 4-7 services. For Layer 2-3 services, IETF has standardized Explicit Routing Object (ERO)= to dictate data flows traversing a pre-determined sequence of Layer 3 node= s, or using BGP control plane to dictate next hop. I am not advocating that policy based routing (e.g. ERO) should be in the = scope of NSC. But I can=92t see how the current proposed scope excludes t= hose policy based routing schemes that have been deployed in the industry. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Thursday, September 05, 2013 6:57 AM To: nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Greetings, I have updated the charter as follows based on all comments received thus f= ar. There have been lots of inputs and this charter may not reflect all of = them (hopefully it is pretty close). Please take time to review and continu= e the discussion. Proposed NSC WG Charter =96 Take two Existing service insertion and deployment techniques fail to address new ch= allenging requirements raised by the introduction of emerging technologies = such as multi-tenancy, virtualization, elasticity, and rich classification.= Networks, servers, and other storage technologies, let alone applications,= have all undergone significant change in recent years: virtualization, net= work overlays, and orchestration have increasingly become techniques that c= ount and sometimes prevail. All of these have profound effects on network a= nd services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to massively static configuration procedures for network servic= e delivery or update purposes. The structuring and the delivery of new netw= ork services assume the (smart) combination of various service functions as= shared resources, and enable the linkage of these resources using service = chains that represent the abstracted view of the required service functions= , and define the order in which they should be invoked. Such (smart) combin= ations could be made of heterogeneous service functions which may act at va= rious layers of a protocol stack (network layer, application layer, etc). W= hen a service chain is instantiated in a network, specific instances of ser= vice functions are selected, and a service topology is created and used for= forwarding packets according to the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information that is shared across a subset of service functions may enabl= e a richer service chain for more advanced composite services. For example,= shared information, such as the results of a classification function, may = be passed to downstream service functions to enable the offloading of servi= ce function processing or to share information that would otherwise be hard= to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to network service structuring, insertion, and deployment, providing a fram= ework for the construction of services built using service function chains.= The WG focuses on the necessary protocols for the creation of service chai= ns, and the transmission of network and service-specific information from t= he network to service functions, and between service functions. When possib= le, the WG will extend existing protocols to provide service chaining funct= ionality, and any protocol extensions will be reviewed by both the Network = Service Chaining WG and by the WG responsible for the protocol being extend= ed. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including example h= igh-level use cases. Additionally, the WG will normalize on nomenclature a= nd definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining management in= support of (2) including relevant service chaining MIBs and information mo= dels, and service chaining OAM. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including context data) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of Informational document(s) defining Network = Service Chaining use cases to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability including MIBs, OAM, and information models to IESG --_000_68B171751455884590F8E38E96416F363F677263xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <58CB2D5E073E8B44A48BC4B88FF6F5BF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Linda,

The service chaining effort has nothing to do with traffic engineering= and I am puzzled as to why you would think so. We have been back and forth= on the discussion of layering and from what I can see there is consensus o= n the list that we need not stall this effort through pontification of terminology or causing confusion wher= e there is none to the majority of participants on the alias. 

From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Thursday, September 5, 2013 1= 0:45 AM
To: Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: [nsc] NSC Working Grou= p Charter Proposal

Jim,

 

This version hasn=92t addressed th= e comments on Bullet 3 of requiring a single encapsulation being too limiti= ng or may not even be realistic.

 

Several people on other email thre= ad (i.e. =93outcome of NSC BoF=94) stated that the =93services=94 in the NS= C context can be Layer 2-3 services or Layer 4-7 services.

 

For Layer 2-3 services, IETF has s= tandardized Explicit Routing Object (ERO) to dictate data flows traversing = a pre-determined sequence of Layer 3 nodes, or using BGP control plane to dictate next hop.  

 

I am not advocating that policy ba= sed routing (e.g. ERO)  should be in the scope of NSC.  But I can= =92t see how the current proposed scope excludes  those policy based routing schemes that have been deployed in the in= dustry.

 

Linda

 

 

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, September 05, 2013 6:57 AM
To: nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

Greetings,

 

I have updated the charter as follows based = on all comments received thus far. There have been lots of inputs and this = charter may not reflect all of them (hopefully it is pretty close). Please take time to review and continue th= e discussion.

 

Proposed NSC WG Charter =96 Take two

 

Existing service insertion and deployment te= chniques fail to address new challenging requirements raised by the introdu= ction of emerging technologies such as multi-tenancy, virtualization, elasticity, and rich classification. Net= works, servers, and other storage technologies, let alone applications, hav= e all undergone significant change in recent years: virtualization, network= overlays, and orchestration have increasingly become techniques that count and sometimes prevail. All of th= ese have profound effects on network and services design.=

 

Today, deploying new services, or making cha= nges to existing services, often requires network topology changes. Adding = and removing service functions is a complex, risky task, that is tied to operationalizing topological changes = leading to massively static configuration procedures for network service de= livery or update purposes. The structuring and the delivery of new network = services assume the (smart) combination of various service functions as shared resources, and enable the linkage o= f these resources using service chains that represent the abstracted view o= f the required service functions, and define the order in which they should= be invoked. Such (smart) combinations could be made of heterogeneous service functions which may act at various = layers of a protocol stack (network layer, application layer, etc). When a = service chain is instantiated in a network, specific instances of service f= unctions are selected, and a service topology is created and used for forwarding packets according to the servi= ce chain.

 

A basic service chain might simply utilize a= n existing overlay technology to force traffic through the necessary servic= e functions. However, additional information that is shared across a subset of service functions may enable a richer se= rvice chain for more advanced composite services. For example, shared infor= mation, such as the results of a classification function, may be passed to = downstream service functions to enable the offloading of service function processing or to share informati= on that would otherwise be hard to glean. 

 

The Network Service Chaining (NSC) working g= roup focuses on new approaches to network service structuring, insertion, a= nd deployment, providing a framework for the construction of services built using service function chains. The = WG focuses on the necessary protocols for the creation of service chains, a= nd the transmission of network and service-specific information from the ne= twork to service functions, and between service functions. When possible, the WG will extend existing prot= ocols to provide service chaining functionality, and any protocol extension= s will be reviewed by both the Network Service Chaining WG and by the WG re= sponsible for the protocol being extended.  

 

Specifically, the Network Service Chaining W= G is chartered to deliver the following work items: =

 

1) Problem Statement: this document will pro= vide a summary of the problem space to be addressed by the Network Service = Chaining WG including example high-level use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.

 

2) System Architecture: this set of document= s will provide a description of the architecture building blocks and their = relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Plane: this documen= t will describe on the wire data plane encapsulation in support of (2). &nb= sp;A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this document will address= service chaining management in support of (2) including relevant service c= haining MIBs and information models, and service chaining OAM.

 

Proposed Milestones:

 

Dec 2013 Request publication of an Informati= onal document defining the Network Service Chaining problem statement to th= e IESG

 

Mar 2014 Request publication of informationa= l documents defining the system architecture including protocol requirement= s and framework to the IESG

 

May 2014 Request publication of a Standards = Track document specifying the data-plane (including context data) for Servi= ce Chaining to IESG

 

May 2014 Request publication of an informati= onal document specifying Service Chaining Control Plane requirements to IES= G

 

Dec 2014 Request publication of Informationa= l document(s) defining Network Service Chaining use cases to IESG

 

Dec 2014 Request publication of informationa= l documents defining Service Chaining manageability including MIBs, OAM, an= d information models to IESG 

 

 

 

 =

--_000_68B171751455884590F8E38E96416F363F677263xmbrcdx01ciscoc_-- From linda.dunbar@huawei.com Thu Sep 5 09:22:36 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8A221E814B for ; Thu, 5 Sep 2013 09:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.368, 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 rpRpmTsLhKU3 for ; Thu, 5 Sep 2013 09:22:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 61F9221E8130 for ; Thu, 5 Sep 2013 09:22:26 -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.5-GA FastPath queued) with ESMTP id AWY11905; Thu, 05 Sep 2013 16:22:25 +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; Thu, 5 Sep 2013 17:21:43 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 17:22:00 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Thu, 5 Sep 2013 09:21:55 -0700 From: Linda Dunbar To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAACnbAP//8WaQ Date: Thu, 5 Sep 2013 16:21:55 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9DD7F@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645B9DBA7@dfweml509-mbx.china.huawei.com> <68B171751455884590F8E38E96416F363F677263@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F677263@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.192.11.59] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B9DD7Fdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 16:22:36 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645B9DD7Fdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, The service chaining effort has nothing to do with traffic engineering and = I am puzzled as to why you would think so. [Linda]No, I don't believe that service chaining effort is about chaining L= ayer2/3 links & nodes across network. That is why I sent several emails on= the other email threads to advocate the necessity of differentiating the "= Services" in the context of NSC from typical Layer2/3 services. However, some people on the other thread stated that Layer 2/3 nodes chaini= ng shouldn't be excluded. I simply want to point out that the current scope doesn't have clear defini= tion about "services". Therefore, the current scope doesn't preclude chain= ing Layer 2/3 nodes based on control plane policy. (I am not saying that I = want to do so). Linda From: Linda Dunbar = > Date: Thursday, September 5, 2013 10:45 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: [nsc] NSC Working Group Charter Proposal Jim, This version hasn't addressed the comments on Bullet 3 of requiring a singl= e encapsulation being too limiting or may not even be realistic. Several people on other email thread (i.e. "outcome of NSC BoF") stated tha= t the "services" in the NSC context can be Layer 2-3 services or Layer 4-7 = services. For Layer 2-3 services, IETF has standardized Explicit Routing Object (ERO)= to dictate data flows traversing a pre-determined sequence of Layer 3 node= s, or using BGP control plane to dictate next hop. I am not advocating that policy based routing (e.g. ERO) should be in the = scope of NSC. But I can't see how the current proposed scope excludes tho= se policy based routing schemes that have been deployed in the industry. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Thursday, September 05, 2013 6:57 AM To: nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Greetings, I have updated the charter as follows based on all comments received thus f= ar. There have been lots of inputs and this charter may not reflect all of = them (hopefully it is pretty close). Please take time to review and continu= e the discussion. Proposed NSC WG Charter - Take two Existing service insertion and deployment techniques fail to address new ch= allenging requirements raised by the introduction of emerging technologies = such as multi-tenancy, virtualization, elasticity, and rich classification.= Networks, servers, and other storage technologies, let alone applications,= have all undergone significant change in recent years: virtualization, net= work overlays, and orchestration have increasingly become techniques that c= ount and sometimes prevail. All of these have profound effects on network a= nd services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to massively static configuration procedures for network servic= e delivery or update purposes. The structuring and the delivery of new netw= ork services assume the (smart) combination of various service functions as= shared resources, and enable the linkage of these resources using service = chains that represent the abstracted view of the required service functions= , and define the order in which they should be invoked. Such (smart) combin= ations could be made of heterogeneous service functions which may act at va= rious layers of a protocol stack (network layer, application layer, etc). W= hen a service chain is instantiated in a network, specific instances of ser= vice functions are selected, and a service topology is created and used for= forwarding packets according to the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information that is shared across a subset of service functions may enabl= e a richer service chain for more advanced composite services. For example,= shared information, such as the results of a classification function, may = be passed to downstream service functions to enable the offloading of servi= ce function processing or to share information that would otherwise be hard= to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to network service structuring, insertion, and deployment, providing a fram= ework for the construction of services built using service function chains.= The WG focuses on the necessary protocols for the creation of service chai= ns, and the transmission of network and service-specific information from t= he network to service functions, and between service functions. When possib= le, the WG will extend existing protocols to provide service chaining funct= ionality, and any protocol extensions will be reviewed by both the Network = Service Chaining WG and by the WG responsible for the protocol being extend= ed. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including example h= igh-level use cases. Additionally, the WG will normalize on nomenclature a= nd definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining management in= support of (2) including relevant service chaining MIBs and information mo= dels, and service chaining OAM. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including context data) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of Informational document(s) defining Network = Service Chaining use cases to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability including MIBs, OAM, and information models to IESG --_000_4A95BA014132FF49AE685FAB4B9F17F645B9DD7Fdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim,

 <= /p>

 <= /p>

 <= /p>

 

The service chaining effort = has nothing to do with traffic engineering and I am puzzled as to why you w= ould think so.

 <= /p>

[Linda]No, I don’t = believe that service chaining effort is about chaining Layer2/3 links &= nodes across network.  That is why I sent several emails on the other email threads to advocate the necessity of differentiating the “Serv= ices” in the context of NSC from typical Layer2/3 services.

However, some people on t= he other thread stated that Layer 2/3 nodes chaining shouldn’t be exc= luded.

 <= /p>

I simply want to point ou= t that the current scope doesn’t have clear definition about “s= ervices”.  Therefore, the current scope doesn’t preclude c= haining Layer 2/3 nodes based on control plane policy. (I am not saying that I want to d= o so).

 <= /p>

 <= /p>

Linda

 <= /p>

 

From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Thursday, September 5, 2013 10:45 AM
To: Microsoft Office User <= jguichar@cisco.com>, "nsc@ietf.= org" <nsc@ietf.org>
Subject: RE: [nsc] NSC Working Group Charter Proposal

 

Jim,

 

This version hasn’t= addressed the comments on Bullet 3 of requiring a single encapsulation bei= ng too limiting or may not even be realistic.

 

Several people on other e= mail thread (i.e. “outcome of NSC BoF”) stated that the “= services” in the NSC context can be Layer 2-3 services or Layer 4-7 s= ervices.

 

For Layer 2-3 services, I= ETF has standardized Explicit Routing Object (ERO) to dictate data flows tr= aversing a pre-determined sequence of Layer 3 nodes, or using BGP control plane to dictate next hop.  

 

I am not advocating that = policy based routing (e.g. ERO)  should be in the scope of NSC.  = But I can’t see how the current proposed scope excludes  those p= olicy based routing schemes that have been deployed in the industry.

 

Linda

 

 

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, September 05, 2013 6:57 AM
To: nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 =

Greetings,

 

I have updated the charter a= s follows based on all comments received thus far. There have been lots of = inputs and this charter may not reflect all of them (hopefully it is pretty close). Please take time to review and continue the discussio= n.

 

Proposed NSC WG Charter &= #8211; Take two

 

Existing service insertion a= nd deployment techniques fail to address new challenging requirements raise= d by the introduction of emerging technologies such as multi-tenancy, virtualization, elasticity, and rich classification. Networks, servers, an= d other storage technologies, let alone applications, have all undergone si= gnificant change in recent years: virtualization, network overlays, and orc= hestration have increasingly become techniques that count and sometimes prevail. All of these have profound ef= fects on network and services design.

 

Today, deploying new service= s, or making changes to existing services, often requires network topology = changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o massively static configuration procedures for network service delivery or= update purposes. The structuring and the delivery of new network services = assume the (smart) combination of various service functions as shared resources, and enable the linkage of t= hese resources using service chains that represent the abstracted view of t= he required service functions, and define the order in which they should be= invoked. Such (smart) combinations could be made of heterogeneous service functions which may act at various = layers of a protocol stack (network layer, application layer, etc). When a = service chain is instantiated in a network, specific instances of service f= unctions are selected, and a service topology is created and used for forwarding packets according to the servi= ce chain.

 

A basic service chain might = simply utilize an existing overlay technology to force traffic through the = necessary service functions. However, additional information that is shared across a subset of service functions may enable a richer se= rvice chain for more advanced composite services. For example, shared infor= mation, such as the results of a classification function, may be passed to = downstream service functions to enable the offloading of service function processing or to share informati= on that would otherwise be hard to glean. 

 

The Network Service Chaining= (NSC) working group focuses on new approaches to network service structuri= ng, insertion, and deployment, providing a framework for the construction of services built using service function chains. The WG f= ocuses on the necessary protocols for the creation of service chains, and t= he transmission of network and service-specific information from the networ= k to service functions, and between service functions. When possible, the WG will extend existing protocols to= provide service chaining functionality, and any protocol extensions will b= e reviewed by both the Network Service Chaining WG and by the WG responsibl= e for the protocol being extended.  

 

Specifically, the Network Se= rvice Chaining WG is chartered to deliver the following work items: 

 

1) Problem Statement: this d= ocument will provide a summary of the problem space to be addressed by the = Network Service Chaining WG including example high-level use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.=

 

2) System Architecture: this= set of documents will provide a description of the architecture building b= locks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pla= ne: this document will describe on the wire data plane encapsulation in sup= port of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docum= ent will address service chaining management in support of (2) including re= levant service chaining MIBs and information models, and service chaining OAM.=

 

Proposed Milestones:<= span style=3D"color:black">

 

Dec 2013 Request publication= of an Informational document defining the Network Service Chaining problem= statement to the IESG=

 

Mar 2014 Request publication= of informational documents defining the system architecture including prot= ocol requirements and framework to the IESG

 

May 2014 Request publication= of a Standards Track document specifying the data-plane (including context= data) for Service Chaining to IESG=

 

May 2014 Request publication= of an informational document specifying Service Chaining Control Plane req= uirements to IESG

 

Dec 2014 Request publication= of Informational document(s) defining Network Service Chaining use cases t= o IESG

 

Dec 2014 Request publication= of informational documents defining Service Chaining manageability includi= ng MIBs, OAM, and information models to IESG 

 

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645B9DD7Fdfweml509mbxchi_-- From melinda.shore@gmail.com Thu Sep 5 09:57: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 3EAFF21E80E8 for ; Thu, 5 Sep 2013 09:57:42 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZHRGZEmMS80 for ; Thu, 5 Sep 2013 09:57:40 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D062311E81C1 for ; Thu, 5 Sep 2013 09:57:33 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so2040797pbc.3 for ; Thu, 05 Sep 2013 09:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ZAiN/2tb0OmAH1cYaAyzDSwFe/F1refnV6js6qviLP4=; b=PWyRGCZNmLUjFH73yyJDoIdxbHNUUb7KleczeNBt79VOqvAM8yxk3FBQ3mlbfp1Lin 0HULs6BiwNgF32qNZ8cXg812+LWkjaIhxVO6xs1/q9qohso4Ep/X/e3HukTEOXdaejdc gKnOKQi9PURLuxEZ53n8uNwX+5jNczozGz3huUUzNmG1O9pjxTRuO9lOWlyIJv+SexLh CkRjPN8M/0yC+FCYZnrXn5mU26mhvviWtSo22WsE/kOY0kPCdbcj3q+1jOcz5Aq+qrFn vyY5QDfMwnqWdiKj72bgDesPk9S+3s7fhxtlALsCH+Y4szOlrJShG4cQQXYAy8f+vV2d L+Wg== X-Received: by 10.66.144.102 with SMTP id sl6mr10202497pab.96.1378400253507; Thu, 05 Sep 2013 09:57:33 -0700 (PDT) Received: from spandex.local (66-230-85-112-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.85.112]) by mx.google.com with ESMTPSA id sy2sm6350636pbc.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Sep 2013 09:57:32 -0700 (PDT) Message-ID: <5228B7FA.80601@gmail.com> Date: Thu, 05 Sep 2013 08:57:30 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: nsc@ietf.org References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <68B171751455884590F8E38E96416F363F676C32@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9DBA7@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9DBA7@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 16:57:42 -0000 On 9/5/13 6:45 AM, Linda Dunbar wrote: > This version hasn’t addressed the comments on Bullet 3 of requiring a > single encapsulation being too limiting or may not even be realistic. There's no agreement that that's the case. Melinda From Ron_Parker@affirmednetworks.com Thu Sep 5 10:44: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 5523611E8258 for ; Thu, 5 Sep 2013 10:44:25 -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 FwNA5QgQxicA for ; Thu, 5 Sep 2013 10:44:20 -0700 (PDT) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3788311E822D for ; Thu, 5 Sep 2013 10:44:19 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0123.003; Thu, 5 Sep 2013 10:44:17 -0700 From: Ron Parker To: Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAJ5aAP//lE3g Date: Thu, 5 Sep 2013 17:44:17 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <68B171751455884590F8E38E96416F363F676C32@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9DBA7@dfweml509-mbx.china.huawei.com> <5228B7FA.80601@gmail.com> In-Reply-To: <5228B7FA.80601@gmail.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 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 17:44:25 -0000 I apologize if I'm being thick on this, but I'm still having trouble with t= he meaning of "encapsulation" here. It has been pointed out that it is th= e thing that carries information like chain id, hop index, and possibly met= adata about the flow, but excludes the "overlay" encapsulation. So if I = think about something that resembles GRE, when we say encapsulation, we are= meaning the part of GRE that has the key but not the part of GRE that adds= another IP header. Where I really get twisted around the axle is if I t= hink about this information being embedded in an IPv4 option or IPv6 extens= ion header. Not that we're necessarily choosing those, but if we did, wou= ld we call that "encapsulation"? Thanks. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Melin= da Shore Sent: Thursday, September 05, 2013 12:58 PM To: nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal On 9/5/13 6:45 AM, Linda Dunbar wrote: > This version hasn't addressed the comments on Bullet 3 of requiring a=20 > single encapsulation being too limiting or may not even be realistic. There's no agreement that that's the case. Melinda _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Thu Sep 5 10:48: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 2AA1A11E81DD for ; Thu, 5 Sep 2013 10:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-dByV4zkjd3 for ; Thu, 5 Sep 2013 10:48:31 -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 9A50B11E81C1 for ; Thu, 5 Sep 2013 10:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2057; q=dns/txt; s=iport; t=1378403311; x=1379612911; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=VswpKQ1yCzWIpEFDKFqXbByqFiMui7DtNbQlov0k618=; b=V2Es1QTzvH6YYNswLUbk4t56VO3C0CnIWj9N4EvA/qGXAAGGTF0wiANv cw3aki+Hv0xk7ZY4bdvOZX44Jj4KZnhZMPniaoQ9lrBdp2UWWSuiiPW0b ibZ0ssprr2esujk5tVvGGr56zPX6zK7EOJ3JB0pdeKLQqIRXqkfjgfGPA c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAIzCKFKtJV2Z/2dsb2JhbABRCoMHNVHBSoErFnSCJAEBAQQBAQE3LQcXBgEIEQQBAQEKFAkuCxQJCAIEARIIh3oMujwEjh2BEgYyAgSDF4EAA6lbgyCCKg X-IronPort-AV: E=Sophos;i="4.90,848,1371081600"; d="scan'208";a="256057335" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 05 Sep 2013 17:48:31 +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 r85HmVP4015506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 17:48:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 12:48:30 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4A= Date: Thu, 5 Sep 2013 17:48:30 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6777F2@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.86.246.115] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 17:48:37 -0000 Hi Ron, By encapsulation we mean something inserted between the transport encapsulation and the original packet payload. There are two things that need to happen; (1) identify that "service chaining" information follows the transport header, and (2) encapsulate the actual service chaining information. Now you could go down the path of trying to force fit the service chaining information into the transport but that imho is a mistake we should avoid. On 9/5/13 1:44 PM, "Ron Parker" wrote: >I apologize if I'm being thick on this, but I'm still having trouble with >the meaning of "encapsulation" here. It has been pointed out that it is >the thing that carries information like chain id, hop index, and possibly >metadata about the flow, but excludes the "overlay" encapsulation. So >if I think about something that resembles GRE, when we say encapsulation, >we are meaning the part of GRE that has the key but not the part of GRE >that adds another IP header. Where I really get twisted around the >axle is if I think about this information being embedded in an IPv4 >option or IPv6 extension header. Not that we're necessarily choosing >those, but if we did, would we call that "encapsulation"? > >Thanks. > > Ron > > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Melinda Shore >Sent: Thursday, September 05, 2013 12:58 PM >To: nsc@ietf.org >Subject: Re: [nsc] NSC Working Group Charter Proposal > >On 9/5/13 6:45 AM, Linda Dunbar wrote: >> This version hasn't addressed the comments on Bullet 3 of requiring a >> single encapsulation being too limiting or may not even be realistic. > >There's no agreement that that's the case. > >Melinda > > > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jmoisand@juniper.net Thu Sep 5 11:14: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 D0D1921E80FD for ; Thu, 5 Sep 2013 11:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HNk-3yqvdoKl for ; Thu, 5 Sep 2013 11:14:23 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1009621E8132 for ; Thu, 5 Sep 2013 11:14:21 -0700 (PDT) Received: from mail142-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 18:14:21 +0000 Received: from mail142-co1 (localhost [127.0.0.1]) by mail142-co1-R.bigfish.com (Postfix) with ESMTP id 508481803A0; Thu, 5 Sep 2013 18:14:21 +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: -19 X-BigFish: VPS-19(zz9371Ic85fhdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail142-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(377454003)(81686001)(63696002)(74706001)(74366001)(76576001)(74876001)(74316001)(81816001)(561944002)(33646001)(19609705001)(18717965001)(65816001)(80976001)(15975445006)(4396001)(74662001)(19300405004)(31966008)(19580395003)(74502001)(50986001)(79102001)(16236675002)(47446002)(83072001)(66066001)(80022001)(77982001)(46102001)(59766001)(49866001)(15202345003)(47736001)(47976001)(81342001)(77096001)(56816003)(76786001)(76796001)(51856001)(19580405001)(54356001)(83322001)(76482001)(81542001)(54316002)(56776001)(53806001)(69226001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB251; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail142-co1 (localhost.localdomain [127.0.0.1]) by mail142-co1 (MessageSwitch) id 1378404858818907_8207; Thu, 5 Sep 2013 18:14:18 +0000 (UTC) Received: from CO1EHSMHS003.bigfish.com (unknown [10.243.78.228]) by mail142-co1.bigfish.com (Postfix) with ESMTP id B5C22200041; Thu, 5 Sep 2013 18:14:18 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS003.bigfish.com (10.243.66.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 18:14:18 +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.353.4; Thu, 5 Sep 2013 18:14:17 +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.745.25; Thu, 5 Sep 2013 18:14:16 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.242]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.242]) with mapi id 15.00.0745.000; Thu, 5 Sep 2013 18:14:15 +0000 From: Jerome Moisand To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgABXk2A= Date: Thu, 5 Sep 2013 18:14:15 +0000 Message-ID: <23ef9ba0d2344ebd82cf4527e062414a@BN1PR05MB251.namprd05.prod.outlook.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <68B171751455884590F8E38E96416F363F676C32@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F676C32@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.232.2] x-forefront-prvs: 096029FF66 Content-Type: multipart/alternative; boundary="_000_23ef9ba0d2344ebd82cf4527e062414aBN1PR05MB251namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 18:14:30 -0000 --_000_23ef9ba0d2344ebd82cf4527e062414aBN1PR05MB251namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As previously mentioned, the control plane is a bit missing. Let me suggest you just amend point 3) to say: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. =3D=3D> 3) Service Chaining Data & Control Plane: this document will describe on th= e wire data plane encapsulation in support of (2). A single encapsulation = will be selected in order to enable interoperability of data plane componen= ts. Supporting control plane protocol elements will be added as needs be (a= s a separate document). From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Thursday, September 05, 2013 7:57 AM To: nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Greetings, I have updated the charter as follows based on all comments received thus f= ar. There have been lots of inputs and this charter may not reflect all of = them (hopefully it is pretty close). Please take time to review and continu= e the discussion. Proposed NSC WG Charter - Take two Existing service insertion and deployment techniques fail to address new ch= allenging requirements raised by the introduction of emerging technologies = such as multi-tenancy, virtualization, elasticity, and rich classification.= Networks, servers, and other storage technologies, let alone applications,= have all undergone significant change in recent years: virtualization, net= work overlays, and orchestration have increasingly become techniques that c= ount and sometimes prevail. All of these have profound effects on network a= nd services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to massively static configuration procedures for network servic= e delivery or update purposes. The structuring and the delivery of new netw= ork services assume the (smart) combination of various service functions as= shared resources, and enable the linkage of these resources using service = chains that represent the abstracted view of the required service functions= , and define the order in which they should be invoked. Such (smart) combin= ations could be made of heterogeneous service functions which may act at va= rious layers of a protocol stack (network layer, application layer, etc). W= hen a service chain is instantiated in a network, specific instances of ser= vice functions are selected, and a service topology is created and used for= forwarding packets according to the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information that is shared across a subset of service functions may enabl= e a richer service chain for more advanced composite services. For example,= shared information, such as the results of a classification function, may = be passed to downstream service functions to enable the offloading of servi= ce function processing or to share information that would otherwise be hard= to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to network service structuring, insertion, and deployment, providing a fram= ework for the construction of services built using service function chains.= The WG focuses on the necessary protocols for the creation of service chai= ns, and the transmission of network and service-specific information from t= he network to service functions, and between service functions. When possib= le, the WG will extend existing protocols to provide service chaining funct= ionality, and any protocol extensions will be reviewed by both the Network = Service Chaining WG and by the WG responsible for the protocol being extend= ed. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including example h= igh-level use cases. Additionally, the WG will normalize on nomenclature a= nd definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining management in= support of (2) including relevant service chaining MIBs and information mo= dels, and service chaining OAM. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including context data) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of Informational document(s) defining Network = Service Chaining use cases to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability including MIBs, OAM, and information models to IESG --_000_23ef9ba0d2344ebd82cf4527e062414aBN1PR05MB251namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As previously mentioned, = the control plane is a bit missing.

 <= /p>

Let me suggest you just a= mend point 3) to say:

 <= /p>

3) Service Chaining Data Pl= ane: this document will describe on the wire data plane encapsulation in su= pport of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 <= /p>

=3D=3D>

 <= /p>

3) Service Chaining Data &a= mp; Control Plane: this document will describe on the wire data plane encap= sulation in support of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components. Sup= porting control plane protocol elements will be added as needs be (as a sep= arate document).

 <= /p>

 <= /p>

From: nsc-boun= ces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, September 05, 2013 7:57 AM
To: nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

Greetings,

 

I have updated the charter = as follows based on all comments received thus far. There have been lots of= inputs and this charter may not reflect all of them (hopefully it is pretty close). Please take time to review and continue the discussio= n.

 

Proposed NSC WG Charter = – Take two

 

Existing service insertion = and deployment techniques fail to address new challenging requirements rais= ed by the introduction of emerging technologies such as multi-tenancy, virtualization, elasticity, and rich classification. Networ= ks, servers, and other storage technologies, let alone applications, have a= ll undergone significant change in recent years: virtualization, network ov= erlays, and orchestration have increasingly become techniques that count and sometimes prevail. All of these have prof= ound effects on network and services design.

 

Today, deploying new servic= es, or making changes to existing services, often requires network topology= changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o massively static configuration procedures for network service delivery or= update purposes. The structuring and the delivery of new network services = assume the (smart) combination of various service functions as shared resources, and enable the linkage of t= hese resources using service chains that represent the abstracted view of t= he required service functions, and define the order in which they should be= invoked. Such (smart) combinations could be made of heterogeneous service functions which may act at various = layers of a protocol stack (network layer, application layer, etc). When a = service chain is instantiated in a network, specific instances of service f= unctions are selected, and a service topology is created and used for forwarding packets according to the servi= ce chain.

 

A basic service chain might= simply utilize an existing overlay technology to force traffic through the= necessary service functions. However, additional information that is shared across a subset of service functions may enable a richer se= rvice chain for more advanced composite services. For example, shared infor= mation, such as the results of a classification function, may be passed to = downstream service functions to enable the offloading of service function processing or to share informati= on that would otherwise be hard to glean. 

 

The Network Service Chainin= g (NSC) working group focuses on new approaches to network service structur= ing, insertion, and deployment, providing a framework for the construction of services built using service function chains. The WG f= ocuses on the necessary protocols for the creation of service chains, and t= he transmission of network and service-specific information from the networ= k to service functions, and between service functions. When possible, the WG will extend existing protocols to= provide service chaining functionality, and any protocol extensions will b= e reviewed by both the Network Service Chaining WG and by the WG responsibl= e for the protocol being extended.  

 

Specifically, the Network S= ervice Chaining WG is chartered to deliver the following work items: <= o:p>

 

1) Problem Statement: this = document will provide a summary of the problem space to be addressed by the= Network Service Chaining WG including example high-level use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.

 

2) System Architecture: thi= s set of documents will provide a description of the architecture building = blocks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pl= ane: this document will describe on the wire data plane encapsulation in su= pport of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docu= ment will address service chaining management in support of (2) including r= elevant service chaining MIBs and information models, and service chaining OAM.

 

Proposed Milestones:

 

Dec 2013 Request publicatio= n of an Informational document defining the Network Service Chaining proble= m statement to the IESG

 

Mar 2014 Request publicatio= n of informational documents defining the system architecture including pro= tocol requirements and framework to the IESG

 

May 2014 Request publicatio= n of a Standards Track document specifying the data-plane (including contex= t data) for Service Chaining to IESG

 

May 2014 Request publicatio= n of an informational document specifying Service Chaining Control Plane re= quirements to IESG

 

Dec 2014 Request publicatio= n of Informational document(s) defining Network Service Chaining use cases = to IESG

 

Dec 2014 Request publicatio= n of informational documents defining Service Chaining manageability includ= ing MIBs, OAM, and information models to IESG 

 

 

 

 

--_000_23ef9ba0d2344ebd82cf4527e062414aBN1PR05MB251namprd05pro_-- From rjs@rob.sh Thu Sep 5 11:41: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 6576A11E80FB for ; Thu, 5 Sep 2013 11:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.068 X-Spam-Level: X-Spam-Status: No, score=-1.068 tagged_above=-999 required=5 tests=[AWL=1.532, 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 IGzwircd9D1K for ; Thu, 5 Sep 2013 11:41:54 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1BE21F9FED for ; Thu, 5 Sep 2013 11:41:53 -0700 (PDT) Received: from [212.183.132.20] (helo=[10.138.2.96]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VHeUE-00087e-Oj; Thu, 05 Sep 2013 19:40:58 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9DD7F@dfweml509-mbx.china.huawei.com> Date: Thu, 5 Sep 2013 19:41:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <80B1F2E3-F111-40C1-9F6E-F0FFBB364A0A@rob.sh> References: <4A95BA014132FF49AE685FAB4B9F17F645B9DBA7@dfweml509-mbx.china.huawei.com> <68B171751455884590F8E38E96416F363F677263@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9DD7F@dfweml509-mbx.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1508) Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 18:41:56 -0000 Linda, I'm afraid to say that I agree that there is not a clear need for = clarification on which layers are targetede. We should allow both L2-3 = chaining and L4-7. Restricting at this time breaks use cases such as = those L4-7 services which are implemented as a "bump in the wire" rather = than being explicitly individual hops (which does not clearly fit into = either of your definitions below). Mechanisms that allow TE may also allow chaining of services -- since = both may be about steering through explicit paths in the network. The = key thing is that the problem statement here is trying to do this for = reasons *other* than those that are typical of TE solutions. Kind regards, r. On 5 Sep 2013, at 17:21, Linda Dunbar wrote: > =20 > The service chaining effort has nothing to do with traffic engineering = and I am puzzled as to why you would think so. > =20 > [Linda]No, I don=92t believe that service chaining effort is about = chaining Layer2/3 links & nodes across network. That is why I sent = several emails on the other email threads to advocate the necessity of = differentiating the =93Services=94 in the context of NSC from typical = Layer2/3 services. > However, some people on the other thread stated that Layer 2/3 nodes = chaining shouldn=92t be excluded. > =20 > I simply want to point out that the current scope doesn=92t have clear = definition about =93services=94. Therefore, the current scope doesn=92t = preclude chaining Layer 2/3 nodes based on control plane policy. (I am = not saying that I want to do so). > =20 > =20 > Linda > =20 > =20 > From: Linda Dunbar > Date: Thursday, September 5, 2013 10:45 AM > To: Microsoft Office User , "nsc@ietf.org" = > Subject: RE: [nsc] NSC Working Group Charter Proposal > =20 > Jim, > =20 > This version hasn=92t addressed the comments on Bullet 3 of requiring = a single encapsulation being too limiting or may not even be realistic. > =20 > Several people on other email thread (i.e. =93outcome of NSC BoF=94) = stated that the =93services=94 in the NSC context can be Layer 2-3 = services or Layer 4-7 services. > =20 > For Layer 2-3 services, IETF has standardized Explicit Routing Object = (ERO) to dictate data flows traversing a pre-determined sequence of = Layer 3 nodes, or using BGP control plane to dictate next hop. =20 > =20 > I am not advocating that policy based routing (e.g. ERO) should be in = the scope of NSC. But I can=92t see how the current proposed scope = excludes those policy based routing schemes that have been deployed in = the industry. > =20 > Linda > =20 > =20 > =20 > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of = Jim Guichard (jguichar) > Sent: Thursday, September 05, 2013 6:57 AM > To: nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal > =20 > Greetings, > =20 > I have updated the charter as follows based on all comments received = thus far. There have been lots of inputs and this charter may not = reflect all of them (hopefully it is pretty close). Please take time to = review and continue the discussion. > =20 > Proposed NSC WG Charter =96 Take two > =20 > Existing service insertion and deployment techniques fail to address = new challenging requirements raised by the introduction of emerging = technologies such as multi-tenancy, virtualization, elasticity, and rich = classification. Networks, servers, and other storage technologies, let = alone applications, have all undergone significant change in recent = years: virtualization, network overlays, and orchestration have = increasingly become techniques that count and sometimes prevail. All of = these have profound effects on network and services design. > =20 > Today, deploying new services, or making changes to existing services, = often requires network topology changes. Adding and removing service = functions is a complex, risky task, that is tied to operationalizing = topological changes leading to massively static configuration procedures = for network service delivery or update purposes. The structuring and the = delivery of new network services assume the (smart) combination of = various service functions as shared resources, and enable the linkage of = these resources using service chains that represent the abstracted view = of the required service functions, and define the order in which they = should be invoked. Such (smart) combinations could be made of = heterogeneous service functions which may act at various layers of a = protocol stack (network layer, application layer, etc). When a service = chain is instantiated in a network, specific instances of service = functions are selected, and a service topology is created and used for = forwarding packets according to the service chain. > =20 > A basic service chain might simply utilize an existing overlay = technology to force traffic through the necessary service functions. = However, additional information that is shared across a subset of = service functions may enable a richer service chain for more advanced = composite services. For example, shared information, such as the results = of a classification function, may be passed to downstream service = functions to enable the offloading of service function processing or to = share information that would otherwise be hard to glean.=20 > =20 > The Network Service Chaining (NSC) working group focuses on new = approaches to network service structuring, insertion, and deployment, = providing a framework for the construction of services built using = service function chains. The WG focuses on the necessary protocols for = the creation of service chains, and the transmission of network and = service-specific information from the network to service functions, and = between service functions. When possible, the WG will extend existing = protocols to provide service chaining functionality, and any protocol = extensions will be reviewed by both the Network Service Chaining WG and = by the WG responsible for the protocol being extended. =20 > =20 > Specifically, the Network Service Chaining WG is chartered to deliver = the following work items:=20 > =20 > 1) Problem Statement: this document will provide a summary of the = problem space to be addressed by the Network Service Chaining WG = including example high-level use cases. Additionally, the WG will = normalize on nomenclature and definitions for Network Service Chaining. > =20 > 2) System Architecture: this set of documents will provide a = description of the architecture building blocks and their relationships = including interconnection, placement of capabilities, and security = models, as well as requirements on the control mechanisms and data plane = encapsulation. > =20 > 3) Service Chaining Data Plane: this document will describe on the = wire data plane encapsulation in support of (2). A single encapsulation = will be selected in order to enable interoperability of data plane = components. > =20 > 4) Manageability: this document will address service chaining = management in support of (2) including relevant service chaining MIBs = and information models, and service chaining OAM. > =20 > Proposed Milestones: > =20 > Dec 2013 Request publication of an Informational document defining the = Network Service Chaining problem statement to the IESG > =20 > Mar 2014 Request publication of informational documents defining the = system architecture including protocol requirements and framework to the = IESG > =20 > May 2014 Request publication of a Standards Track document specifying = the data-plane (including context data) for Service Chaining to IESG > =20 > May 2014 Request publication of an informational document specifying = Service Chaining Control Plane requirements to IESG > =20 > Dec 2014 Request publication of Informational document(s) defining = Network Service Chaining use cases to IESG > =20 > Dec 2014 Request publication of informational documents defining = Service Chaining manageability including MIBs, OAM, and information = models to IESG=20 > =20 > =20 > =20 > =20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From jmh@joelhalpern.com Thu Sep 5 11:45: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 4C26311E80E9 for ; Thu, 5 Sep 2013 11:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 Ywpo2NE6H7qJ for ; Thu, 5 Sep 2013 11:44:56 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 29D1411E81CF for ; Thu, 5 Sep 2013 11:44:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id BF23B201124; Thu, 5 Sep 2013 11:44:54 -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 9EF7A1C07C3; Thu, 5 Sep 2013 11:44:52 -0700 (PDT) Message-ID: <5228D126.1040304@joelhalpern.com> Date: Thu, 05 Sep 2013 14:44:54 -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: Ron Parker References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <68B171751455884590F8E38E96416F363F676C32@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9DBA7@dfweml509-mbx.china.huawei.com> <5228B7FA.80601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "nsc@ietf.org" , Melinda Shore Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 18:45:01 -0000 From where I sit, I think that vague may well be good. For example, I think that there are ways to use MPLS labels or VLAN tags as part of the process of directing packets through service chains. If we agreed on such an approach, that would be part of what we would describe. (Heck, I've seen some strange things. Maybe an IP address can identify a chain?) That does leda to questions of how can we define "one". I am concerned that if we do not at least aim for a single answer, it will be very difficult to get interoperation. Yours, Joel On 9/5/13 1:44 PM, Ron Parker wrote: > I apologize if I'm being thick on this, but I'm still having trouble with the meaning of "encapsulation" here. It has been pointed out that it is the thing that carries information like chain id, hop index, and possibly metadata about the flow, but excludes the "overlay" encapsulation. So if I think about something that resembles GRE, when we say encapsulation, we are meaning the part of GRE that has the key but not the part of GRE that adds another IP header. Where I really get twisted around the axle is if I think about this information being embedded in an IPv4 option or IPv6 extension header. Not that we're necessarily choosing those, but if we did, would we call that "encapsulation"? > > Thanks. > > Ron > > > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Melinda Shore > Sent: Thursday, September 05, 2013 12:58 PM > To: nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal > > On 9/5/13 6:45 AM, Linda Dunbar wrote: >> This version hasn't addressed the comments on Bullet 3 of requiring a >> single encapsulation being too limiting or may not even be realistic. > > There's no agreement that that's the case. > > Melinda > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From Ron_Parker@affirmednetworks.com Thu Sep 5 11:52: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 99E5821E8119 for ; Thu, 5 Sep 2013 11:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 P9J-vc4i5rPk for ; Thu, 5 Sep 2013 11:52:28 -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 BB52721E80EF for ; Thu, 5 Sep 2013 11:52:28 -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; Thu, 5 Sep 2013 11:52:27 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAJ5aAP//lE3ggAB58wD//5m/sA== Date: Thu, 5 Sep 2013 18:52:26 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F6777F2@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6777F2@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 18:52:33 -0000 Thanks for your patience, Jim! Does your description pre-suppose that there is always another IP header ap= plied? For example, an original TCP segment could look like this (assumin= g UDP-based encap for this example): Outer-ip/udp/nsc/inner-ip/tcp/payload I can definitely get my head around that as it is a universal solution that= presumes an IP network, only. I may be misinterpreting but I suspect that some on this thread aren't on t= he same page (at least yet) and may be thinking that in certain network top= ologies the outer IP can/should be avoided. If that is the case, I can'= t see how the nsc information can be inserted after the transport, which wo= uld create something that looks like this: Ip/tcp/nsc/payload Thanks. Ron -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Thursday, September 05, 2013 1:49 PM To: Ron Parker; Melinda Shore; nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Hi Ron, By encapsulation we mean something inserted between the transport encapsula= tion and the original packet payload. There are two things that need to hap= pen; (1) identify that "service chaining" information follows the transport= header, and (2) encapsulate the actual service chaining information. Now y= ou could go down the path of trying to force fit the service chaining infor= mation into the transport but that imho is a mistake we should avoid. On 9/5/13 1:44 PM, "Ron Parker" wrote: >I apologize if I'm being thick on this, but I'm still having trouble with >the meaning of "encapsulation" here. It has been pointed out that it is >the thing that carries information like chain id, hop index, and possibly >metadata about the flow, but excludes the "overlay" encapsulation. So >if I think about something that resembles GRE, when we say=20 >encapsulation, we are meaning the part of GRE that has the key but not the= part of GRE >that adds another IP header. Where I really get twisted around the >axle is if I think about this information being embedded in an IPv4 >option or IPv6 extension header. Not that we're necessarily choosing >those, but if we did, would we call that "encapsulation"? > >Thanks. > > Ron > > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >Melinda Shore >Sent: Thursday, September 05, 2013 12:58 PM >To: nsc@ietf.org >Subject: Re: [nsc] NSC Working Group Charter Proposal > >On 9/5/13 6:45 AM, Linda Dunbar wrote: >> This version hasn't addressed the comments on Bullet 3 of requiring a=20 >> single encapsulation being too limiting or may not even be realistic. > >There's no agreement that that's the case. > >Melinda > > > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From smkumar@cisco.com Thu Sep 5 12:04: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 2D7D621E814C for ; Thu, 5 Sep 2013 12:04:22 -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 v-P8r-KqSkxU for ; Thu, 5 Sep 2013 12:04:17 -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 38EF621E814E for ; Thu, 5 Sep 2013 12:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3898; q=dns/txt; s=iport; t=1378407852; x=1379617452; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=fcdU70qCqv/T054HSADdyN98FeoDxg6Lbt29pRTopWQ=; b=ZjZrXobtD+Oc3Fe3BiBTVBtHVU1fgWe5U6OzySRd0uJhahi6rCAIGnw9 99L+qbm2CsumLFUi9WYg5GZqrh3Jw67dj0/p52gh8zgIMaXWUYhs4xPLY /Dk25C3urws0SbQoMu+bJCgPbdQ4CAwwjq7yLS7m7xKjt804udAld1pBw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFADjVKFKtJXHA/2dsb2JhbABRCoMHNVHBS4ErFnSCJAEBAQQBAQFkBxcGAQgRBAEBAQodLgsUCQgCBAESCBOHZwy6NgSOHYESBjICBIMXgQADlBuVQIMggio X-IronPort-AV: E=Sophos;i="4.90,848,1371081600"; d="scan'208";a="256110479" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 05 Sep 2013 19:03:50 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r85J3lDL007326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 19:03:47 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.152]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 14:03:47 -0500 From: "Surendra Kumar (smkumar)" To: Ron Parker , "Jim Guichard (jguichar)" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAP//jdAA Date: Thu, 5 Sep 2013 19:03:46 +0000 Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C9210F2222@xmb-aln-x09.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.3.6.130613 x-originating-ip: [10.21.85.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 19:04:22 -0000 Just to add, for clarity(hopefully). This is the intent: [Transport-Encapsulation/Header | Service-Encapsulaiton/Header | Original-payload] Where, Original-payload : an IP packet without the layer-2 header or it could be a frame with the L2-header. This depends on the interception layer. Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, =8A Service Encap : is where the service-path-identifier/... Is carried in order to be able to identify the chain or the forwarding path. Surendra. On 9/5/13 11:52 AM, "Ron Parker" wrote: >Thanks for your patience, Jim! > >Does your description pre-suppose that there is always another IP header >applied? For example, an original TCP segment could look like this >(assuming UDP-based encap for this example): > > Outer-ip/udp/nsc/inner-ip/tcp/payload > >I can definitely get my head around that as it is a universal solution >that presumes an IP network, only. > >I may be misinterpreting but I suspect that some on this thread aren't on >the same page (at least yet) and may be thinking that in certain network >topologies the outer IP can/should be avoided. If that is the case, I >can't see how the nsc information can be inserted after the transport, >which would create something that looks like this: > > Ip/tcp/nsc/payload > >Thanks. > > Ron > > >-----Original Message----- >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Thursday, September 05, 2013 1:49 PM >To: Ron Parker; Melinda Shore; nsc@ietf.org >Subject: Re: [nsc] NSC Working Group Charter Proposal > >Hi Ron, > >By encapsulation we mean something inserted between the transport >encapsulation and the original packet payload. There are two things that >need to happen; (1) identify that "service chaining" information follows >the transport header, and (2) encapsulate the actual service chaining >information. Now you could go down the path of trying to force fit the >service chaining information into the transport but that imho is a >mistake we should avoid. > >On 9/5/13 1:44 PM, "Ron Parker" wrote: > >>I apologize if I'm being thick on this, but I'm still having trouble with >>the meaning of "encapsulation" here. It has been pointed out that it is >>the thing that carries information like chain id, hop index, and possibly >>metadata about the flow, but excludes the "overlay" encapsulation. So >>if I think about something that resembles GRE, when we say >>encapsulation, we are meaning the part of GRE that has the key but not >>the part of GRE >>that adds another IP header. Where I really get twisted around the >>axle is if I think about this information being embedded in an IPv4 >>option or IPv6 extension header. Not that we're necessarily choosing >>those, but if we did, would we call that "encapsulation"? >> >>Thanks. >> >> Ron >> >> >>-----Original Message----- >>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>Melinda Shore >>Sent: Thursday, September 05, 2013 12:58 PM >>To: nsc@ietf.org >>Subject: Re: [nsc] NSC Working Group Charter Proposal >> >>On 9/5/13 6:45 AM, Linda Dunbar wrote: >>> This version hasn't addressed the comments on Bullet 3 of requiring a >>> single encapsulation being too limiting or may not even be realistic. >> >>There's no agreement that that's the case. >> >>Melinda >> >> >> >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Thu Sep 5 12:11: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 AA64411E81C6 for ; Thu, 5 Sep 2013 12:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 TJyhWUbMgtHL for ; Thu, 5 Sep 2013 12:11:48 -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 68E3311E80FF for ; Thu, 5 Sep 2013 12:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4186; q=dns/txt; s=iport; t=1378408305; x=1379617905; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Be3vRFnyHcUG2ffO5NNw8mkIDMDxucSiZlQJZKUlk/0=; b=mjVsoNDZJMggTioFutusfvObzeSjIdb+E18MqMMOj9/F2AzLdKjLVRPE 2inPlMp4cwsU7A1T5QI3otpKkdZN3LpMmMaAPVx/St4IES+i/YPiqMDsv bwd+pkzDIl/ek+ncQtzED8az5Zco0Rm4Xj1HmvXccyjLVltuabJyOJnxm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAKLWKFKtJV2d/2dsb2JhbABRCoMHNVHBS4ErFnSCJAEBAQQBAQFkBxcGAQgRBAEBAQodLgsUCQgCBAESCBOHZwy6LQSOHYESBjICBIMXgQADlBuVQIMggio X-IronPort-AV: E=Sophos;i="4.90,849,1371081600"; d="scan'208";a="256105550" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 05 Sep 2013 19:11:44 +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 r85JBibe019395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 19:11:44 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 14:11:43 -0500 From: "Jim Guichard (jguichar)" To: "Surendra Kumar (smkumar)" , Ron Parker , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAP//jdAAgAA0foA= Date: Thu, 5 Sep 2013 19:11:42 +0000 Message-ID: <68B171751455884590F8E38E96416F363F677A40@xmb-rcd-x01.cisco.com> In-Reply-To: <8E86B6E7C6FB9F40A00B0E269045A7C9210F2222@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.246.115] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <4C02CFDA5602514F90909BAB507CB4CC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 19:11:54 -0000 Yes, this is what I have in mind exactly. Ron, let me know if this does not make sense. On 9/5/13 3:03 PM, "Surendra Kumar (smkumar)" wrote: >Just to add, for clarity(hopefully). > >This is the intent: [Transport-Encapsulation/Header | >Service-Encapsulaiton/Header | Original-payload] >Where, >Original-payload : an IP packet without the layer-2 header or it >could be a frame with the L2-header. This depends on the interception >layer. >Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, =A9 >Service Encap : is where the service-path-identifier/... Is >carried in order to be able to identify the chain or the forwarding path. > >Surendra. > >On 9/5/13 11:52 AM, "Ron Parker" wrote: > >>Thanks for your patience, Jim! >> >>Does your description pre-suppose that there is always another IP header >>applied? For example, an original TCP segment could look like this >>(assuming UDP-based encap for this example): >> >> Outer-ip/udp/nsc/inner-ip/tcp/payload >> >>I can definitely get my head around that as it is a universal solution >>that presumes an IP network, only. >> >>I may be misinterpreting but I suspect that some on this thread aren't on >>the same page (at least yet) and may be thinking that in certain network >>topologies the outer IP can/should be avoided. If that is the case, I >>can't see how the nsc information can be inserted after the transport, >>which would create something that looks like this: >> >> Ip/tcp/nsc/payload >> >>Thanks. >> >> Ron >> >> >>-----Original Message----- >>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>Sent: Thursday, September 05, 2013 1:49 PM >>To: Ron Parker; Melinda Shore; nsc@ietf.org >>Subject: Re: [nsc] NSC Working Group Charter Proposal >> >>Hi Ron, >> >>By encapsulation we mean something inserted between the transport >>encapsulation and the original packet payload. There are two things that >>need to happen; (1) identify that "service chaining" information follows >>the transport header, and (2) encapsulate the actual service chaining >>information. Now you could go down the path of trying to force fit the >>service chaining information into the transport but that imho is a >>mistake we should avoid. >> >>On 9/5/13 1:44 PM, "Ron Parker" wrote: >> >>>I apologize if I'm being thick on this, but I'm still having trouble >>>with >>>the meaning of "encapsulation" here. It has been pointed out that it >>>is >>>the thing that carries information like chain id, hop index, and >>>possibly >>>metadata about the flow, but excludes the "overlay" encapsulation. So >>>if I think about something that resembles GRE, when we say >>>encapsulation, we are meaning the part of GRE that has the key but not >>>the part of GRE >>>that adds another IP header. Where I really get twisted around the >>>axle is if I think about this information being embedded in an IPv4 >>>option or IPv6 extension header. Not that we're necessarily choosing >>>those, but if we did, would we call that "encapsulation"? >>> >>>Thanks. >>> >>> Ron >>> >>> >>>-----Original Message----- >>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>>Melinda Shore >>>Sent: Thursday, September 05, 2013 12:58 PM >>>To: nsc@ietf.org >>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>> >>>On 9/5/13 6:45 AM, Linda Dunbar wrote: >>>> This version hasn't addressed the comments on Bullet 3 of requiring a >>>> single encapsulation being too limiting or may not even be realistic. >>> >>>There's no agreement that that's the case. >>> >>>Melinda >>> >>> >>> >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >> >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > From damascene.joachimpillai@verizon.com Thu Sep 5 12:17: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 CB48111E81C8 for ; Thu, 5 Sep 2013 12:17:54 -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 9smJJqVq+d8O for ; Thu, 5 Sep 2013 12:17:49 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id BA58211E81C6 for ; Thu, 5 Sep 2013 12:17:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe01.verizon.com with ESMTP; 05 Sep 2013 19:17:47 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.90,849,1371081600"; d="scan'208";a="541676085" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi02.verizon.com with ESMTP; 05 Sep 2013 19:17:46 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Thu, 5 Sep 2013 15:17:46 -0400 To: "Jim Guichard (jguichar)" , "Surendra Kumar (smkumar)" , Ron Parker , Melinda Shore , "nsc@ietf.org" Date: Thu, 5 Sep 2013 15:17:44 -0400 Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAP//jdAAgAA0foD///DU0A== Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB01233AF61A@FHDP1LUMXC7V31.us.one.verizon.com> References: <8E86B6E7C6FB9F40A00B0E269045A7C9210F2222@xmb-aln-x09.cisco.com> <68B171751455884590F8E38E96416F363F677A40@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F677A40@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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 19:17:55 -0000 Isnt all of these lead to carrying Metadata from application to application= ? -- DJ -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Thursday, September 05, 2013 3:12 PM To: Surendra Kumar (smkumar); Ron Parker; Melinda Shore; nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Yes, this is what I have in mind exactly. Ron, let me know if this does not= make sense. On 9/5/13 3:03 PM, "Surendra Kumar (smkumar)" wrote: >Just to add, for clarity(hopefully). > >This is the intent: [Transport-Encapsulation/Header |=20 >Service-Encapsulaiton/Header | Original-payload] Where, >Original-payload : an IP packet without the layer-2 header or it >could be a frame with the L2-header. This depends on the interception=20 >layer. >Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, =A9 >Service Encap : is where the service-path-identifier/... Is >carried in order to be able to identify the chain or the forwarding path. > >Surendra. > >On 9/5/13 11:52 AM, "Ron Parker" wrote: > >>Thanks for your patience, Jim! >> >>Does your description pre-suppose that there is always another IP header >>applied? For example, an original TCP segment could look like this >>(assuming UDP-based encap for this example): >> >> Outer-ip/udp/nsc/inner-ip/tcp/payload >> >>I can definitely get my head around that as it is a universal solution=20 >>that presumes an IP network, only. >> >>I may be misinterpreting but I suspect that some on this thread aren't=20 >>on the same page (at least yet) and may be thinking that in certain netwo= rk >>topologies the outer IP can/should be avoided. If that is the case, I >>can't see how the nsc information can be inserted after the transport,=20 >>which would create something that looks like this: >> >> Ip/tcp/nsc/payload >> >>Thanks. >> >> Ron >> >> >>-----Original Message----- >>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>Sent: Thursday, September 05, 2013 1:49 PM >>To: Ron Parker; Melinda Shore; nsc@ietf.org >>Subject: Re: [nsc] NSC Working Group Charter Proposal >> >>Hi Ron, >> >>By encapsulation we mean something inserted between the transport=20 >>encapsulation and the original packet payload. There are two things=20 >>that need to happen; (1) identify that "service chaining" information=20 >>follows the transport header, and (2) encapsulate the actual service=20 >>chaining information. Now you could go down the path of trying to=20 >>force fit the service chaining information into the transport but that=20 >>imho is a mistake we should avoid. >> >>On 9/5/13 1:44 PM, "Ron Parker" wrote: >> >>>I apologize if I'm being thick on this, but I'm still having trouble=20 >>>with >>>the meaning of "encapsulation" here. It has been pointed out that it >>>is >>>the thing that carries information like chain id, hop index, and=20 >>>possibly >>>metadata about the flow, but excludes the "overlay" encapsulation. So >>>if I think about something that resembles GRE, when we say=20 >>>encapsulation, we are meaning the part of GRE that has the key but=20 >>>not the part of GRE >>>that adds another IP header. Where I really get twisted around the >>>axle is if I think about this information being embedded in an IPv4 >>>option or IPv6 extension header. Not that we're necessarily choosing >>>those, but if we did, would we call that "encapsulation"? >>> >>>Thanks. >>> >>> Ron >>> >>> >>>-----Original Message----- >>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >>>Melinda Shore >>>Sent: Thursday, September 05, 2013 12:58 PM >>>To: nsc@ietf.org >>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>> >>>On 9/5/13 6:45 AM, Linda Dunbar wrote: >>>> This version hasn't addressed the comments on Bullet 3 of requiring=20 >>>> a single encapsulation being too limiting or may not even be realistic= . >>> >>>There's no agreement that that's the case. >>> >>>Melinda >>> >>> >>> >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >> >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Thu Sep 5 12:22: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 58F0111E810C for ; Thu, 5 Sep 2013 12:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm+ehhLqkiMv for ; Thu, 5 Sep 2013 12:22:20 -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 AC77311E81C6 for ; Thu, 5 Sep 2013 12:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5075; q=dns/txt; s=iport; t=1378408940; x=1379618540; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=i4+eFJYbYK68lo1LkwlbAOGY+jbi5sM4FHHwGgCG1IE=; b=NE3HoQf7k2fLy1dPM9MdWf3Lj+CvsKUNUJhsj3oRicZdTNOaIz6T5Huq hjO+MMtDrUieiPP9J2cwxLIzYMiNjT8jWhjP2NXYkOXU7ZrRLGZpYnDBP +9U0jne9n1j0FXBZcUd9ZLBvf6ZkBaSmSlZkQ/S/8nxZW6ZS/wnESYqR4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFADLZKFKtJXG8/2dsb2JhbABRCoMHNVHBS4ErFnSCJAEBAQQBAQFkBxcGAQgRBAEBAQodLgsUCQgCBAESCBOHVQMPDLopBIx0gSmBEgYyAgSDF4EAA5QblUCDIIIq X-IronPort-AV: E=Sophos;i="4.90,849,1371081600"; d="scan'208";a="256142280" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 05 Sep 2013 19:22:18 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r85JMIqt026527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 19:22:18 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 14:22:17 -0500 From: "Jim Guichard (jguichar)" To: "Joachimpillai, Damascene M" , "Surendra Kumar (smkumar)" , Ron Parker , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAP//jdAAgAA0foD///DU0AACRKGA Date: Thu, 5 Sep 2013 19:22:17 +0000 Message-ID: <68B171751455884590F8E38E96416F363F677AEE@xmb-rcd-x01.cisco.com> In-Reply-To: <689CE984BDBA8B4CAF3EA6E2CDC5CACB01233AF61A@FHDP1LUMXC7V31.us.one.verizon.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.86.246.115] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 19:22:27 -0000 That is certainly one possibility (although not required for all services) and the data plane should enable that functionality yes. On 9/5/13 3:17 PM, "Joachimpillai, Damascene M" wrote: >Isnt all of these lead to carrying Metadata from application to >application? > >-- DJ > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim >Guichard (jguichar) >Sent: Thursday, September 05, 2013 3:12 PM >To: Surendra Kumar (smkumar); Ron Parker; Melinda Shore; nsc@ietf.org >Subject: Re: [nsc] NSC Working Group Charter Proposal > >Yes, this is what I have in mind exactly. Ron, let me know if this does >not make sense. > >On 9/5/13 3:03 PM, "Surendra Kumar (smkumar)" wrote: > >>Just to add, for clarity(hopefully). >> >>This is the intent: [Transport-Encapsulation/Header | >>Service-Encapsulaiton/Header | Original-payload] Where, >>Original-payload : an IP packet without the layer-2 header or it >>could be a frame with the L2-header. This depends on the interception >>layer. >>Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, =A9 >>Service Encap : is where the service-path-identifier/... Is >>carried in order to be able to identify the chain or the forwarding path. >> >>Surendra. >> >>On 9/5/13 11:52 AM, "Ron Parker" wrote: >> >>>Thanks for your patience, Jim! >>> >>>Does your description pre-suppose that there is always another IP header >>>applied? For example, an original TCP segment could look like this >>>(assuming UDP-based encap for this example): >>> >>> Outer-ip/udp/nsc/inner-ip/tcp/payload >>> >>>I can definitely get my head around that as it is a universal solution >>>that presumes an IP network, only. >>> >>>I may be misinterpreting but I suspect that some on this thread aren't >>>on the same page (at least yet) and may be thinking that in certain >>>network >>>topologies the outer IP can/should be avoided. If that is the case, >>>I >>>can't see how the nsc information can be inserted after the transport, >>>which would create something that looks like this: >>> >>> Ip/tcp/nsc/payload >>> >>>Thanks. >>> >>> Ron >>> >>> >>>-----Original Message----- >>>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>Sent: Thursday, September 05, 2013 1:49 PM >>>To: Ron Parker; Melinda Shore; nsc@ietf.org >>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>> >>>Hi Ron, >>> >>>By encapsulation we mean something inserted between the transport >>>encapsulation and the original packet payload. There are two things >>>that need to happen; (1) identify that "service chaining" information >>>follows the transport header, and (2) encapsulate the actual service >>>chaining information. Now you could go down the path of trying to >>>force fit the service chaining information into the transport but that >>>imho is a mistake we should avoid. >>> >>>On 9/5/13 1:44 PM, "Ron Parker" wrote: >>> >>>>I apologize if I'm being thick on this, but I'm still having trouble >>>>with >>>>the meaning of "encapsulation" here. It has been pointed out that it >>>>is >>>>the thing that carries information like chain id, hop index, and >>>>possibly >>>>metadata about the flow, but excludes the "overlay" encapsulation. >>>>So >>>>if I think about something that resembles GRE, when we say >>>>encapsulation, we are meaning the part of GRE that has the key but >>>>not the part of GRE >>>>that adds another IP header. Where I really get twisted around the >>>>axle is if I think about this information being embedded in an IPv4 >>>>option or IPv6 extension header. Not that we're necessarily choosing >>>>those, but if we did, would we call that "encapsulation"? >>>> >>>>Thanks. >>>> >>>> Ron >>>> >>>> >>>>-----Original Message----- >>>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>>>Melinda Shore >>>>Sent: Thursday, September 05, 2013 12:58 PM >>>>To: nsc@ietf.org >>>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>>> >>>>On 9/5/13 6:45 AM, Linda Dunbar wrote: >>>>> This version hasn't addressed the comments on Bullet 3 of requiring >>>>> a single encapsulation being too limiting or may not even be >>>>>realistic. >>>> >>>>There's no agreement that that's the case. >>>> >>>>Melinda >>>> >>>> >>>> >>>>_______________________________________________ >>>>nsc mailing list >>>>nsc@ietf.org >>>>https://www.ietf.org/mailman/listinfo/nsc >>>>_______________________________________________ >>>>nsc mailing list >>>>nsc@ietf.org >>>>https://www.ietf.org/mailman/listinfo/nsc >>> >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >> > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Thu Sep 5 12:22: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 EF55B21E8086 for ; Thu, 5 Sep 2013 12:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 aZNrSKVRm7iy for ; Thu, 5 Sep 2013 12:22:41 -0700 (PDT) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2D66811E810C for ; Thu, 5 Sep 2013 12:22:41 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0123.003; Thu, 5 Sep 2013 12:22:29 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , "Surendra Kumar (smkumar)" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAJ5aAP//lE3ggAB58wD//5m/sIAAe0kAgAACNwD//4z9QA== Date: Thu, 5 Sep 2013 19:22:29 +0000 Message-ID: References: <8E86B6E7C6FB9F40A00B0E269045A7C9210F2222@xmb-aln-x09.cisco.com> <68B171751455884590F8E38E96416F363F677A40@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F677A40@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: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 19:22:52 -0000 Yes, that makes sense. I think I was stuck on "transport" as "layer 4". = The term is used more broadly, here. So when we say a single encapsulati= on, we are really saying a single service-encapsulation/header and we are n= ot saying a single complete transformation of the original IP packet, as th= at would be dependent on the choice of "transport". Thanks, all. Ron -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Thursday, September 05, 2013 3:12 PM To: Surendra Kumar (smkumar); Ron Parker; Melinda Shore; nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Yes, this is what I have in mind exactly. Ron, let me know if this does not= make sense. On 9/5/13 3:03 PM, "Surendra Kumar (smkumar)" wrote: >Just to add, for clarity(hopefully). > >This is the intent: [Transport-Encapsulation/Header |=20 >Service-Encapsulaiton/Header | Original-payload] Where, >Original-payload : an IP packet without the layer-2 header or it >could be a frame with the L2-header. This depends on the interception=20 >layer. >Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, =A9 >Service Encap : is where the service-path-identifier/... Is >carried in order to be able to identify the chain or the forwarding path. > >Surendra. > >On 9/5/13 11:52 AM, "Ron Parker" wrote: > >>Thanks for your patience, Jim! >> >>Does your description pre-suppose that there is always another IP header >>applied? For example, an original TCP segment could look like this >>(assuming UDP-based encap for this example): >> >> Outer-ip/udp/nsc/inner-ip/tcp/payload >> >>I can definitely get my head around that as it is a universal solution=20 >>that presumes an IP network, only. >> >>I may be misinterpreting but I suspect that some on this thread aren't=20 >>on the same page (at least yet) and may be thinking that in certain netwo= rk >>topologies the outer IP can/should be avoided. If that is the case, I >>can't see how the nsc information can be inserted after the transport,=20 >>which would create something that looks like this: >> >> Ip/tcp/nsc/payload >> >>Thanks. >> >> Ron >> >> >>-----Original Message----- >>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>Sent: Thursday, September 05, 2013 1:49 PM >>To: Ron Parker; Melinda Shore; nsc@ietf.org >>Subject: Re: [nsc] NSC Working Group Charter Proposal >> >>Hi Ron, >> >>By encapsulation we mean something inserted between the transport=20 >>encapsulation and the original packet payload. There are two things=20 >>that need to happen; (1) identify that "service chaining" information=20 >>follows the transport header, and (2) encapsulate the actual service=20 >>chaining information. Now you could go down the path of trying to=20 >>force fit the service chaining information into the transport but that=20 >>imho is a mistake we should avoid. >> >>On 9/5/13 1:44 PM, "Ron Parker" wrote: >> >>>I apologize if I'm being thick on this, but I'm still having trouble=20 >>>with >>>the meaning of "encapsulation" here. It has been pointed out that it >>>is >>>the thing that carries information like chain id, hop index, and=20 >>>possibly >>>metadata about the flow, but excludes the "overlay" encapsulation. So >>>if I think about something that resembles GRE, when we say=20 >>>encapsulation, we are meaning the part of GRE that has the key but=20 >>>not the part of GRE >>>that adds another IP header. Where I really get twisted around the >>>axle is if I think about this information being embedded in an IPv4 >>>option or IPv6 extension header. Not that we're necessarily choosing >>>those, but if we did, would we call that "encapsulation"? >>> >>>Thanks. >>> >>> Ron >>> >>> >>>-----Original Message----- >>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >>>Melinda Shore >>>Sent: Thursday, September 05, 2013 12:58 PM >>>To: nsc@ietf.org >>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>> >>>On 9/5/13 6:45 AM, Linda Dunbar wrote: >>>> This version hasn't addressed the comments on Bullet 3 of requiring=20 >>>> a single encapsulation being too limiting or may not even be realistic= . >>> >>>There's no agreement that that's the case. >>> >>>Melinda >>> >>> >>> >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >> >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > From jguichar@cisco.com Thu Sep 5 12:25: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 EC96F11E810A for ; Thu, 5 Sep 2013 12:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 hSns24eLoVIt for ; Thu, 5 Sep 2013 12:25:17 -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 8BD7521F9CB0 for ; Thu, 5 Sep 2013 12:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5252; q=dns/txt; s=iport; t=1378409116; x=1379618716; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=CMcckxHmMvcBoh4VS4KN2RyCd/Kag6GVij9kg7K5Pqo=; b=aXLKLGyqGMFfDk16DemcZPRgdIEZHKNHqHMOs9+rSpaodIHHXv+O2jzF +vTQ2oCCYcakb9FVIeeRykTmCrRS4hS2q9zMHW3J7ShcT96N7S1DtP4Cz WcX0EYPGSlnpUpSZJvFV77VO4dTeD8pkjcbkYtFf6DfdEqGv2sN7NeOix 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAObZKFKtJV2Z/2dsb2JhbABRCoMHNVHBS4ErFnSCJAEBAQQBAQFkBxcGAQgRBAEBAQodLgsUCQgCBAESCBOHZwy6KQSOHYESBjICBIMXgQADlBuVQIMggio X-IronPort-AV: E=Sophos;i="4.90,849,1371081600"; d="scan'208";a="256122670" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 05 Sep 2013 19:25:16 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r85JPFDS023821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 19:25:15 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 14:25:15 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker , "Surendra Kumar (smkumar)" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAP//jdAAgAA0foCAAEYXgP//vbUA Date: Thu, 5 Sep 2013 19:25:14 +0000 Message-ID: <68B171751455884590F8E38E96416F363F677B60@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.86.246.115] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 19:25:24 -0000 Yes exactly. The point being the service encapsulation should be *independent* of the transport so that we don't get into the game of trying to retrofit all possible transport encapsulations. On 9/5/13 3:22 PM, "Ron Parker" wrote: >Yes, that makes sense. I think I was stuck on "transport" as "layer 4". > The term is used more broadly, here. So when we say a single >encapsulation, we are really saying a single service-encapsulation/header >and we are not saying a single complete transformation of the original IP >packet, as that would be dependent on the choice of "transport". > >Thanks, all. > > Ron > > >-----Original Message----- >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Thursday, September 05, 2013 3:12 PM >To: Surendra Kumar (smkumar); Ron Parker; Melinda Shore; nsc@ietf.org >Subject: Re: [nsc] NSC Working Group Charter Proposal > >Yes, this is what I have in mind exactly. Ron, let me know if this does >not make sense. > >On 9/5/13 3:03 PM, "Surendra Kumar (smkumar)" wrote: > >>Just to add, for clarity(hopefully). >> >>This is the intent: [Transport-Encapsulation/Header | >>Service-Encapsulaiton/Header | Original-payload] Where, >>Original-payload : an IP packet without the layer-2 header or it >>could be a frame with the L2-header. This depends on the interception >>layer. >>Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, =A9 >>Service Encap : is where the service-path-identifier/... Is >>carried in order to be able to identify the chain or the forwarding path. >> >>Surendra. >> >>On 9/5/13 11:52 AM, "Ron Parker" wrote: >> >>>Thanks for your patience, Jim! >>> >>>Does your description pre-suppose that there is always another IP header >>>applied? For example, an original TCP segment could look like this >>>(assuming UDP-based encap for this example): >>> >>> Outer-ip/udp/nsc/inner-ip/tcp/payload >>> >>>I can definitely get my head around that as it is a universal solution >>>that presumes an IP network, only. >>> >>>I may be misinterpreting but I suspect that some on this thread aren't >>>on the same page (at least yet) and may be thinking that in certain >>>network >>>topologies the outer IP can/should be avoided. If that is the case, >>>I >>>can't see how the nsc information can be inserted after the transport, >>>which would create something that looks like this: >>> >>> Ip/tcp/nsc/payload >>> >>>Thanks. >>> >>> Ron >>> >>> >>>-----Original Message----- >>>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>Sent: Thursday, September 05, 2013 1:49 PM >>>To: Ron Parker; Melinda Shore; nsc@ietf.org >>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>> >>>Hi Ron, >>> >>>By encapsulation we mean something inserted between the transport >>>encapsulation and the original packet payload. There are two things >>>that need to happen; (1) identify that "service chaining" information >>>follows the transport header, and (2) encapsulate the actual service >>>chaining information. Now you could go down the path of trying to >>>force fit the service chaining information into the transport but that >>>imho is a mistake we should avoid. >>> >>>On 9/5/13 1:44 PM, "Ron Parker" wrote: >>> >>>>I apologize if I'm being thick on this, but I'm still having trouble >>>>with >>>>the meaning of "encapsulation" here. It has been pointed out that it >>>>is >>>>the thing that carries information like chain id, hop index, and >>>>possibly >>>>metadata about the flow, but excludes the "overlay" encapsulation. >>>>So >>>>if I think about something that resembles GRE, when we say >>>>encapsulation, we are meaning the part of GRE that has the key but >>>>not the part of GRE >>>>that adds another IP header. Where I really get twisted around the >>>>axle is if I think about this information being embedded in an IPv4 >>>>option or IPv6 extension header. Not that we're necessarily choosing >>>>those, but if we did, would we call that "encapsulation"? >>>> >>>>Thanks. >>>> >>>> Ron >>>> >>>> >>>>-----Original Message----- >>>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>>>Melinda Shore >>>>Sent: Thursday, September 05, 2013 12:58 PM >>>>To: nsc@ietf.org >>>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>>> >>>>On 9/5/13 6:45 AM, Linda Dunbar wrote: >>>>> This version hasn't addressed the comments on Bullet 3 of requiring >>>>> a single encapsulation being too limiting or may not even be >>>>>realistic. >>>> >>>>There's no agreement that that's the case. >>>> >>>>Melinda >>>> >>>> >>>> >>>>_______________________________________________ >>>>nsc mailing list >>>>nsc@ietf.org >>>>https://www.ietf.org/mailman/listinfo/nsc >>>>_______________________________________________ >>>>nsc mailing list >>>>nsc@ietf.org >>>>https://www.ietf.org/mailman/listinfo/nsc >>> >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >> > From jmh@joelhalpern.com Thu Sep 5 12:30: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 F2C3211E81CE for ; Thu, 5 Sep 2013 12:30:03 -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 6zR6STw1CEww for ; Thu, 5 Sep 2013 12:29:59 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id E02FC11E810A for ; Thu, 5 Sep 2013 12:29:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id BFBF83215F6; Thu, 5 Sep 2013 12:29:58 -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 3CEDD3215ED; Thu, 5 Sep 2013 12:29:57 -0700 (PDT) Message-ID: <5228DBB7.5030505@joelhalpern.com> Date: Thu, 05 Sep 2013 15:29:59 -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: "Surendra Kumar (smkumar)" References: <8E86B6E7C6FB9F40A00B0E269045A7C9210F2222@xmb-aln-x09.cisco.com> In-Reply-To: <8E86B6E7C6FB9F40A00B0E269045A7C9210F2222@xmb-aln-x09.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore , Ron Parker Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 19:30:04 -0000 We are getting into details of the archtiecture which I would like to debate once we have a charter. But just to put stake in the ground, it seems to me that we want to at least enable the transport-encaps to carry service-chain forwarding information, particularly so that we can use existing forwarding hardware whenever possible. Yes, we can assume architecturally that the IP / Ethernet headers merely identify the next hop in the chain and chain identification is always encapsulated. But it seems at least premature to make that assumption. Yours, Joel PS: Note, I do understand that we need to carry other information in the packet to assist in the service / chaining. For example, I have applications where I need to retain subscriber identity as metadata. On 9/5/13 3:03 PM, Surendra Kumar (smkumar) wrote: > Just to add, for clarity(hopefully). > > This is the intent: [Transport-Encapsulation/Header | > Service-Encapsulaiton/Header | Original-payload] > Where, > Original-payload : an IP packet without the layer-2 header or it > could be a frame with the L2-header. This depends on the interception > layer. > Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, Š > Service Encap : is where the service-path-identifier/... Is > carried in order to be able to identify the chain or the forwarding path. > > Surendra. > > On 9/5/13 11:52 AM, "Ron Parker" wrote: > >> Thanks for your patience, Jim! >> >> Does your description pre-suppose that there is always another IP header >> applied? For example, an original TCP segment could look like this >> (assuming UDP-based encap for this example): >> >> Outer-ip/udp/nsc/inner-ip/tcp/payload >> >> I can definitely get my head around that as it is a universal solution >> that presumes an IP network, only. >> >> I may be misinterpreting but I suspect that some on this thread aren't on >> the same page (at least yet) and may be thinking that in certain network >> topologies the outer IP can/should be avoided. If that is the case, I >> can't see how the nsc information can be inserted after the transport, >> which would create something that looks like this: >> >> Ip/tcp/nsc/payload >> >> Thanks. >> >> Ron >> >> >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Thursday, September 05, 2013 1:49 PM >> To: Ron Parker; Melinda Shore; nsc@ietf.org >> Subject: Re: [nsc] NSC Working Group Charter Proposal >> >> Hi Ron, >> >> By encapsulation we mean something inserted between the transport >> encapsulation and the original packet payload. There are two things that >> need to happen; (1) identify that "service chaining" information follows >> the transport header, and (2) encapsulate the actual service chaining >> information. Now you could go down the path of trying to force fit the >> service chaining information into the transport but that imho is a >> mistake we should avoid. >> >> On 9/5/13 1:44 PM, "Ron Parker" wrote: >> >>> I apologize if I'm being thick on this, but I'm still having trouble with >>> the meaning of "encapsulation" here. It has been pointed out that it is >>> the thing that carries information like chain id, hop index, and possibly >>> metadata about the flow, but excludes the "overlay" encapsulation. So >>> if I think about something that resembles GRE, when we say >>> encapsulation, we are meaning the part of GRE that has the key but not >>> the part of GRE >>> that adds another IP header. Where I really get twisted around the >>> axle is if I think about this information being embedded in an IPv4 >>> option or IPv6 extension header. Not that we're necessarily choosing >>> those, but if we did, would we call that "encapsulation"? >>> >>> Thanks. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>> Melinda Shore >>> Sent: Thursday, September 05, 2013 12:58 PM >>> To: nsc@ietf.org >>> Subject: Re: [nsc] NSC Working Group Charter Proposal >>> >>> On 9/5/13 6:45 AM, Linda Dunbar wrote: >>>> This version hasn't addressed the comments on Bullet 3 of requiring a >>>> single encapsulation being too limiting or may not even be realistic. >>> >>> There's no agreement that that's the case. >>> >>> Melinda >>> >>> >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From damascene.joachimpillai@verizon.com Thu Sep 5 12:31: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 2A33811E81D3 for ; Thu, 5 Sep 2013 12:31:47 -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 KSL19cjdV8jU for ; Thu, 5 Sep 2013 12:31:41 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id 35B7A11E81D1 for ; Thu, 5 Sep 2013 12:31:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe01.verizonbusiness.com with ESMTP; 05 Sep 2013 19:31:39 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.90,849,1371081600"; d="scan'208";a="551783413" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 05 Sep 2013 19:31:39 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Thu, 5 Sep 2013 15:31:39 -0400 To: "Jim Guichard (jguichar)" , "Surendra Kumar (smkumar)" , Ron Parker , Melinda Shore , "nsc@ietf.org" Date: Thu, 5 Sep 2013 15:31:38 -0400 Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAP//jdAAgAA0foD///DU0AACRKGAAAHHymA= Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB01233AF64A@FHDP1LUMXC7V31.us.one.verizon.com> References: <689CE984BDBA8B4CAF3EA6E2CDC5CACB01233AF61A@FHDP1LUMXC7V31.us.one.verizon.com> <68B171751455884590F8E38E96416F363F677AEE@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F677AEE@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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 19:31:47 -0000 So what is the encapsulation carrying? -- DJ -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Thursday, September 05, 2013 3:22 PM To: Joachimpillai, Damascene M; Surendra Kumar (smkumar); Ron Parker; Melin= da Shore; nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal That is certainly one possibility (although not required for all services) = and the data plane should enable that functionality yes. On 9/5/13 3:17 PM, "Joachimpillai, Damascene M" wrote: >Isnt all of these lead to carrying Metadata from application to=20 >application? > >-- DJ > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >Jim Guichard (jguichar) >Sent: Thursday, September 05, 2013 3:12 PM >To: Surendra Kumar (smkumar); Ron Parker; Melinda Shore; nsc@ietf.org >Subject: Re: [nsc] NSC Working Group Charter Proposal > >Yes, this is what I have in mind exactly. Ron, let me know if this does=20 >not make sense. > >On 9/5/13 3:03 PM, "Surendra Kumar (smkumar)" wrote: > >>Just to add, for clarity(hopefully). >> >>This is the intent: [Transport-Encapsulation/Header |=20 >>Service-Encapsulaiton/Header | Original-payload] Where, >>Original-payload : an IP packet without the layer-2 header or it >>could be a frame with the L2-header. This depends on the interception=20 >>layer. >>Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, =A9 >>Service Encap : is where the service-path-identifier/... Is >>carried in order to be able to identify the chain or the forwarding path. >> >>Surendra. >> >>On 9/5/13 11:52 AM, "Ron Parker" wrote: >> >>>Thanks for your patience, Jim! >>> >>>Does your description pre-suppose that there is always another IP header >>>applied? For example, an original TCP segment could look like this >>>(assuming UDP-based encap for this example): >>> >>> Outer-ip/udp/nsc/inner-ip/tcp/payload >>> >>>I can definitely get my head around that as it is a universal=20 >>>solution that presumes an IP network, only. >>> >>>I may be misinterpreting but I suspect that some on this thread=20 >>>aren't on the same page (at least yet) and may be thinking that in=20 >>>certain network >>>topologies the outer IP can/should be avoided. If that is the case, >>>I >>>can't see how the nsc information can be inserted after the=20 >>>transport, which would create something that looks like this: >>> >>> Ip/tcp/nsc/payload >>> >>>Thanks. >>> >>> Ron >>> >>> >>>-----Original Message----- >>>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>Sent: Thursday, September 05, 2013 1:49 PM >>>To: Ron Parker; Melinda Shore; nsc@ietf.org >>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>> >>>Hi Ron, >>> >>>By encapsulation we mean something inserted between the transport=20 >>>encapsulation and the original packet payload. There are two things=20 >>>that need to happen; (1) identify that "service chaining" information=20 >>>follows the transport header, and (2) encapsulate the actual service=20 >>>chaining information. Now you could go down the path of trying to=20 >>>force fit the service chaining information into the transport but=20 >>>that imho is a mistake we should avoid. >>> >>>On 9/5/13 1:44 PM, "Ron Parker" wrote: >>> >>>>I apologize if I'm being thick on this, but I'm still having trouble=20 >>>>with >>>>the meaning of "encapsulation" here. It has been pointed out that it >>>>is >>>>the thing that carries information like chain id, hop index, and=20 >>>>possibly metadata about the flow, but excludes the "overlay"=20 >>>>encapsulation. >>>>So >>>>if I think about something that resembles GRE, when we say=20 >>>>encapsulation, we are meaning the part of GRE that has the key but=20 >>>>not the part of GRE >>>>that adds another IP header. Where I really get twisted around the >>>>axle is if I think about this information being embedded in an IPv4 >>>>option or IPv6 extension header. Not that we're necessarily choosing >>>>those, but if we did, would we call that "encapsulation"? >>>> >>>>Thanks. >>>> >>>> Ron >>>> >>>> >>>>-----Original Message----- >>>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>>>Of Melinda Shore >>>>Sent: Thursday, September 05, 2013 12:58 PM >>>>To: nsc@ietf.org >>>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>>> >>>>On 9/5/13 6:45 AM, Linda Dunbar wrote: >>>>> This version hasn't addressed the comments on Bullet 3 of=20 >>>>>requiring a single encapsulation being too limiting or may not=20 >>>>>even be realistic. >>>> >>>>There's no agreement that that's the case. >>>> >>>>Melinda >>>> >>>> >>>> >>>>_______________________________________________ >>>>nsc mailing list >>>>nsc@ietf.org >>>>https://www.ietf.org/mailman/listinfo/nsc >>>>_______________________________________________ >>>>nsc mailing list >>>>nsc@ietf.org >>>>https://www.ietf.org/mailman/listinfo/nsc >>> >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >> > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From melinda.shore@gmail.com Thu Sep 5 12:31: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 19FC321E8144 for ; Thu, 5 Sep 2013 12:31:53 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGninMosLCv6 for ; Thu, 5 Sep 2013 12:31:52 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8D08021E813C for ; Thu, 5 Sep 2013 12:31:52 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lj1so2349508pab.15 for ; Thu, 05 Sep 2013 12:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HPXvNeUjw7e8igGdRLBZHCZpOk9j+bPYOn3An8xNdAs=; b=h/iWMx4YogBJw1VI3/RM0H1XNTLUX25PN3QsgR6nxHyqMsXqt88fBJEKn2aoMIesJE EgfIhqaoFHSpU2YYaWNbhBvuMmx3GN9c8cV49lidqvtHBueFhXqOpq7oSO3S3osmmOlQ 1gvPVLmehT1vnmvMl6j7F8YvCf2zhqzRwzphvfDCFf9wHZrOfaH2KOuafiAtCs3xXKr5 mB/MpEZubzTvJI7y70qidA52iJtBQr1yQDVMKV5ZREg1D+CWLhLFVVAPrOR+Fb+G4Wqs symFM7/MEAYM7i47t752xsS7SFX/1Of+5lZEwr3X+YFOxh6BBTjLN0Tcuh011UL6JsU6 JMJQ== X-Received: by 10.66.242.17 with SMTP id wm17mr11125004pac.102.1378409512266; Thu, 05 Sep 2013 12:31:52 -0700 (PDT) Received: from spandex.local (66-230-85-112-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.85.112]) by mx.google.com with ESMTPSA id in2sm37370774pbc.37.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Sep 2013 12:31:51 -0700 (PDT) Message-ID: <5228DC25.6010306@gmail.com> Date: Thu, 05 Sep 2013 11:31:49 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Surendra Kumar (smkumar)" References: <8E86B6E7C6FB9F40A00B0E269045A7C9210F2222@xmb-aln-x09.cisco.com> In-Reply-To: <8E86B6E7C6FB9F40A00B0E269045A7C9210F2222@xmb-aln-x09.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "nsc@ietf.org" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 19:31:53 -0000 On 9/5/13 11:03 AM, Surendra Kumar (smkumar) wrote: > Just to add, for clarity(hopefully). > > This is the intent: [Transport-Encapsulation/Header | > Service-Encapsulaiton/Header | Original-payload] > Where, > Original-payload : an IP packet without the layer-2 header or it > could be a frame with the L2-header. This depends on the interception > layer. > Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, Š > Service Encap : is where the service-path-identifier/... Is > carried in order to be able to identify the chain or the forwarding path. I think this is quite helpful, actually. I think some of the discussion of layering, or at least some of the discussion of layering, has been a little too fuzzy. The IP stack does not break down that cleanly into OSI layers and so when someone says "Layer 4" it's not always clear what they mean. Bringing specificity to the discussion is extremely useful. Melinda From jguichar@cisco.com Thu Sep 5 12:36: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 BCF3D11E81D1 for ; Thu, 5 Sep 2013 12:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 1N4UfO2Uh2zP for ; Thu, 5 Sep 2013 12:35:53 -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 9986A11E81CE for ; Thu, 5 Sep 2013 12:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6217; q=dns/txt; s=iport; t=1378409752; x=1379619352; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=JrEoMBmzq3FMkLduV1OhPSpkhlu46FF80oV3oCzthUI=; b=MdJYIQ+VuLNY1slg5BEU5aqGc/1hWREsTmvi959b6LGdu2BDla0Ig1Ci F+e78s6Asyo6TxxUZMizy7lYLscJzAORya3dQ+c2RRrtP/V+ltYNS2sOr /yR16KTixDc6Iy7nHa6zzqeFcD3P4YGBsPR0DoHOeoJnj3NaPzitavMOw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAHXcKFKtJV2Z/2dsb2JhbABRCoMHNVHBS4ErFnSCJAEBAQQBAQFkBxcGAQgRBAEBAQodLgsUCQgCBAESCBOHVQMPDLowBIx0gSmBEgYyAgSDF4EAA5QblUCDIIIq X-IronPort-AV: E=Sophos;i="4.90,849,1371081600"; d="scan'208";a="256099065" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 05 Sep 2013 19:35:50 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r85JZot0008093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 19:35:50 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 14:35:50 -0500 From: "Jim Guichard (jguichar)" To: "Joachimpillai, Damascene M" , "Surendra Kumar (smkumar)" , Ron Parker , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAP//jdAAgAA0foD///DU0AACRKGAAAHHymD///WJgA== Date: Thu, 5 Sep 2013 19:35:49 +0000 Message-ID: <68B171751455884590F8E38E96416F363F677C06@xmb-rcd-x01.cisco.com> In-Reply-To: <689CE984BDBA8B4CAF3EA6E2CDC5CACB01233AF64A@FHDP1LUMXC7V31.us.one.verizon.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.86.246.115] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 19:36:07 -0000 That's something that we would debate within the WG and as Joel said it is perhaps premature to be discussing it now. However, to answer your question, in the absence of metadata the minimum would be to carry a service path identifier (that is used to identify a given service chain) and I would argue an index into the service chain (so that a receiving network node is able to identify which of the service functions within the service chain it should apply). An example of what I am thinking is given in draft-quinn-nsh. On 9/5/13 3:31 PM, "Joachimpillai, Damascene M" wrote: >So what is the encapsulation carrying? > >-- DJ > >-----Original Message----- >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Thursday, September 05, 2013 3:22 PM >To: Joachimpillai, Damascene M; Surendra Kumar (smkumar); Ron Parker; >Melinda Shore; nsc@ietf.org >Subject: Re: [nsc] NSC Working Group Charter Proposal > >That is certainly one possibility (although not required for all >services) and the data plane should enable that functionality yes. > >On 9/5/13 3:17 PM, "Joachimpillai, Damascene M" > wrote: > >>Isnt all of these lead to carrying Metadata from application to >>application? >> >>-- DJ >> >>-----Original Message----- >>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>Jim Guichard (jguichar) >>Sent: Thursday, September 05, 2013 3:12 PM >>To: Surendra Kumar (smkumar); Ron Parker; Melinda Shore; nsc@ietf.org >>Subject: Re: [nsc] NSC Working Group Charter Proposal >> >>Yes, this is what I have in mind exactly. Ron, let me know if this does >>not make sense. >> >>On 9/5/13 3:03 PM, "Surendra Kumar (smkumar)" wrote: >> >>>Just to add, for clarity(hopefully). >>> >>>This is the intent: [Transport-Encapsulation/Header | >>>Service-Encapsulaiton/Header | Original-payload] Where, >>>Original-payload : an IP packet without the layer-2 header or it >>>could be a frame with the L2-header. This depends on the interception >>>layer. >>>Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, =A9 >>>Service Encap : is where the service-path-identifier/... Is >>>carried in order to be able to identify the chain or the forwarding >>>path. >>> >>>Surendra. >>> >>>On 9/5/13 11:52 AM, "Ron Parker" >>>wrote: >>> >>>>Thanks for your patience, Jim! >>>> >>>>Does your description pre-suppose that there is always another IP >>>>header >>>>applied? For example, an original TCP segment could look like this >>>>(assuming UDP-based encap for this example): >>>> >>>> Outer-ip/udp/nsc/inner-ip/tcp/payload >>>> >>>>I can definitely get my head around that as it is a universal >>>>solution that presumes an IP network, only. >>>> >>>>I may be misinterpreting but I suspect that some on this thread >>>>aren't on the same page (at least yet) and may be thinking that in >>>>certain network >>>>topologies the outer IP can/should be avoided. If that is the case, >>>>I >>>>can't see how the nsc information can be inserted after the >>>>transport, which would create something that looks like this: >>>> >>>> Ip/tcp/nsc/payload >>>> >>>>Thanks. >>>> >>>> Ron >>>> >>>> >>>>-----Original Message----- >>>>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>Sent: Thursday, September 05, 2013 1:49 PM >>>>To: Ron Parker; Melinda Shore; nsc@ietf.org >>>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>>> >>>>Hi Ron, >>>> >>>>By encapsulation we mean something inserted between the transport >>>>encapsulation and the original packet payload. There are two things >>>>that need to happen; (1) identify that "service chaining" information >>>>follows the transport header, and (2) encapsulate the actual service >>>>chaining information. Now you could go down the path of trying to >>>>force fit the service chaining information into the transport but >>>>that imho is a mistake we should avoid. >>>> >>>>On 9/5/13 1:44 PM, "Ron Parker" >>>>wrote: >>>> >>>>>I apologize if I'm being thick on this, but I'm still having trouble >>>>>with >>>>>the meaning of "encapsulation" here. It has been pointed out that it >>>>>is >>>>>the thing that carries information like chain id, hop index, and >>>>>possibly metadata about the flow, but excludes the "overlay" >>>>>encapsulation. >>>>>So >>>>>if I think about something that resembles GRE, when we say >>>>>encapsulation, we are meaning the part of GRE that has the key but >>>>>not the part of GRE >>>>>that adds another IP header. Where I really get twisted around the >>>>>axle is if I think about this information being embedded in an IPv4 >>>>>option or IPv6 extension header. Not that we're necessarily choosing >>>>>those, but if we did, would we call that "encapsulation"? >>>>> >>>>>Thanks. >>>>> >>>>> Ron >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>>>Of Melinda Shore >>>>>Sent: Thursday, September 05, 2013 12:58 PM >>>>>To: nsc@ietf.org >>>>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>>>> >>>>>On 9/5/13 6:45 AM, Linda Dunbar wrote: >>>>>> This version hasn't addressed the comments on Bullet 3 of >>>>>>requiring a single encapsulation being too limiting or may not >>>>>>even be realistic. >>>>> >>>>>There's no agreement that that's the case. >>>>> >>>>>Melinda >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>nsc mailing list >>>>>nsc@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/nsc >>>>>_______________________________________________ >>>>>nsc mailing list >>>>>nsc@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/nsc >>>> >>>>_______________________________________________ >>>>nsc mailing list >>>>nsc@ietf.org >>>>https://www.ietf.org/mailman/listinfo/nsc >>> >> >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > From jguichar@cisco.com Thu Sep 5 13:27: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 0375E21F8416 for ; Thu, 5 Sep 2013 13:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 8z0fdNxqS6bU for ; Thu, 5 Sep 2013 13:27: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 7790F21F8C20 for ; Thu, 5 Sep 2013 13:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26171; q=dns/txt; s=iport; t=1378412317; x=1379621917; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=9GMrBqnbCCWlK7KaOkXKulAT6c4WZwri/iTbm2rvtwY=; b=hAsugaY4KuGNfqwP0A2fP1dHoR+7qn2u/OrXrIsO7QWj7nWSYx/B70sq pWKEM6cnVw/zE1ip0Yrho8c7trNAQ62DmJlewXe4A4kM3utLePc2N5Wgl GSpUM1UjInN6izIUXCxRxNFSkPu9t+QshRGMsSPHoGuM/MmQXp54RAZqt c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FABHmKFKtJXG8/2dsb2JhbABbgkNENVHBTIErFnSCJAEBAQQtOgsZAQgOAwECAQEBCxYHORQDBggCBAESCId6ukOOLYECIBcBgx2BAAOUG5VAgyCBaUE X-IronPort-AV: E=Sophos;i="4.90,849,1371081600"; d="scan'208,217";a="256132056" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 05 Sep 2013 20:18:35 +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 r85KIZn7027667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 20:18:35 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 15:18:35 -0500 From: "Jim Guichard (jguichar)" To: Jerome Moisand , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgABXk2CAADSpAA== Date: Thu, 5 Sep 2013 20:18:35 +0000 Message-ID: <68B171751455884590F8E38E96416F363F677CC9@xmb-rcd-x01.cisco.com> In-Reply-To: <23ef9ba0d2344ebd82cf4527e062414a@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.86.246.115] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F677CC9xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 20:27:48 -0000 --_000_68B171751455884590F8E38E96416F363F677CC9xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jerome, I have updated 3) as follows: 3) Service Chaining Data & Control Plane: A data plane document will descri= be on the wire data plane encapsulation in support of (2). A single service= -level encapsulation will be selected in order to enable interoperability o= f data plane components, which can in turn be carried in various transport = encapsulations (e.g., IP, MPLS, or other overlays). Supporting control plan= e protocol elements will be added as needed (as a separate document). Does this reflect your view accurately? From: Jerome Moisand > Date: Thursday, September 5, 2013 2:14 PM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: [nsc] NSC Working Group Charter Proposal As previously mentioned, the control plane is a bit missing. Let me suggest you just amend point 3) to say: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. =3D=3D> 3) Service Chaining Data & Control Plane: this document will describe on th= e wire data plane encapsulation in support of (2). A single encapsulation = will be selected in order to enable interoperability of data plane componen= ts. Supporting control plane protocol elements will be added as needs be (a= s a separate document). From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Thursday, September 05, 2013 7:57 AM To: nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Greetings, I have updated the charter as follows based on all comments received thus f= ar. There have been lots of inputs and this charter may not reflect all of = them (hopefully it is pretty close). Please take time to review and continu= e the discussion. Proposed NSC WG Charter =96 Take two Existing service insertion and deployment techniques fail to address new ch= allenging requirements raised by the introduction of emerging technologies = such as multi-tenancy, virtualization, elasticity, and rich classification.= Networks, servers, and other storage technologies, let alone applications,= have all undergone significant change in recent years: virtualization, net= work overlays, and orchestration have increasingly become techniques that c= ount and sometimes prevail. All of these have profound effects on network a= nd services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to massively static configuration procedures for network servic= e delivery or update purposes. The structuring and the delivery of new netw= ork services assume the (smart) combination of various service functions as= shared resources, and enable the linkage of these resources using service = chains that represent the abstracted view of the required service functions= , and define the order in which they should be invoked. Such (smart) combin= ations could be made of heterogeneous service functions which may act at va= rious layers of a protocol stack (network layer, application layer, etc). W= hen a service chain is instantiated in a network, specific instances of ser= vice functions are selected, and a service topology is created and used for= forwarding packets according to the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information that is shared across a subset of service functions may enabl= e a richer service chain for more advanced composite services. For example,= shared information, such as the results of a classification function, may = be passed to downstream service functions to enable the offloading of servi= ce function processing or to share information that would otherwise be hard= to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to network service structuring, insertion, and deployment, providing a fram= ework for the construction of services built using service function chains.= The WG focuses on the necessary protocols for the creation of service chai= ns, and the transmission of network and service-specific information from t= he network to service functions, and between service functions. When possib= le, the WG will extend existing protocols to provide service chaining funct= ionality, and any protocol extensions will be reviewed by both the Network = Service Chaining WG and by the WG responsible for the protocol being extend= ed. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including example h= igh-level use cases. Additionally, the WG will normalize on nomenclature a= nd definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining management in= support of (2) including relevant service chaining MIBs and information mo= dels, and service chaining OAM. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including context data) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of Informational document(s) defining Network = Service Chaining use cases to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability including MIBs, OAM, and information models to IESG --_000_68B171751455884590F8E38E96416F363F677CC9xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7DF01A415BD4274A92A65C0EF0A3CA42@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Jerome,

I have updated 3) as follows:

3) Service Chaining Data &am= p; Control Plane: A data plane document will describe on the wire data plan= e encapsulation in support of (2). A single service-level encapsulation wil= l be selected in order to enable interoperability of data plane components, which can in turn be carried in various transpor= t encapsulations (e.g., IP, MPLS, or other overlays). Supporting control pl= ane protocol elements will be added as needed (as a separate document).

Does this reflect your view = accurately?

From: Jerome Moisand <jmoisand@juniper.net>
Date: Thursday, September 5, 2013 2= :14 PM
To: Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: [nsc] NSC Working Grou= p Charter Proposal

As previously mentioned, the contr= ol plane is a bit missing.

 

Let me suggest you just amend poin= t 3) to say:

 

3) Service Chaining Data Plane: this docume= nt will describe on the wire data plane encapsulation in support of (2). &n= bsp;A single encapsulation will be selected in order to enable interoperability of data plane components.

 

=3D=3D>

 

3) Service Chaining Data & Control Plan= e: this document will describe on the wire data plane encapsulation in supp= ort of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components. = Supporting control plane protocol elements will be added as needs be (as a = separate document).

 

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, September 05, 2013 7:57 AM
To: nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

Greetings,

 

I have updated the charter as follows based= on all comments received thus far. There have been lots of inputs and this= charter may not reflect all of them (hopefully it is pretty close). Please take time to review and continue th= e discussion.

 

Proposed NSC WG Charter =96 Take two

 

Existing service insertion and deployment t= echniques fail to address new challenging requirements raised by the introd= uction of emerging technologies such as multi-tenancy, virtualization, elasticity, and rich classification. Net= works, servers, and other storage technologies, let alone applications, hav= e all undergone significant change in recent years: virtualization, network= overlays, and orchestration have increasingly become techniques that count and sometimes prevail. All of th= ese have profound effects on network and services design.=

 

Today, deploying new services, or making ch= anges to existing services, often requires network topology changes. Adding= and removing service functions is a complex, risky task, that is tied to operationalizing topological changes = leading to massively static configuration procedures for network service de= livery or update purposes. The structuring and the delivery of new network = services assume the (smart) combination of various service functions as shared resources, and enable the linkage o= f these resources using service chains that represent the abstracted view o= f the required service functions, and define the order in which they should= be invoked. Such (smart) combinations could be made of heterogeneous service functions which may act at various = layers of a protocol stack (network layer, application layer, etc). When a = service chain is instantiated in a network, specific instances of service f= unctions are selected, and a service topology is created and used for forwarding packets according to the servi= ce chain.

 

A basic service chain might simply utilize = an existing overlay technology to force traffic through the necessary servi= ce functions. However, additional information that is shared across a subset of service functions may enable a richer se= rvice chain for more advanced composite services. For example, shared infor= mation, such as the results of a classification function, may be passed to = downstream service functions to enable the offloading of service function processing or to share informati= on that would otherwise be hard to glean. 

 

The Network Service Chaining (NSC) working = group focuses on new approaches to network service structuring, insertion, = and deployment, providing a framework for the construction of services built using service function chains. The = WG focuses on the necessary protocols for the creation of service chains, a= nd the transmission of network and service-specific information from the ne= twork to service functions, and between service functions. When possible, the WG will extend existing prot= ocols to provide service chaining functionality, and any protocol extension= s will be reviewed by both the Network Service Chaining WG and by the WG re= sponsible for the protocol being extended.  

 

Specifically, the Network Service Chaining = WG is chartered to deliver the following work items: 

 

1) Problem Statement: this document will pr= ovide a summary of the problem space to be addressed by the Network Service= Chaining WG including example high-level use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.

 

2) System Architecture: this set of documen= ts will provide a description of the architecture building blocks and their= relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Plane: this docume= nt will describe on the wire data plane encapsulation in support of (2). &n= bsp;A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this document will addres= s service chaining management in support of (2) including relevant service = chaining MIBs and information models, and service chaining OAM.

 

Proposed Milestones:

 

Dec 2013 Request publication of an Informat= ional document defining the Network Service Chaining problem statement to t= he IESG

 

Mar 2014 Request publication of information= al documents defining the system architecture including protocol requiremen= ts and framework to the IESG

 

May 2014 Request publication of a Standards= Track document specifying the data-plane (including context data) for Serv= ice Chaining to IESG

 

May 2014 Request publication of an informat= ional document specifying Service Chaining Control Plane requirements to IE= SG

 

Dec 2014 Request publication of Information= al document(s) defining Network Service Chaining use cases to IESG

 

Dec 2014 Request publication of information= al documents defining Service Chaining manageability including MIBs, OAM, a= nd information models to IESG 

 

 

 

 =

--_000_68B171751455884590F8E38E96416F363F677CC9xmbrcdx01ciscoc_-- From jmoisand@juniper.net Thu Sep 5 13:38: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 94C2621F9E43 for ; Thu, 5 Sep 2013 13:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.378 X-Spam-Level: X-Spam-Status: No, score=-4.378 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 2JATlmxyINY7 for ; Thu, 5 Sep 2013 13:38:49 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id D2BD721F9E37 for ; Thu, 5 Sep 2013 13:38:48 -0700 (PDT) Received: from mail153-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE021.bigfish.com (10.243.66.84) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 20:38:48 +0000 Received: from mail153-co1 (localhost [127.0.0.1]) by mail153-co1-R.bigfish.com (Postfix) with ESMTP id 16EDE1C015C; Thu, 5 Sep 2013 20:38:48 +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: -19 X-BigFish: VPS-19(zz9371Ic85fhdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail153-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(377454003)(4396001)(83072001)(66066001)(561944002)(51856001)(59766001)(46102001)(77982001)(15975445006)(16236675002)(80022001)(33646001)(65816001)(81686001)(81342001)(79102001)(19609705001)(50986001)(47976001)(49866001)(47736001)(81542001)(76482001)(54356001)(74876001)(54316002)(56776001)(31966008)(63696002)(74316001)(15202345003)(74502001)(74662001)(47446002)(76576001)(69226001)(83322001)(74706001)(77096001)(19580405001)(56816003)(80976001)(81816001)(76786001)(76796001)(74366001)(19580395003)(19300405004)(18717965001)(53806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB250; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail153-co1 (localhost.localdomain [127.0.0.1]) by mail153-co1 (MessageSwitch) id 1378413524770354_4354; Thu, 5 Sep 2013 20:38:44 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.250]) by mail153-co1.bigfish.com (Postfix) with ESMTP id B885E900041; Thu, 5 Sep 2013 20:38:44 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 20:38:44 +0000 Received: from BN1PR05MB250.namprd05.prod.outlook.com (10.255.206.24) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 5 Sep 2013 20:38:43 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BN1PR05MB250.namprd05.prod.outlook.com (10.255.206.24) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 5 Sep 2013 20:38:41 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.242]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.242]) with mapi id 15.00.0745.000; Thu, 5 Sep 2013 20:38:41 +0000 From: Jerome Moisand To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgABXk2CAADSpAP//9K4w Date: Thu, 5 Sep 2013 20:38:40 +0000 Message-ID: References: <23ef9ba0d2344ebd82cf4527e062414a@BN1PR05MB251.namprd05.prod.outlook.com> <68B171751455884590F8E38E96416F363F677CC9@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F677CC9@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.232.2] x-forefront-prvs: 096029FF66 Content-Type: multipart/alternative; boundary="_000_e464732bf91a483aa9f86959a38368ffBN1PR05MB251namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 20:38:55 -0000 --_000_e464732bf91a483aa9f86959a38368ffBN1PR05MB251namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perfect. Thank you. From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Thursday, September 05, 2013 4:19 PM To: Jerome Moisand; nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Hi Jerome, I have updated 3) as follows: 3) Service Chaining Data & Control Plane: A data plane document will descri= be on the wire data plane encapsulation in support of (2). A single service= -level encapsulation will be selected in order to enable interoperability o= f data plane components, which can in turn be carried in various transport = encapsulations (e.g., IP, MPLS, or other overlays). Supporting control plan= e protocol elements will be added as needed (as a separate document). Does this reflect your view accurately? From: Jerome Moisand > Date: Thursday, September 5, 2013 2:14 PM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: [nsc] NSC Working Group Charter Proposal As previously mentioned, the control plane is a bit missing. Let me suggest you just amend point 3) to say: 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. =3D=3D> 3) Service Chaining Data & Control Plane: this document will describe on th= e wire data plane encapsulation in support of (2). A single encapsulation = will be selected in order to enable interoperability of data plane componen= ts. Supporting control plane protocol elements will be added as needs be (a= s a separate document). From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Thursday, September 05, 2013 7:57 AM To: nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Greetings, I have updated the charter as follows based on all comments received thus f= ar. There have been lots of inputs and this charter may not reflect all of = them (hopefully it is pretty close). Please take time to review and continu= e the discussion. Proposed NSC WG Charter - Take two Existing service insertion and deployment techniques fail to address new ch= allenging requirements raised by the introduction of emerging technologies = such as multi-tenancy, virtualization, elasticity, and rich classification.= Networks, servers, and other storage technologies, let alone applications,= have all undergone significant change in recent years: virtualization, net= work overlays, and orchestration have increasingly become techniques that c= ount and sometimes prevail. All of these have profound effects on network a= nd services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to massively static configuration procedures for network servic= e delivery or update purposes. The structuring and the delivery of new netw= ork services assume the (smart) combination of various service functions as= shared resources, and enable the linkage of these resources using service = chains that represent the abstracted view of the required service functions= , and define the order in which they should be invoked. Such (smart) combin= ations could be made of heterogeneous service functions which may act at va= rious layers of a protocol stack (network layer, application layer, etc). W= hen a service chain is instantiated in a network, specific instances of ser= vice functions are selected, and a service topology is created and used for= forwarding packets according to the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information that is shared across a subset of service functions may enabl= e a richer service chain for more advanced composite services. For example,= shared information, such as the results of a classification function, may = be passed to downstream service functions to enable the offloading of servi= ce function processing or to share information that would otherwise be hard= to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to network service structuring, insertion, and deployment, providing a fram= ework for the construction of services built using service function chains.= The WG focuses on the necessary protocols for the creation of service chai= ns, and the transmission of network and service-specific information from t= he network to service functions, and between service functions. When possib= le, the WG will extend existing protocols to provide service chaining funct= ionality, and any protocol extensions will be reviewed by both the Network = Service Chaining WG and by the WG responsible for the protocol being extend= ed. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including example h= igh-level use cases. Additionally, the WG will normalize on nomenclature a= nd definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining management in= support of (2) including relevant service chaining MIBs and information mo= dels, and service chaining OAM. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including context data) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of Informational document(s) defining Network = Service Chaining use cases to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability including MIBs, OAM, and information models to IESG --_000_e464732bf91a483aa9f86959a38368ffBN1PR05MB251namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Perfect. Thank you.<= /o:p>

 <= /p>

 <= /p>

From: Jim Guic= hard (jguichar) [mailto:jguichar@cisco.com]
Sent: Thursday, September 05, 2013 4:19 PM
To: Jerome Moisand; nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

Hi Jerome,

 

I have updated 3) as follow= s:

 

3) Service Chaining Data & Control Plane: A data plane d= ocument will describe on the wire data plane encapsulation in support of (2). A single service-level encapsulation will be selected in o= rder to enable interoperability of data plane components, which can in turn= be carried in various transport encapsulations (e.g., IP, MPLS, or other o= verlays). Supporting control plane protocol elements will be added as needed (as a separate document).=

 

Does this reflect your view accurately?

 

From: Jerome Moisand <jmoisand@juniper.net>
Date: Thursday, September 5, 2013 2:14 PM
To: Microsoft Office User <= jguichar@cisco.com>, "nsc@ietf.= org" <nsc@ietf.org>
Subject: RE: [nsc] NSC Working Group Charter Proposal

 

As previously mentioned, = the control plane is a bit missing.

 

Let me suggest you just a= mend point 3) to say:<= /p>

 

3) Service Chaining Data Pl= ane: this document will describe on the wire data plane encapsulation in su= pport of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

=3D=3D>

 

3) Service Chaining Data &a= mp; Control Plane: this document will describe on the wire data plane encap= sulation in support of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components. Sup= porting control plane protocol elements will be added as needs be (as a sep= arate document).

 

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, September 05, 2013 7:57 AM
To: nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 =

Greetings,

 

I have updated the charter = as follows based on all comments received thus far. There have been lots of= inputs and this charter may not reflect all of them (hopefully it is pretty close). Please take time to review and continue the discussio= n.

 

Proposed NSC WG Charter = – Take two

 

Existing service insertion = and deployment techniques fail to address new challenging requirements rais= ed by the introduction of emerging technologies such as multi-tenancy, virtualization, elasticity, and rich classification. Networ= ks, servers, and other storage technologies, let alone applications, have a= ll undergone significant change in recent years: virtualization, network ov= erlays, and orchestration have increasingly become techniques that count and sometimes prevail. All of these have prof= ound effects on network and services design.

 

Today, deploying new servic= es, or making changes to existing services, often requires network topology= changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o massively static configuration procedures for network service delivery or= update purposes. The structuring and the delivery of new network services = assume the (smart) combination of various service functions as shared resources, and enable the linkage of t= hese resources using service chains that represent the abstracted view of t= he required service functions, and define the order in which they should be= invoked. Such (smart) combinations could be made of heterogeneous service functions which may act at various = layers of a protocol stack (network layer, application layer, etc). When a = service chain is instantiated in a network, specific instances of service f= unctions are selected, and a service topology is created and used for forwarding packets according to the servi= ce chain.

 

A basic service chain might= simply utilize an existing overlay technology to force traffic through the= necessary service functions. However, additional information that is shared across a subset of service functions may enable a richer se= rvice chain for more advanced composite services. For example, shared infor= mation, such as the results of a classification function, may be passed to = downstream service functions to enable the offloading of service function processing or to share informati= on that would otherwise be hard to glean. 

 

The Network Service Chainin= g (NSC) working group focuses on new approaches to network service structur= ing, insertion, and deployment, providing a framework for the construction of services built using service function chains. The WG f= ocuses on the necessary protocols for the creation of service chains, and t= he transmission of network and service-specific information from the networ= k to service functions, and between service functions. When possible, the WG will extend existing protocols to= provide service chaining functionality, and any protocol extensions will b= e reviewed by both the Network Service Chaining WG and by the WG responsibl= e for the protocol being extended.  

 

Specifically, the Network S= ervice Chaining WG is chartered to deliver the following work items: <= /span>

 

1) Problem Statement: this = document will provide a summary of the problem space to be addressed by the= Network Service Chaining WG including example high-level use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.=

 

2) System Architecture: thi= s set of documents will provide a description of the architecture building = blocks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pl= ane: this document will describe on the wire data plane encapsulation in su= pport of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docu= ment will address service chaining management in support of (2) including r= elevant service chaining MIBs and information models, and service chaining OAM.=

 

Proposed Milestones:=

 

Dec 2013 Request publicatio= n of an Informational document defining the Network Service Chaining proble= m statement to the IESG

 

Mar 2014 Request publicatio= n of informational documents defining the system architecture including pro= tocol requirements and framework to the IESG

 

May 2014 Request publicatio= n of a Standards Track document specifying the data-plane (including contex= t data) for Service Chaining to IESG

 

May 2014 Request publicatio= n of an informational document specifying Service Chaining Control Plane re= quirements to IESG

 

Dec 2014 Request publicatio= n of Informational document(s) defining Network Service Chaining use cases = to IESG

 

Dec 2014 Request publicatio= n of informational documents defining Service Chaining manageability includ= ing MIBs, OAM, and information models to IESG 

 

 

 

 

--_000_e464732bf91a483aa9f86959a38368ffBN1PR05MB251namprd05pro_-- From kgray@juniper.net Thu Sep 5 13:39: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 7B53A21F9E37 for ; Thu, 5 Sep 2013 13:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 BnjW8BKKVe4q for ; Thu, 5 Sep 2013 13:39:35 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id DEE2A21F9F96 for ; Thu, 5 Sep 2013 13:39:34 -0700 (PDT) Received: from mail65-co1-R.bigfish.com (10.243.78.252) by CO1EHSOBE039.bigfish.com (10.243.66.104) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 20:39:29 +0000 Received: from mail65-co1 (localhost [127.0.0.1]) by mail65-co1-R.bigfish.com (Postfix) with ESMTP id 5D34C92029A; Thu, 5 Sep 2013 20:39:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail65-co1: 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:(51704005)(479174003)(377454003)(189002)(199002)(24454002)(77982001)(59766001)(76786001)(83072001)(76796001)(76176001)(63696002)(56776001)(36756003)(54316002)(79102001)(47736001)(80976001)(56816003)(50986001)(47976001)(77096001)(69226001)(47446002)(31966008)(81816001)(49866001)(74502001)(74662001)(46102001)(81542001)(74366001)(19580395003)(80022001)(83322001)(19580405001)(65816001)(54356001)(74706001)(83506001)(76482001)(74876001)(81686001)(4396001)(53806001)(51856001)(81342001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB082; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail65-co1 (localhost.localdomain [127.0.0.1]) by mail65-co1 (MessageSwitch) id 1378413568335389_25646; Thu, 5 Sep 2013 20:39:28 +0000 (UTC) Received: from CO1EHSMHS011.bigfish.com (unknown [10.243.78.254]) by mail65-co1.bigfish.com (Postfix) with ESMTP id 44598780048; Thu, 5 Sep 2013 20:39:28 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS011.bigfish.com (10.243.66.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 20:39:28 +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.353.4; Thu, 5 Sep 2013 20:39:27 +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.745.25; Thu, 5 Sep 2013 20:39:26 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) with mapi id 15.00.0745.000; Thu, 5 Sep 2013 20:39:24 +0000 From: Ken Gray To: Melinda Shore , "Surendra Kumar (smkumar)" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAACkCAIAADRKAgAABLQCAABHdAIAAAysAgAAH1oD//8/SAA== Date: Thu, 5 Sep 2013 20:39:24 +0000 Message-ID: In-Reply-To: <5228DC25.6010306@gmail.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: 096029FF66 Content-Type: text/plain; charset="iso-8859-2" Content-ID: <601923B11231C64E92E341E16B25B1CE@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] NSC Working Group Charter Proposal 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, 05 Sep 2013 20:39:42 -0000 It gets clearer when we get beyond the charter and into the piecework. For example, Paul's NSH doc makes this part pretty clear. On 9/5/13 3:31 PM, "Melinda Shore" wrote: >On 9/5/13 11:03 AM, Surendra Kumar (smkumar) wrote: >> Just to add, for clarity(hopefully). >>=20 >> This is the intent: [Transport-Encapsulation/Header | >> Service-Encapsulaiton/Header | Original-payload] >> Where, >> Original-payload : an IP packet without the layer-2 header or it >> could be a frame with the L2-header. This depends on the interception >> layer. >> Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, =A9 >> Service Encap : is where the service-path-identifier/... Is >> carried in order to be able to identify the chain or the forwarding >>path. > >I think this is quite helpful, actually. I think some of the >discussion of layering, or at least some of the discussion of >layering, has been a little too fuzzy. The IP stack does not >break down that cleanly into OSI layers and so when someone says >"Layer 4" it's not always clear what they mean. Bringing >specificity to the discussion is extremely useful. > >Melinda > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > From darlewis@cisco.com Thu Sep 5 13:59: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 7746C21E80CC for ; Thu, 5 Sep 2013 13:59: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 0aztl2YMik13 for ; Thu, 5 Sep 2013 13:59:32 -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 67C7211E80F5 for ; Thu, 5 Sep 2013 13:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1866; q=dns/txt; s=iport; t=1378414772; x=1379624372; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uMU1+QoGZNHKbCVIQROMQgtsJ172JeDLEnEtW+Zu5dc=; b=ZZLoJLMlzJNYmU7D/aA7EMxxV5Hwx1mkMauWzhXOiuACyk5u+ROvgroG byZakZF5NyiRSCZhjEkFrNrnRtdsJa98wmG59SbQZmS9bq8hr9LCdQNsZ 6mkQglv3VrVSrtNR6LnE7da39NfR+p8oL82wNQ+mIc7HgbyFm6Ycao+f1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAPjvKFKtJV2b/2dsb2JhbABRCoMHNVHBTIErFnSCJAEBAQMBAQEBZAcLBQsCAQgOCgokIQYLJQIEDgUIh2gDCQYMsS8NiGwEjHSBKYEQAjEHgx2BAAOUG4FxjiCFL4Mggio X-IronPort-AV: E=Sophos;i="4.90,849,1371081600"; d="scan'208";a="253160432" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 05 Sep 2013 20:59:31 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r85KxVK7032012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 20:59:31 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.207]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 15:59:31 -0500 From: "Darrel Lewis (darlewis)" To: Ken Gray Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqnrQrXOZ2m/vBEG19boxgCQmQw== Date: Thu, 5 Sep 2013 20:59:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.213.92] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <47BDAA421519484C8ACA092B290091F0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Darrel Lewis \(darlewis\)" , Melinda Shore , "Surendra Kumar \(smkumar\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 20:59:38 -0000 Ken, I agree with that and (in IMHO) this simple, conceptual statement was missi= ng from the use case discussions in Berlin - so I can see where there is so= me confusion among people who have not read the piecework yet. -Darrel On Sep 5, 2013, at 1:39 PM, Ken Gray wrote: > It gets clearer when we get beyond the charter and into the piecework. > For example, Paul's NSH doc makes this part pretty clear. >=20 > On 9/5/13 3:31 PM, "Melinda Shore" wrote: >=20 >> On 9/5/13 11:03 AM, Surendra Kumar (smkumar) wrote: >>> Just to add, for clarity(hopefully). >>>=20 >>> This is the intent: [Transport-Encapsulation/Header | >>> Service-Encapsulaiton/Header | Original-payload] >>> Where, >>> Original-payload : an IP packet without the layer-2 header or it >>> could be a frame with the L2-header. This depends on the interception >>> layer. >>> Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, =A9 >>> Service Encap : is where the service-path-identifier/... Is >>> carried in order to be able to identify the chain or the forwarding >>> path. >>=20 >> I think this is quite helpful, actually. I think some of the >> discussion of layering, or at least some of the discussion of >> layering, has been a little too fuzzy. The IP stack does not >> break down that cleanly into OSI layers and so when someone says >> "Layer 4" it's not always clear what they mean. Bringing >> specificity to the discussion is extremely useful. >>=20 >> Melinda >>=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 From linda.dunbar@huawei.com Thu Sep 5 14:19: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 C08E621F9C70 for ; Thu, 5 Sep 2013 14:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 2foWpDNhY1Tz for ; Thu, 5 Sep 2013 14:19:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AA9DE11E8135 for ; Thu, 5 Sep 2013 14:19:13 -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.5-GA FastPath queued) with ESMTP id AWY25989; Thu, 05 Sep 2013 21:19:10 +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; Thu, 5 Sep 2013 22:18:47 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 22:19:06 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Thu, 5 Sep 2013 14:19:03 -0700 From: Linda Dunbar To: Ron Parker , "Jim Guichard (jguichar)" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAJ5aAP//lE3ggAB58wD//5m/sIAAGcwQ Date: Thu, 5 Sep 2013 21:19:03 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9E0BB@dfweml509-mbx.china.huawei.com> References: <68B171751455884590F8E38E96416F363F6777F2@xmb-rcd-x01.cisco.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.192.11.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 21:19:20 -0000 I can see the need for this "NSC" header inserted to the packets, and occas= ionally needing an "outer-ip" encapsulation to by-pass nodes that can't par= se the "NSC" header.=20 Can someone explain why it is necessary to always have the "outer-ip" heade= r?=20 > -----Original Message----- >=20 > Outer-ip/udp/nsc/inner-ip/tcp/payload Linda From Ron_Parker@affirmednetworks.com Thu Sep 5 16:16: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 C134011E81DF for ; Thu, 5 Sep 2013 16:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 DjSVnqxyM7Vn for ; Thu, 5 Sep 2013 16:16:19 -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 9EE9E11E810B for ; Thu, 5 Sep 2013 16:16:19 -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.0123.003; Thu, 5 Sep 2013 16:16:18 -0700 From: Ron Parker To: Linda Dunbar , "Jim Guichard (jguichar)" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAJ5aAP//lE3ggAB58wD//5m/sIAAGcwQgAAwdeA= Date: Thu, 5 Sep 2013 23:16:18 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F6777F2@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9E0BB@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9E0BB@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.76.112.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 05 Sep 2013 23:16:26 -0000 Hi, Linda. As it was recently explained on this thread, I don't think it needs to be n= ecessary to always have it if we are willing to allow multiple overall "tra= nsport"+service encapsulations. For example: =20 /enet/ip/udp/nsc/ip/tcp/... /enet/ip/gre/nsc/ip/tcp/... /enet/llc-snap/nsc/ip/tcp/... /enet/mpls/nsc/ip/tcp/... As much as I don't think we'll end up there, I do find a single overall uni= versal transformation very attractive and any flavor that is /{l2}/ip/xxx/i= p/tcp would be universally applicable -- same subnet or different subnet, l= 2 switches and/or l3 routers in between , OpenFlow or not OpenFlow, MPLS or= not MPLS, ... The argument against this will be that the packets are b= igger than they need to be for some network topologies/protocols. Simplic= ity or efficiency? Ron -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20 Sent: Thursday, September 05, 2013 5:19 PM To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org Subject: RE: [nsc] NSC Working Group Charter Proposal I can see the need for this "NSC" header inserted to the packets, and occas= ionally needing an "outer-ip" encapsulation to by-pass nodes that can't par= se the "NSC" header.=20 Can someone explain why it is necessary to always have the "outer-ip" heade= r?=20 > -----Original Message----- >=20 > Outer-ip/udp/nsc/inner-ip/tcp/payload Linda From linda.dunbar@huawei.com Fri Sep 6 07:17: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 285D011E82B3 for ; Fri, 6 Sep 2013 07:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.261 X-Spam-Level: X-Spam-Status: No, score=-6.261 tagged_above=-999 required=5 tests=[AWL=0.338, 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 4WjJX8gZVtN3 for ; Fri, 6 Sep 2013 07:17:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC6611E8159 for ; Fri, 6 Sep 2013 07:17:36 -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.5-GA FastPath queued) with ESMTP id AVC79684; Fri, 06 Sep 2013 14:17:35 +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; Fri, 6 Sep 2013 15:17:08 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 15:17:28 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Fri, 6 Sep 2013 07:17:24 -0700 From: Linda Dunbar To: Ron Parker , "Jim Guichard (jguichar)" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAJ5aAP//lE3ggAB58wD//5m/sIAAGcwQgAAwdeCAAP1hUA== Date: Fri, 6 Sep 2013 14:17:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9E85C@dfweml509-mbx.china.huawei.com> References: <68B171751455884590F8E38E96416F363F6777F2@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9E0BB@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.192.11.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 14:17:47 -0000 Ron,=20 Great! I am glad to see that we go down this path.=20 We should also allow: /enet/ip/udp or tcp/nsc/... i.e. not necessarily having an inner IP.=20 Linda > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Thursday, September 05, 2013 6:16 PM > To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org > Subject: RE: [nsc] NSC Working Group Charter Proposal >=20 > Hi, Linda. >=20 > As it was recently explained on this thread, I don't think it needs to > be necessary to always have it if we are willing to allow multiple > overall "transport"+service encapsulations. For example: >=20 > /enet/ip/udp/nsc/ip/tcp/... > /enet/ip/gre/nsc/ip/tcp/... > /enet/llc-snap/nsc/ip/tcp/... > /enet/mpls/nsc/ip/tcp/... >=20 > As much as I don't think we'll end up there, I do find a single overall > universal transformation very attractive and any flavor that is > /{l2}/ip/xxx/ip/tcp would be universally applicable -- same subnet or > different subnet, l2 switches and/or l3 routers in between , OpenFlow > or not OpenFlow, MPLS or not MPLS, ... The argument against this > will be that the packets are bigger than they need to be for some > network topologies/protocols. Simplicity or efficiency? >=20 > Ron >=20 >=20 >=20 > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Thursday, September 05, 2013 5:19 PM > To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org > Subject: RE: [nsc] NSC Working Group Charter Proposal >=20 > I can see the need for this "NSC" header inserted to the packets, and > occasionally needing an "outer-ip" encapsulation to by-pass nodes that > can't parse the "NSC" header. >=20 > Can someone explain why it is necessary to always have the "outer-ip" > header? >=20 >=20 > > -----Original Message----- > > > > Outer-ip/udp/nsc/inner-ip/tcp/payload >=20 >=20 >=20 > Linda From Ron_Parker@affirmednetworks.com Fri Sep 6 07:38: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 51BCB21F85C3 for ; Fri, 6 Sep 2013 07:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 jpTFltWR9i1V for ; Fri, 6 Sep 2013 07:38:17 -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 161A811E817F for ; Fri, 6 Sep 2013 07:38: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, 6 Sep 2013 07:38:14 -0700 From: Ron Parker To: Linda Dunbar , "Jim Guichard (jguichar)" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAJ5aAP//lE3ggAB58wD//5m/sIAAGcwQgAAwdeCAAP1hUIAAASYw Date: Fri, 6 Sep 2013 14:38:14 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F6777F2@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9E0BB@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645B9E85C@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9E85C@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 14:38:25 -0000 Hi, Linda,=20 When I referenced an inner IP, I more properly should have referenced "orig= inal packet", which I think you are pointing out, correctly, is not necessa= rily IP. Even in this case, I think it is important to state whether a n= ew "transport" is always required in front of the "original packet" or not.= =20 So if we exemplify this with a layer 2 "transport" and a layer 2 original p= acket, we might have something like: /encaps-enet/llc-snap/nsc-header/original-enet/payload If we take another example of a layer 2/3/4 "transport" and a layer 2 origi= nal packet, we might have something like: /encaps-enet/ip/udp/nsc-header/original-enet/payload The reason I am being pedantic here is that these approaches contrast to ot= her possible solutions where an outer "transport" is not added. For examp= le, if we were entertaining mapping the nsc-header to a new IPv4 option and= new IPv6 extension header for use only when the "original packet" is an IP= v4 or IPv6 packet, then an encapsulating "transport" would not necessarily = be required. Again, we come to simplicity/universality vs. efficiency (at= least in terms of packet size if not necessarily processing requirements). This is obviously an important area to cover in the WG. Some of this anal= ysis is presented in draft-boucadair-chaining-design-analysis and we intend= to add more of this pros/cons analysis wrt the overall encapsulation issue= in an upcoming revision. I would like to take the opportunity to back previous suggestions that a de= sign choices analysis document become a part of the WG chartered deliverabl= es as it encourages a more open and transparent process and ultimately prov= ides a better record of how the eventual recommendations are arrived at. Ron =09 -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20 Sent: Friday, September 06, 2013 10:17 AM To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org Subject: RE: [nsc] NSC Working Group Charter Proposal Ron,=20 Great! I am glad to see that we go down this path.=20 We should also allow: /enet/ip/udp or tcp/nsc/... i.e. not necessarily having an inner IP.=20 Linda > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Thursday, September 05, 2013 6:16 PM > To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org > Subject: RE: [nsc] NSC Working Group Charter Proposal >=20 > Hi, Linda. >=20 > As it was recently explained on this thread, I don't think it needs to=20 > be necessary to always have it if we are willing to allow multiple > overall "transport"+service encapsulations. For example: >=20 > /enet/ip/udp/nsc/ip/tcp/... > /enet/ip/gre/nsc/ip/tcp/... > /enet/llc-snap/nsc/ip/tcp/... > /enet/mpls/nsc/ip/tcp/... >=20 > As much as I don't think we'll end up there, I do find a single=20 > overall universal transformation very attractive and any flavor that=20 > is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same subnet=20 > or different subnet, l2 switches and/or l3 routers in between , OpenFlow > or not OpenFlow, MPLS or not MPLS, ... The argument against this > will be that the packets are bigger than they need to be for some > network topologies/protocols. Simplicity or efficiency? >=20 > Ron >=20 >=20 >=20 > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Thursday, September 05, 2013 5:19 PM > To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org > Subject: RE: [nsc] NSC Working Group Charter Proposal >=20 > I can see the need for this "NSC" header inserted to the packets, and=20 > occasionally needing an "outer-ip" encapsulation to by-pass nodes that=20 > can't parse the "NSC" header. >=20 > Can someone explain why it is necessary to always have the "outer-ip" > header? >=20 >=20 > > -----Original Message----- > > > > Outer-ip/udp/nsc/inner-ip/tcp/payload >=20 >=20 >=20 > Linda From cpignata@cisco.com Fri Sep 6 08:23: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 6FAAB21F9DC9 for ; Fri, 6 Sep 2013 08:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 dpXcxuka7ERI for ; Fri, 6 Sep 2013 08:23:30 -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 9D06421E81CD for ; Fri, 6 Sep 2013 08:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36091; q=dns/txt; s=iport; t=1378481009; x=1379690609; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6ZXXyLQjUPMHVKOXrQ8Q/y1n42ad0pAR+qba4qk3+T8=; b=JM0Yn/K7vHK5o5DyeXNAcl2T2gC9htd4269HCXdAhD204DSLFI3d8lUy Mjbnpdf3INVbeZ0wdYf6MQ3LP06WdDMGmZSOgMXfouNGG9YoA5JLQIcha GWCiZ/nhnChysh/CKCJ9qWo1e4h/mwxWQHGPnKM8wfHH3a3LXr8jdALq9 Q=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAK/yKVKtJV2Y/2dsb2JhbABbgkNENVHBVYEkFnSCJAEBAQMBAQEBKkEEBwULAgEIDgMBAgEBAQsWAQYHJwsUAwYIAgQBDQUIBg2HYQYMvhIEjkmBAiANBAYBgx2BAAOQI4EugkqVQIMggWlB X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="asc'?scan'208,217";a="256491093" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 06 Sep 2013 15:23:28 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r86FNSeK001116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 15:23:28 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 10:23:28 -0500 From: "Carlos Pignataro (cpignata)" To: Ken Gray , Lucy yong Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m2DOtggAAOrPCAABiugP//8GhQ///FkQCAA0IlgA== Date: Fri, 6 Sep 2013 15:23:27 +0000 Message-ID: <95067C434CE250468B77282634C96ED325EFDB06@xmb-aln-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: multipart/signed; boundary="Apple-Mail=_2899AE22-FF39-4A7D-B452-8490BE56C191"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Linda Dunbar Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 15:23:35 -0000 --Apple-Mail=_2899AE22-FF39-4A7D-B452-8490BE56C191 Content-Type: multipart/alternative; boundary="Apple-Mail=_44B14967-B674-4E2F-96A1-B124924C746F" --Apple-Mail=_44B14967-B674-4E2F-96A1-B124924C746F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Lucy, To add to this, and commenting only for completeness for the record, you = say "The bof in IETF87 does not convey the issues clearly." However, the sponsoring AD's summary said the contrary: I believe that the BoF delivered what the IESG had hoped to see. That = is, it allowed a number of network operators from a broad spectrum of network = types to describe the problem space that they are interested in. Certainly a small number of use cases to complete and exemplify the = problem statement are appropriate and useful. That said, there is no = strict sequentiality implied in having to finish a laundry list of use = cases to start working on a solution. Thanks, -- Carlos. On Sep 4, 2013, at 6:38 PM, Ken Gray wrote: > Please, count me out of "not many people". =20 >=20 > For the members of "not many people", help save us a year of = introspection and please see the huge amount of use case and best = practice gorge in ETSI documentation or mailing lists, regurgitation in = IEEE special work groups and ONF special work groups, numerous articles = restating the position papers therein. All easily accessible by using = Google, Bing or other engines to search for "NFV". This may appear = sarcastic, but =85 really, it's not intended to be overly so (I think = "tired of hearing this" is more appropriate) =85you will be amazed at = what has already been writ, spoken and debated in the name of Service = Chaining and Service Virtualization. >=20 > From: Lucy yong > Date: Wed, 4 Sep 2013 22:12:03 +0000 > To: "Jim Guichard (jguichar)" , Linda Dunbar = , "nsc@ietf.org" > Subject: Re: [nsc] NSC Working Group Charter Proposal >=20 > Not many people well understand the problem and use case yet. The bof = in IETF87 does not convey the issues clearly. So the first charter = should solve that first before to work on the solution. The work items = listed in the charter do not indicate has the order. The time table = clear indicates they will be worked at the same time. I agree that we = should standardize one data plane solution, but don=92t think the = schedule is proper. > =20 > Lucy > =20 > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 > Sent: Wednesday, September 04, 2013 5:03 PM > To: Lucy yong; Linda Dunbar; nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal > =20 > I disagree, this working group must be focused on solutions and not = pontification over terminology or a laundry list of use cases. Having = said that you will note in the milestones that the problem statement and = requirements are the first work items to be delivered followed by the = data plane that will support both. It is perfectly acceptable to provide = a planned outline of the WG activities and this is reflected in the = charter.=20 > =20 > From: Lucy yong > Date: Wednesday, September 4, 2013 5:38 PM > To: Linda Dunbar , Microsoft Office User = , "nsc@ietf.org" > Subject: Re: [nsc] NSC Working Group Charter Proposal > =20 > The first charter should focus on the problem statement, architecture, = use case, and requirement; Not on specifying one solution. Therefore, = work item #3 should not be in the first charter. > =20 > Lucy > =20 > From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of = Linda Dunbar > Sent: Wednesday, September 04, 2013 3:45 PM > To: Jim Guichard (jguichar); nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal > =20 > One clarification on Work Item #3: > 3) Service Chaining Data Plane: this document will describe on the = wire data plane encapsulation in support of (2). A single encapsulation = will be selected in order to enable interoperability of data plane = components. > =20 > Is it really =93A single encapsulation=94? > The encapsulation should depend on the underlay networks. Underlay = network could be IP based, MPLS based, or Ethernet based. =20 > =20 > Linda > =20 > From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of = Jim Guichard (jguichar) > Sent: Tuesday, September 03, 2013 11:01 AM > To: nsc@ietf.org > Subject: [nsc] NSC Working Group Charter Proposal > =20 > Greetings, > =20 > As we look forward to the formation of a working group that will focus = on network service chaining, I would like to propose a discussion on = this alias to try and reach consensus on an initial charter as requested = by the routing area AD's. The following is a first draft of the charter = and I invite you to actively participate and provide inputs into this = process. > =20 > Proposed NSC WG Charter > =20 > Existing service insertion and deployment techniques have not evolved = to meet modern network architectures and do not reflect multi-tenancy, = virtualization, elasticity, rich classification, and other network = requirements. Networks, servers, storage, and applications, have all = undergone significant change in recent years: virtualization, network = overlays, and orchestration are increasingly the norm. All of these have = profound effects on network and services design. > =20 > Today, deploying new services, or making changes to existing services, = often requires network topology changes. Adding and removing service = functions is a complex, risky task, that is tied to operationalizing = topological changes leading to mostly-static service definitions. New = service insertion and deployment techniques must enable the concept of = service functions as shared resources, and enable the linkage of these = resources using service chains that represent the abstracted view of the = required service functions, and define the order in which they should be = applied. When a service chain is instantiated in a network, specific = instances of service functions are selected, and a service topology is = created and used for forwarding packets through the service chain. > =20 > A basic service chain might simply utilize an existing overlay = technology to force traffic through the necessary service functions. = However, additional information enables a richer service chain for more = advanced composite services. For example, shared information (e.g., the = result of classification) can be used to offload service function = processing or inform other service functions about information that = would otherwise be hard to glean.=20 > =20 > The Network Service Chaining (NSC) working group focuses on new = approaches to service insertion and deployment, providing a framework = for the construction of services built using service chains. The WG = focuses on the necessary protocols for the creation of service chains, = and the passing of metadata from the network to service functions, and = between service functions. When possible, the WG will extend existing = protocols to provide service chaining functionality, and any protocol = extensions will be reviewed by both the Network Service Chaining WG and = by the WG responsible for the protocol being extended. =20 > =20 > Specifically, the Network Service Chaining WG is chartered to deliver = the following work items:=20 > =20 > 1) Problem Statement: this document will provide a summary of the = problem space to be addressed by the Network Service Chaining WG = including terminology and sample use cases. Additionally, the WG will = normalize on nomenclature and definitions for Network Service Chaining. > =20 > 2) System Architecture: this set of documents will provide a = description of the architecture building blocks and their relationships = including interconnection, placement of capabilities, and security = models, as well as requirements on the control mechanisms and data plane = encapsulation. > =20 > 3) Service Chaining Data Plane: this document will describe on the = wire data plane encapsulation in support of (2). A single encapsulation = will be selected in order to enable interoperability of data plane = components. > =20 > 4) Manageability: this document will address service chaining = operation, monitoring and troubleshooting including relevant service = chaining models such as MIBs or YANG modules, along with relevant OAM = capabilities and how they are realized. > =20 > Proposed Milestones: > =20 > Dec 2013 Request publication of an Informational document defining the = Network Service Chaining problem statement to the IESG > =20 > Mar 2014 Request publication of informational documents defining the = system architecture including protocol requirements and framework to the = IESG > =20 > May 2014 Request publication of a Standards Track document specifying = the data-plane (including metadata) for Service Chaining to IESG > =20 > May 2014 Request publication of an informational document specifying = Service Chaining Control Plane requirements to IESG > =20 > Dec 2014 Request publication of informational documents defining = Service Chaining manageability requirements including MIBs, OAM, and = information models to IESG=20 > =20 > =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 --Apple-Mail=_44B14967-B674-4E2F-96A1-B124924C746F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The bof in = IETF87 does not convey the issues = clearly."

However, the sponsoring AD's = summary said the contrary:
I believe that the BoF delivered =
what the IESG had hoped to see. That is, it
allowed =
a number of network operators from a broad spectrum of network types =
to
describe the problem space that they are =
interested in.
Certainly a small = number of use cases to complete and exemplify the problem statement are = appropriate and useful. That said, there is no strict sequentiality = implied in having to finish a laundry list of use cases to start working = on a = solution.

Thanks,

= -- Carlos.


On Sep 4, = 2013, at 6:38 PM, Ken Gray <kgray@juniper.net> = wrote:

Please, count me out of "not many people".   

For the members of "not many people", help save us a year of = introspection and please see the huge amount of use case  and best = practice gorge in ETSI documentation or mailing lists, regurgitation in = IEEE special work groups and ONF special work groups, numerous articles restating the position papers therein.  All = easily accessible by using Google, Bing or other engines to search for = "NFV".  This may appear sarcastic, but =85 really, it's not = intended to be overly so (I think "tired of hearing this" is more appropriate) =85you will be amazed at what has already been writ, = spoken and debated in the name of Service Chaining and Service = Virtualization.

From: Lucy yong <lucy.yong@huawei.com>
Date: Wed, 4 Sep 2013 22:12:03 = +0000
To: "Jim Guichard (jguichar)" = <jguichar@cisco.com>, = Linda Dunbar <linda.dunbar@huawei.com>, = "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] NSC Working = Group Charter Proposal

Not many people well understand the problem and use case = yet. The bof in IETF87 does not convey the issues clearly. So the first = charter should solve that first before to work on the solution. The work items listed in the = charter do not indicate has the order. The time table clear indicates = they will be worked at the same time.  I agree that we should = standardize one data plane solution, but don=92t think the schedule is proper.
Lucy
 
From: Jim = Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Wednesday, September 04, 2013 5:03 PM
To: Lucy yong; Linda Dunbar; nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter = Proposal
 
I disagree, this working group must be focused on solutions and not pontification over terminology or a = laundry list of use cases. Having said that you will = note in the milestones that the problem statement and requirements are the first work items to be delivered = followed by the data plane that will support both. It is = perfectly acceptable to provide a planned outline of the WG activities = and this is reflected in the charter. 
 
From: Lucy yong <lucy.yong@huawei.com>
Date: Wednesday, September 4, 2013 5:38 PM
To: Linda Dunbar <linda.dunbar@huawei.com>, = Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] NSC Working Group Charter = Proposal
 
The first charter = should focus on the problem statement, architecture, use case, and = requirement;  Not on specifying one solution. Therefore, work item #3 should not be in the first charter.
 
Lucy
 
From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]= On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 3:45 PM
To: Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal
 
One clarification on Work Item #3:

3) Service Chaining Data Plane: this = document will describe on the wire data plane encapsulation in support = of (2). A single encapsulation will be selected in order to enable interoperability of data plane = components.

 
Is it really =93A single encapsulation=94?
The encapsulation should = depend on the underlay networks. Underlay network could be IP based, = MPLS based, or Ethernet based.  
 
Linda
From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]= On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, September 03, 2013 11:01 AM
To: nsc@ietf.org
Subject: [nsc] NSC Working Group Charter Proposal
 
Greetings,
 
As we look forward to the formation = of a working group that will focus on network service chaining, I would = like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing = area AD's. The following is a first draft of the charter and I invite = you to actively participate and provide inputs into this = process.
 
Proposed NSC WG = Charter
 
Existing service insertion and = deployment techniques have not evolved to meet modern network = architectures and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. = Networks, servers, storage, and applications, have all undergone = significant change in recent years: virtualization, network overlays, = and orchestration are increasingly the norm. All of these have profound effects on network and services design.
 
Today, deploying new services, or = making changes to existing services, often requires network topology = changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological = changes leading to mostly-static service definitions. New service = insertion and deployment techniques must enable the concept of service = functions as shared resources, and enable the linkage of these resources using service chains that represent the abstracted = view of the required service functions, and define the order in which = they should be applied. When a service chain is instantiated in a = network, specific instances of service functions are selected, and a service topology is created and used for forwarding = packets through the service chain.
 
A basic service chain might simply = utilize an existing overlay technology to force traffic through the = necessary service functions. However, additional information enables a richer service chain for more advanced composite services. = For example, shared information (e.g., the result of classification) can = be used to offload service function processing or inform other service = functions about information that would otherwise be hard to glean. 
 
The Network Service Chaining (NSC) = working group focuses on new approaches to service insertion and = deployment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary = protocols for the creation of service chains, and the passing of = metadata from the network to service functions, and between service = functions. When possible, the WG will extend existing protocols to provide service chaining functionality, and any protocol = extensions will be reviewed by both the Network Service Chaining WG and = by the WG responsible for the protocol being extended. =  
 
Specifically, the Network Service = Chaining WG is chartered to deliver the following work = items: 
 
1) Problem Statement: this document = will provide a summary of the problem space to be addressed by the = Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on = nomenclature and definitions for Network Service Chaining.
 
2) System Architecture: this set of = documents will provide a description of the architecture building blocks = and their relationships including interconnection, placement of capabilities, and security models, as well as requirements = on the control mechanisms and data plane encapsulation.
 
3) Service Chaining Data Plane: this = document will describe on the wire data plane encapsulation in support = of (2).  A single encapsulation will be selected in order to enable interoperability of data plane = components.
 
4) Manageability: this document will = address service chaining operation, monitoring and troubleshooting = including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they = are realized.
 
Proposed Milestones:
 
Dec 2013 Request publication of an = Informational document defining the Network Service Chaining problem = statement to the IESG
 
Mar 2014 Request publication of = informational documents defining the system architecture including = protocol requirements and framework to the IESG
 
May 2014 Request publication of a = Standards Track document specifying the data-plane (including metadata) = for Service Chaining to IESG
 
May 2014 Request publication of an = informational document specifying Service Chaining Control Plane = requirements to IESG
 
Dec 2014 Request publication of = informational documents defining Service Chaining manageability = requirements including MIBs, OAM, and information models to IESG 
 
 
_______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/ma= ilman/listinfo/nsc
_______________________________________________
nsc mailing = list
nsc@ietf.org
https://www.ietf.org/mail= man/listinfo/nsc

= --Apple-Mail=_44B14967-B674-4E2F-96A1-B124924C746F-- --Apple-Mail=_2899AE22-FF39-4A7D-B452-8490BE56C191 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIp820ACgkQtfDPGTp3USwKVgCgtntO9OlkgcE67B8dj4+mYSm2 jYMAn1WKJc5CkYJt2WH97/N7+kxhj/kt =oRKo -----END PGP SIGNATURE----- --Apple-Mail=_2899AE22-FF39-4A7D-B452-8490BE56C191-- From cpignata@cisco.com Fri Sep 6 08:26: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 F1FCF11E82C7 for ; Fri, 6 Sep 2013 08:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 Mx9Azi4nRCWn for ; Fri, 6 Sep 2013 08:26:04 -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 4336211E82C0 for ; Fri, 6 Sep 2013 08:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3932; q=dns/txt; s=iport; t=1378481139; x=1379690739; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LKYCmspUVVpmeSoDhXues1VQzS4qagiZeEy/UqdnrHg=; b=mO6lxZnVuJNSnwgbOwj+1AlP3oxVNzGyeXAfp3dXL0EzbRLehRlZum7U wwzqZmWuHUoKFKkgNFiX68noBP7/Ocj8tMsfA9geB/NDuPhzBSINTZhs9 PfX7KR3hFIRgd0gUoA9sKsWw1ZlPp65IuTZ1/C7GGASvzAznZGyhk6Haf g=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAGPzKVKtJXG9/2dsb2JhbABbgwc1UcFVgSQWdIIkAQEBAwEBAQFrCwUHBAIBCBEEAQELHQcnCxQJCAIEDgUIAQWHbgYMvheOQ4EIMQIFBoMXgQADkCOBLoJKlUCDIIFxOQ X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="asc'?scan'208";a="256327075" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 06 Sep 2013 15:25:38 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r86FPcZf031890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 15:25:38 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 10:25:37 -0500 From: "Carlos Pignataro (cpignata)" To: Linda Dunbar Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAIAAKPeAgAAgwgCAAPvEAIAAEw+A Date: Fri, 6 Sep 2013 15:25:37 +0000 Message-ID: <95067C434CE250468B77282634C96ED325EFDB5B@xmb-aln-x02.cisco.com> References: <68B171751455884590F8E38E96416F363F6777F2@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9E0BB@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645B9E85C@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9E85C@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: multipart/signed; boundary="Apple-Mail=_B1E50836-3598-433A-8095-428BA27EF379"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore , Ron Parker Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 15:26:15 -0000 --Apple-Mail=_B1E50836-3598-433A-8095-428BA27EF379 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Linda, I have to admit that I am a bit lost with this comment or a couple of = previous ones. Consequently, I wanted to send a (hopefully) clarifying = summary. The goal is to send a packet (original-payload from a service = perspective) with added service context to a service node. This is a = two-step approach: we can call the steps 1. service (inner), 2. = transport. A service chain defines a set of services applied to an original = payload. To provide chain context, service path id, classification info, = etc., a service-level encapsulation/header is added. This should be = encapsulating-layer (transport-layer) agnostic. Second, in order get = that to a service node, it gets further encapsulated (in IP, IP/GRE, = IP/UDP, VXLAN, MPLS, etc) for delivery. Being a graphical person, I also really like what Surendra shared at = http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html HTH, -- Carlos. On Sep 6, 2013, at 10:17 AM, Linda Dunbar wrote: > Ron,=20 >=20 > Great! I am glad to see that we go down this path.=20 > We should also allow: /enet/ip/udp or tcp/nsc/... > i.e. not necessarily having an inner IP.=20 >=20 > Linda >=20 >=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Thursday, September 05, 2013 6:16 PM >> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; = nsc@ietf.org >> Subject: RE: [nsc] NSC Working Group Charter Proposal >>=20 >> Hi, Linda. >>=20 >> As it was recently explained on this thread, I don't think it needs = to >> be necessary to always have it if we are willing to allow multiple >> overall "transport"+service encapsulations. For example: >>=20 >> /enet/ip/udp/nsc/ip/tcp/... >> /enet/ip/gre/nsc/ip/tcp/... >> /enet/llc-snap/nsc/ip/tcp/... >> /enet/mpls/nsc/ip/tcp/... >>=20 >> As much as I don't think we'll end up there, I do find a single = overall >> universal transformation very attractive and any flavor that is >> /{l2}/ip/xxx/ip/tcp would be universally applicable -- same subnet or >> different subnet, l2 switches and/or l3 routers in between , OpenFlow >> or not OpenFlow, MPLS or not MPLS, ... The argument against this >> will be that the packets are bigger than they need to be for some >> network topologies/protocols. Simplicity or efficiency? >>=20 >> Ron >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> Sent: Thursday, September 05, 2013 5:19 PM >> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org >> Subject: RE: [nsc] NSC Working Group Charter Proposal >>=20 >> I can see the need for this "NSC" header inserted to the packets, and >> occasionally needing an "outer-ip" encapsulation to by-pass nodes = that >> can't parse the "NSC" header. >>=20 >> Can someone explain why it is necessary to always have the "outer-ip" >> header? >>=20 >>=20 >>> -----Original Message----- >>>=20 >>> Outer-ip/udp/nsc/inner-ip/tcp/payload >>=20 >>=20 >>=20 >> Linda > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc --Apple-Mail=_B1E50836-3598-433A-8095-428BA27EF379 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIp8/EACgkQtfDPGTp3USwqZwCggTrZcQHYuy4oLXXXv9KT4M71 hKMAn2ReqwWaFNvG6Jvt+PlUnxmc/MD6 =696+ -----END PGP SIGNATURE----- --Apple-Mail=_B1E50836-3598-433A-8095-428BA27EF379-- From cpignata@cisco.com Fri Sep 6 08:28: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 E46FC21F841D for ; Fri, 6 Sep 2013 08:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 woS2YorUwhSq for ; Fri, 6 Sep 2013 08:28:17 -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 EBF5421E80FA for ; Fri, 6 Sep 2013 08:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1934; q=dns/txt; s=iport; t=1378481297; x=1379690897; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=73eE5jv9sz58AfwUdShWe5LHDh74b+1T7/EUkDAtE40=; b=PHk/9W7+1mIyinZ+2WK10BeO47VLy9xhT7dhpOFLMsACwnnNQuU/9lF3 mpHvY9XgMm40nkvS3knnfL7HBRM9GTkJXmF4GqvHKObfm57X0/AkxLWTC mhpNKIYC/oyQvjz4ppxgPpyzAgI2LoAgSMEA4X3HjoHVtBDyLd29JJbnV c=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFANzzKVKtJXG//2dsb2JhbABbgwc1UcFVgSQWdIIkAQEBAwEBAQEkQAcLBQsCAQgYCiQhBgslAgQOBQgGh2IDCQYMtRgNiHIEjQ6CPTEHgx2BAAOQI4EugkqBcY4ghS+DIIIq X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="asc'?scan'208";a="256540274" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 06 Sep 2013 15:28:16 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r86FSG0C021554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 15:28:16 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 10:28:16 -0500 From: "Carlos Pignataro (cpignata)" To: Melinda Shore Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIABeWaA Date: Fri, 6 Sep 2013 15:28:15 +0000 Message-ID: <95067C434CE250468B77282634C96ED325EFDBDD@xmb-aln-x02.cisco.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <68B171751455884590F8E38E96416F363F676C32@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9DBA7@dfweml509-mbx.china.huawei.com> <5228B7FA.80601@gmail.com> In-Reply-To: <5228B7FA.80601@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: multipart/signed; boundary="Apple-Mail=_3D2008BB-FFFB-45D7-BDD1-059A2D1A4523"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 15:28:22 -0000 --Apple-Mail=_3D2008BB-FFFB-45D7-BDD1-059A2D1A4523 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 5, 2013, at 12:57 PM, Melinda Shore = wrote: > On 9/5/13 6:45 AM, Linda Dunbar wrote: >> This version hasn=92t addressed the comments on Bullet 3 of requiring = a >> single encapsulation being too limiting or may not even be realistic. >=20 > There's no agreement that that's the case. I disagree that aiming for a single service-level encap is too limiting. = Much on the contrary, I think it should be a clear explicit goal if we = are to aim for interoperability. I think the most recent version sent by Jim is good: --->8--- 3) Service Chaining Data & Control Plane: A data plane document will = describe on the wire data plane encapsulation in support of (2). A = single service-level encapsulation will be selected in order to enable = interoperability of data plane components, which can in turn be carried = in various transport encapsulations (e.g., IP, MPLS, or other overlays). = Supporting control plane protocol elements will be added as needed (as a = separate document). --->8--- -- Carlos. >=20 > Melinda >=20 >=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc --Apple-Mail=_3D2008BB-FFFB-45D7-BDD1-059A2D1A4523 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIp9I8ACgkQtfDPGTp3USyj+gCgmBbLJf4zzrLOrM6TqNW0360j opoAoLee3L2u4slkfMjeE5wCcFeMfa6A =878h -----END PGP SIGNATURE----- --Apple-Mail=_3D2008BB-FFFB-45D7-BDD1-059A2D1A4523-- From kgray@juniper.net Fri Sep 6 08:32: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 D4B5B11E82B9 for ; Fri, 6 Sep 2013 08:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[AWL=1.490, 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 7oqW77MhdC-J for ; Fri, 6 Sep 2013 08:32:38 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1189711E82AA for ; Fri, 6 Sep 2013 08:32:38 -0700 (PDT) Received: from mail39-co9-R.bigfish.com (10.236.132.235) by CO9EHSOBE037.bigfish.com (10.236.130.100) with Microsoft SMTP Server id 14.1.225.22; Fri, 6 Sep 2013 15:32:37 +0000 Received: from mail39-co9 (localhost [127.0.0.1]) by mail39-co9-R.bigfish.com (Postfix) with ESMTP id 87DCBD0021D; Fri, 6 Sep 2013 15:32:37 +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: -22 X-BigFish: VPS-22(zzbb2dI98dI9371I542I1432Idb82h853kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail39-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(479174003)(189002)(199002)(24454002)(377454003)(51704005)(83322001)(19580405001)(76176001)(19580395003)(74706001)(561944002)(74876001)(74502001)(47446002)(81816001)(81686001)(76786001)(76796001)(74662001)(83506001)(31966008)(83072001)(36756003)(80022001)(79102001)(76482001)(77982001)(63696002)(47736001)(54316002)(56776001)(65816001)(81542001)(69226001)(77096001)(49866001)(59766001)(81342001)(56816003)(51856001)(74366001)(80976001)(46102001)(47976001)(4396001)(50986001)(54356001)(53806001)(21314002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB081; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail39-co9 (localhost.localdomain [127.0.0.1]) by mail39-co9 (MessageSwitch) id 1378481555198712_4044; Fri, 6 Sep 2013 15:32:35 +0000 (UTC) Received: from CO9EHSMHS028.bigfish.com (unknown [10.236.132.231]) by mail39-co9.bigfish.com (Postfix) with ESMTP id 0F5FCA40064; Fri, 6 Sep 2013 15:32:35 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS028.bigfish.com (10.236.130.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 6 Sep 2013 15:32:27 +0000 Received: from BL2PR05MB081.namprd05.prod.outlook.com (10.255.232.14) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.353.4; Fri, 6 Sep 2013 15:32:26 +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.745.25; Fri, 6 Sep 2013 15:32:25 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.191]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.191]) with mapi id 15.00.0745.000; Fri, 6 Sep 2013 15:32:25 +0000 From: Ken Gray To: Ron Parker , Linda Dunbar , "Jim Guichard (jguichar)" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAACkCAIAADRKAgAABLQCAABHdAIAAKPeAgAAgwwCAAPvDAP//wsQAgAAPHYA= Date: Fri, 6 Sep 2013 15:32:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 0961DF5286 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% Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 15:32:43 -0000 Hey, Ron. I tend to agree with the charter proposal as is. Those four documents should be more than adequate. The design/analysis document could be used as a strawman for the discussion of the decisions imbedded in the ultimate architecture document, but doesn't have to have a life of it's own ...those discussions can/would typically be archived in the WG mailer (THIS mailer) for anyone who would want to catch up on the discussion, IMO. (I had to capitalize the THIS because I also don't believe we need more than THIS list to discuss WG business. This has nothing to do with Ron, btw, I'm editorializing.) On 9/6/13 10:38 AM, "Ron Parker" wrote: >Hi, Linda,=20 > >When I referenced an inner IP, I more properly should have referenced >"original packet", which I think you are pointing out, correctly, is not >necessarily IP. Even in this case, I think it is important to state >whether a new "transport" is always required in front of the "original >packet" or not.=20 > >So if we exemplify this with a layer 2 "transport" and a layer 2 original >packet, we might have something like: > > /encaps-enet/llc-snap/nsc-header/original-enet/payload > >If we take another example of a layer 2/3/4 "transport" and a layer 2 >original packet, we might have something like: > > /encaps-enet/ip/udp/nsc-header/original-enet/payload > >The reason I am being pedantic here is that these approaches contrast to >other possible solutions where an outer "transport" is not added. For >example, if we were entertaining mapping the nsc-header to a new IPv4 >option and new IPv6 extension header for use only when the "original >packet" is an IPv4 or IPv6 packet, then an encapsulating "transport" >would not necessarily be required. Again, we come to >simplicity/universality vs. efficiency (at least in terms of packet size >if not necessarily processing requirements). > >This is obviously an important area to cover in the WG. Some of this >analysis is presented in draft-boucadair-chaining-design-analysis and we >intend to add more of this pros/cons analysis wrt the overall >encapsulation issue in an upcoming revision. > >I would like to take the opportunity to back previous suggestions that a >design choices analysis document become a part of the WG chartered >deliverables as it encourages a more open and transparent process and >ultimately provides a better record of how the eventual recommendations >are arrived at. > > Ron > >=09 > >-----Original Message----- >From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >Sent: Friday, September 06, 2013 10:17 AM >To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org >Subject: RE: [nsc] NSC Working Group Charter Proposal > >Ron,=20 > >Great! I am glad to see that we go down this path. >We should also allow: /enet/ip/udp or tcp/nsc/... >i.e. not necessarily having an inner IP. > >Linda > > >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Thursday, September 05, 2013 6:16 PM >> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org >> Subject: RE: [nsc] NSC Working Group Charter Proposal >>=20 >> Hi, Linda. >>=20 >> As it was recently explained on this thread, I don't think it needs to >> be necessary to always have it if we are willing to allow multiple >> overall "transport"+service encapsulations. For example: >>=20 >> /enet/ip/udp/nsc/ip/tcp/... >> /enet/ip/gre/nsc/ip/tcp/... >> /enet/llc-snap/nsc/ip/tcp/... >> /enet/mpls/nsc/ip/tcp/... >>=20 >> As much as I don't think we'll end up there, I do find a single >> overall universal transformation very attractive and any flavor that >> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same subnet >> or different subnet, l2 switches and/or l3 routers in between , OpenFlow >> or not OpenFlow, MPLS or not MPLS, ... The argument against this >> will be that the packets are bigger than they need to be for some >> network topologies/protocols. Simplicity or efficiency? >>=20 >> Ron >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> Sent: Thursday, September 05, 2013 5:19 PM >> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org >> Subject: RE: [nsc] NSC Working Group Charter Proposal >>=20 >> I can see the need for this "NSC" header inserted to the packets, and >> occasionally needing an "outer-ip" encapsulation to by-pass nodes that >> can't parse the "NSC" header. >>=20 >> Can someone explain why it is necessary to always have the "outer-ip" >> header? >>=20 >>=20 >> > -----Original Message----- >> > >> > Outer-ip/udp/nsc/inner-ip/tcp/payload >>=20 >>=20 >>=20 >> Linda >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > From linda.dunbar@huawei.com Fri Sep 6 08:36: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 8759221E80BB for ; Fri, 6 Sep 2013 08:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.324, 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 j-+a3VI+AawO for ; Fri, 6 Sep 2013 08:36:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 92CA411E8191 for ; Fri, 6 Sep 2013 08:36:52 -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.5-GA FastPath queued) with ESMTP id AWY98217; Fri, 06 Sep 2013 15:36:44 +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.146.0; Fri, 6 Sep 2013 16:36:18 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 16:36:39 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Fri, 6 Sep 2013 08:36:33 -0700 From: Linda Dunbar To: "Carlos Pignataro (cpignata)" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAJ5aAP//lE3ggAB58wD//5m/sIAAGcwQgAAwdeCAAP1hUIAAiQiA//+L0XA= Date: Fri, 6 Sep 2013 15:36:33 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9EA6D@dfweml509-mbx.china.huawei.com> References: <68B171751455884590F8E38E96416F363F6777F2@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B9E0BB@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645B9E85C@dfweml509-mbx.china.huawei.com> <95067C434CE250468B77282634C96ED325EFDB5B@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED325EFDB5B@xmb-aln-x02.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore , Ron Parker Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 15:36:57 -0000 Carlos,=20 I agree that you have to use Outer Transport Layer to pass information amon= g Service Nodes.=20 However, I think that we need to acknowledge that many of today's Service N= odes, e.g. FW, LB, etc, especially the ones that are one link away from For= warding nodes, don't even use any addresses. If the Forwarding nodes have t= he needed traffic clarification means, they can direct the selective traffi= c that need the "Service" to the service nodes. It is not "one size" fits all for all Service nodes.=20 Linda =20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Carlos Pignataro (cpignata) > Sent: Friday, September 06, 2013 10:26 AM > To: Linda Dunbar > Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore; Ron Parker > Subject: Re: [nsc] NSC Working Group Charter Proposal >=20 > Hi, Linda, >=20 > I have to admit that I am a bit lost with this comment or a couple of > previous ones. Consequently, I wanted to send a (hopefully) clarifying > summary. >=20 > The goal is to send a packet (original-payload from a service > perspective) with added service context to a service node. This is a > two-step approach: we can call the steps 1. service (inner), 2. > transport. >=20 > A service chain defines a set of services applied to an original > payload. To provide chain context, service path id, classification info, > etc., a service-level encapsulation/header is added. This should be > encapsulating-layer (transport-layer) agnostic. Second, in order get > that to a service node, it gets further encapsulated (in IP, IP/GRE, > IP/UDP, VXLAN, MPLS, etc) for delivery. >=20 > Being a graphical person, I also really like what Surendra shared at > http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html >=20 > HTH, >=20 > -- Carlos. >=20 > On Sep 6, 2013, at 10:17 AM, Linda Dunbar > wrote: >=20 > > Ron, > > > > Great! I am glad to see that we go down this path. > > We should also allow: /enet/ip/udp or tcp/nsc/... > > i.e. not necessarily having an inner IP. > > > > Linda > > > > > >> -----Original Message----- > >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> Sent: Thursday, September 05, 2013 6:16 PM > >> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; > >> nsc@ietf.org > >> Subject: RE: [nsc] NSC Working Group Charter Proposal > >> > >> Hi, Linda. > >> > >> As it was recently explained on this thread, I don't think it needs > >> to be necessary to always have it if we are willing to allow > multiple > >> overall "transport"+service encapsulations. For example: > >> > >> /enet/ip/udp/nsc/ip/tcp/... > >> /enet/ip/gre/nsc/ip/tcp/... > >> /enet/llc-snap/nsc/ip/tcp/... > >> /enet/mpls/nsc/ip/tcp/... > >> > >> As much as I don't think we'll end up there, I do find a single > >> overall universal transformation very attractive and any flavor that > >> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same > subnet > >> or different subnet, l2 switches and/or l3 routers in between , > OpenFlow > >> or not OpenFlow, MPLS or not MPLS, ... The argument against this > >> will be that the packets are bigger than they need to be for some > >> network topologies/protocols. Simplicity or efficiency? > >> > >> Ron > >> > >> > >> > >> -----Original Message----- > >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > >> Sent: Thursday, September 05, 2013 5:19 PM > >> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org > >> Subject: RE: [nsc] NSC Working Group Charter Proposal > >> > >> I can see the need for this "NSC" header inserted to the packets, > and > >> occasionally needing an "outer-ip" encapsulation to by-pass nodes > >> that can't parse the "NSC" header. > >> > >> Can someone explain why it is necessary to always have the "outer- > ip" > >> header? > >> > >> > >>> -----Original Message----- > >>> > >>> Outer-ip/udp/nsc/inner-ip/tcp/payload > >> > >> > >> > >> Linda > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Fri Sep 6 08:43: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 DDD8C11E81A9 for ; Fri, 6 Sep 2013 08:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9CkaW+hrfUN for ; Fri, 6 Sep 2013 08:42: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 E512911E8122 for ; Fri, 6 Sep 2013 08:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4897; q=dns/txt; s=iport; t=1378482178; x=1379691778; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ulXOwumWFQnro8eU+eCp0RitiUv3DrUfTzvmVrKmNRg=; b=CsEecrai5rZa+rNKFRztAU3L54fOQviuYNMxxbMG0w+3edkLY1/sN9+m olAWgWa3XfoTIEQlQvBI9zXqChu2QzgNbYNWKFRcby3kDCKWmkR7fKXFD SAo6PMCcawXlsPiraCMTZeK/eKt0HpysDMqUXixIh4o/yr8cmQBKDBgex g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAGf3KVKtJV2a/2dsb2JhbABbgwc1UcFVgSQWdIIkAQEBAwEBAQFrCwUHBgEIEQQBAQEKHS4LFAkIAgQBDQUIAYdzBgy+BI5DgQgxAgUGgxeBAAOIfYselUCDIIFxOQ X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="scan'208";a="256546006" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 06 Sep 2013 15:42:57 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r86FgvJd020190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 15:42:57 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 10:42:56 -0500 From: "Jim Guichard (jguichar)" To: Linda Dunbar , "Carlos Pignataro (cpignata)" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAIAAKPeAgAAgwgCAAPvEAIAAEw+AgAADDoD//764AA== Date: Fri, 6 Sep 2013 15:42:56 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6788C8@xmb-rcd-x01.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9EA6D@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.246.115] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0E448D1615FEBA469327573DE542AB71@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , Melinda Shore , Ron Parker Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 15:43:03 -0000 Linda, I don=B9t think anyone is saying that you use outer transport layer for passing information among service nodes; to the contrary, the outer transport layer is simply used to get packets from point A to point B and *nothing* more. If point B happens to be a service node that is acting on behalf of an attached service function then point B may use the service-encapsulation to figure out how to forward the packet to the right service function. =20 On 9/6/13 11:36 AM, "Linda Dunbar" wrote: >Carlos,=20 > >I agree that you have to use Outer Transport Layer to pass information >among Service Nodes. > >However, I think that we need to acknowledge that many of today's Service >Nodes, e.g. FW, LB, etc, especially the ones that are one link away from >Forwarding nodes, don't even use any addresses. If the Forwarding nodes >have the needed traffic clarification means, they can direct the >selective traffic that need the "Service" to the service nodes. > >It is not "one size" fits all for all Service nodes. > >Linda =20 > > > >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Carlos Pignataro (cpignata) >> Sent: Friday, September 06, 2013 10:26 AM >> To: Linda Dunbar >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore; Ron Parker >> Subject: Re: [nsc] NSC Working Group Charter Proposal >>=20 >> Hi, Linda, >>=20 >> I have to admit that I am a bit lost with this comment or a couple of >> previous ones. Consequently, I wanted to send a (hopefully) clarifying >> summary. >>=20 >> The goal is to send a packet (original-payload from a service >> perspective) with added service context to a service node. This is a >> two-step approach: we can call the steps 1. service (inner), 2. >> transport. >>=20 >> A service chain defines a set of services applied to an original >> payload. To provide chain context, service path id, classification info, >> etc., a service-level encapsulation/header is added. This should be >> encapsulating-layer (transport-layer) agnostic. Second, in order get >> that to a service node, it gets further encapsulated (in IP, IP/GRE, >> IP/UDP, VXLAN, MPLS, etc) for delivery. >>=20 >> Being a graphical person, I also really like what Surendra shared at >> http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html >>=20 >> HTH, >>=20 >> -- Carlos. >>=20 >> On Sep 6, 2013, at 10:17 AM, Linda Dunbar >> wrote: >>=20 >> > Ron, >> > >> > Great! I am glad to see that we go down this path. >> > We should also allow: /enet/ip/udp or tcp/nsc/... >> > i.e. not necessarily having an inner IP. >> > >> > Linda >> > >> > >> >> -----Original Message----- >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> Sent: Thursday, September 05, 2013 6:16 PM >> >> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; >> >> nsc@ietf.org >> >> Subject: RE: [nsc] NSC Working Group Charter Proposal >> >> >> >> Hi, Linda. >> >> >> >> As it was recently explained on this thread, I don't think it needs >> >> to be necessary to always have it if we are willing to allow >> multiple >> >> overall "transport"+service encapsulations. For example: >> >> >> >> /enet/ip/udp/nsc/ip/tcp/... >> >> /enet/ip/gre/nsc/ip/tcp/... >> >> /enet/llc-snap/nsc/ip/tcp/... >> >> /enet/mpls/nsc/ip/tcp/... >> >> >> >> As much as I don't think we'll end up there, I do find a single >> >> overall universal transformation very attractive and any flavor that >> >> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same >> subnet >> >> or different subnet, l2 switches and/or l3 routers in between , >> OpenFlow >> >> or not OpenFlow, MPLS or not MPLS, ... The argument against this >> >> will be that the packets are bigger than they need to be for some >> >> network topologies/protocols. Simplicity or efficiency? >> >> >> >> Ron >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> >> Sent: Thursday, September 05, 2013 5:19 PM >> >> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org >> >> Subject: RE: [nsc] NSC Working Group Charter Proposal >> >> >> >> I can see the need for this "NSC" header inserted to the packets, >> and >> >> occasionally needing an "outer-ip" encapsulation to by-pass nodes >> >> that can't parse the "NSC" header. >> >> >> >> Can someone explain why it is necessary to always have the "outer- >> ip" >> >> header? >> >> >> >> >> >>> -----Original Message----- >> >>> >> >>> Outer-ip/udp/nsc/inner-ip/tcp/payload >> >> >> >> >> >> >> >> Linda >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc > From cpignata@cisco.com Fri Sep 6 08:46: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 E68D221E81D9 for ; Fri, 6 Sep 2013 08:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 MHt9Zd8gdw2v for ; Fri, 6 Sep 2013 08:46:37 -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 8AB6F21E810A for ; Fri, 6 Sep 2013 08:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6103; q=dns/txt; s=iport; t=1378482387; x=1379691987; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ltufqpnsiSjW/FadaoYAjf4N/82wAsEYQEN2n+VrVlY=; b=L2NEzMKbC3uKJk06iWz1gdYTXkqXG4lQtaQ1gHnqJoscxEpexX/jEOpc BlA55U9uW997ZFoUHYpVsCwRGC7AoIYTa1jTyjy3aMhXP1Ag57jONN4ig 6NM+1K0w+7PKbtzn2+xM91C28VxpJLRpY5wk+VNZEd5AaL+/rsKcS7gYn c=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAI74KVKtJXHA/2dsb2JhbABbgwc1RQzBVYEkFnSCJAEBAQMBAQEBawsFBwQCAQgRBAEBAQodBycLFAkIAgQOBQgBBYduBgy+Bo5DgQgxAgUGgxeBAAOQI4EugkqVQIMggXE5 X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="asc'?scan'208";a="256547489" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 06 Sep 2013 15:46:26 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r86FkQwD021547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 15:46:26 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 10:46:26 -0500 From: "Carlos Pignataro (cpignata)" To: "Jim Guichard (jguichar)" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAIAAKPeAgAAgwgCAAPvEAIAAEw+AgAADDoD//764AIAARAkA Date: Fri, 6 Sep 2013 15:46:24 +0000 Message-ID: <95067C434CE250468B77282634C96ED325EFE166@xmb-aln-x02.cisco.com> References: <68B171751455884590F8E38E96416F363F6788C8@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6788C8@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: multipart/signed; boundary="Apple-Mail=_74B60D3A-77B6-42BE-9981-BDD858CDAD6F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "nsc@ietf.org" , Melinda Shore , Ron Parker , Linda Dunbar Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 15:46:50 -0000 --Apple-Mail=_74B60D3A-77B6-42BE-9981-BDD858CDAD6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Linda, What Jim said. I was not saying this: > Carlos,=20 >=20 > I agree that you have to use Outer Transport Layer to pass information > among Service Nodes. -- Carlos. On Sep 6, 2013, at 11:42 AM, "Jim Guichard (jguichar)" = wrote: > Linda, >=20 > I don=B9t think anyone is saying that you use outer transport layer = for > passing information among service nodes; to the contrary, the outer > transport layer is simply used to get packets from point A to point B = and > *nothing* more. If point B happens to be a service node that is acting = on > behalf of an attached service function then point B may use the > service-encapsulation to figure out how to forward the packet to the = right > service function. =20 >=20 > On 9/6/13 11:36 AM, "Linda Dunbar" wrote: >=20 >> Carlos,=20 >>=20 >> I agree that you have to use Outer Transport Layer to pass = information >> among Service Nodes. >>=20 >> However, I think that we need to acknowledge that many of today's = Service >> Nodes, e.g. FW, LB, etc, especially the ones that are one link away = from >> Forwarding nodes, don't even use any addresses. If the Forwarding = nodes >> have the needed traffic clarification means, they can direct the >> selective traffic that need the "Service" to the service nodes. >>=20 >> It is not "one size" fits all for all Service nodes. >>=20 >> Linda =20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf = Of >>> Carlos Pignataro (cpignata) >>> Sent: Friday, September 06, 2013 10:26 AM >>> To: Linda Dunbar >>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore; Ron Parker >>> Subject: Re: [nsc] NSC Working Group Charter Proposal >>>=20 >>> Hi, Linda, >>>=20 >>> I have to admit that I am a bit lost with this comment or a couple = of >>> previous ones. Consequently, I wanted to send a (hopefully) = clarifying >>> summary. >>>=20 >>> The goal is to send a packet (original-payload from a service >>> perspective) with added service context to a service node. This is a >>> two-step approach: we can call the steps 1. service (inner), 2. >>> transport. >>>=20 >>> A service chain defines a set of services applied to an original >>> payload. To provide chain context, service path id, classification = info, >>> etc., a service-level encapsulation/header is added. This should be >>> encapsulating-layer (transport-layer) agnostic. Second, in order get >>> that to a service node, it gets further encapsulated (in IP, IP/GRE, >>> IP/UDP, VXLAN, MPLS, etc) for delivery. >>>=20 >>> Being a graphical person, I also really like what Surendra shared at >>> http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html >>>=20 >>> HTH, >>>=20 >>> -- Carlos. >>>=20 >>> On Sep 6, 2013, at 10:17 AM, Linda Dunbar >>> wrote: >>>=20 >>>> Ron, >>>>=20 >>>> Great! I am glad to see that we go down this path. >>>> We should also allow: /enet/ip/udp or tcp/nsc/... >>>> i.e. not necessarily having an inner IP. >>>>=20 >>>> Linda >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>> Sent: Thursday, September 05, 2013 6:16 PM >>>>> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; >>>>> nsc@ietf.org >>>>> Subject: RE: [nsc] NSC Working Group Charter Proposal >>>>>=20 >>>>> Hi, Linda. >>>>>=20 >>>>> As it was recently explained on this thread, I don't think it = needs >>>>> to be necessary to always have it if we are willing to allow >>> multiple >>>>> overall "transport"+service encapsulations. For example: >>>>>=20 >>>>> /enet/ip/udp/nsc/ip/tcp/... >>>>> /enet/ip/gre/nsc/ip/tcp/... >>>>> /enet/llc-snap/nsc/ip/tcp/... >>>>> /enet/mpls/nsc/ip/tcp/... >>>>>=20 >>>>> As much as I don't think we'll end up there, I do find a single >>>>> overall universal transformation very attractive and any flavor = that >>>>> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same >>> subnet >>>>> or different subnet, l2 switches and/or l3 routers in between , >>> OpenFlow >>>>> or not OpenFlow, MPLS or not MPLS, ... The argument against = this >>>>> will be that the packets are bigger than they need to be for some >>>>> network topologies/protocols. Simplicity or efficiency? >>>>>=20 >>>>> Ron >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>>> Sent: Thursday, September 05, 2013 5:19 PM >>>>> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; = nsc@ietf.org >>>>> Subject: RE: [nsc] NSC Working Group Charter Proposal >>>>>=20 >>>>> I can see the need for this "NSC" header inserted to the packets, >>> and >>>>> occasionally needing an "outer-ip" encapsulation to by-pass nodes >>>>> that can't parse the "NSC" header. >>>>>=20 >>>>> Can someone explain why it is necessary to always have the "outer- >>> ip" >>>>> header? >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>>=20 >>>>>> Outer-ip/udp/nsc/inner-ip/tcp/payload >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Linda >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >=20 --Apple-Mail=_74B60D3A-77B6-42BE-9981-BDD858CDAD6F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIp+NAACgkQtfDPGTp3USwU9wCcC6nl1C6rfappsgX7IZc2IY9o xHEAnii/jhvjtSebnFcHk0qcgxZCAtE1 =RIGL -----END PGP SIGNATURE----- --Apple-Mail=_74B60D3A-77B6-42BE-9981-BDD858CDAD6F-- From linda.dunbar@huawei.com Fri Sep 6 08:55: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 D9D2811E819E for ; Fri, 6 Sep 2013 08:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=0.312, 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 HB-X+7ka-hjz for ; Fri, 6 Sep 2013 08:55:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5EB11E8122 for ; Fri, 6 Sep 2013 08:55:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWY99355; Fri, 06 Sep 2013 15:55:10 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 16:54:15 +0100 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.146.0; Fri, 6 Sep 2013 16:54:36 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Fri, 6 Sep 2013 08:54:31 -0700 From: Linda Dunbar To: "Jim Guichard (jguichar)" , "Carlos Pignataro (cpignata)" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAJ5aAP//lE3ggAB58wD//5m/sIAAGcwQgAAwdeCAAP1hUIAAiQiA//+L0XAADyDKAAAOd6ew Date: Fri, 6 Sep 2013 15:54:31 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9EAE4@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645B9EA6D@dfweml509-mbx.china.huawei.com> <68B171751455884590F8E38E96416F363F6788C8@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6788C8@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.192.11.59] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , Melinda Shore , Ron Parker Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 15:55:23 -0000 Jim,=20 What if "A" and "B" in your example are today's existing nodes, (they are n= ot aware of NSC header) and the traffic between "A" and "B" needs a sequenc= e of service functions? Some service functions are one link away from forwarding nodes (or co-locat= ed), which may not require another layer of encapsulation. But some service= functions are accessible via multiple nodes, then there is need for anothe= r layer encapsulation.=20 Linda > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Jim Guichard (jguichar) > Sent: Friday, September 06, 2013 10:43 AM > To: Linda Dunbar; Carlos Pignataro (cpignata) > Cc: nsc@ietf.org; Melinda Shore; Ron Parker > Subject: Re: [nsc] NSC Working Group Charter Proposal >=20 > Linda, >=20 > I don=B9t think anyone is saying that you use outer transport layer for > passing information among service nodes; to the contrary, the outer > transport layer is simply used to get packets from point A to point B > and > *nothing* more. If point B happens to be a service node that is acting > on > behalf of an attached service function then point B may use the > service-encapsulation to figure out how to forward the packet to the > right > service function. >=20 > On 9/6/13 11:36 AM, "Linda Dunbar" wrote: >=20 > >Carlos, > > > >I agree that you have to use Outer Transport Layer to pass information > >among Service Nodes. > > > >However, I think that we need to acknowledge that many of today's > Service > >Nodes, e.g. FW, LB, etc, especially the ones that are one link away > from > >Forwarding nodes, don't even use any addresses. If the Forwarding > nodes > >have the needed traffic clarification means, they can direct the > >selective traffic that need the "Service" to the service nodes. > > > >It is not "one size" fits all for all Service nodes. > > > >Linda > > > > > > > >> -----Original Message----- > >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > >> Carlos Pignataro (cpignata) > >> Sent: Friday, September 06, 2013 10:26 AM > >> To: Linda Dunbar > >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore; Ron Parker > >> Subject: Re: [nsc] NSC Working Group Charter Proposal > >> > >> Hi, Linda, > >> > >> I have to admit that I am a bit lost with this comment or a couple > of > >> previous ones. Consequently, I wanted to send a (hopefully) > clarifying > >> summary. > >> > >> The goal is to send a packet (original-payload from a service > >> perspective) with added service context to a service node. This is a > >> two-step approach: we can call the steps 1. service (inner), 2. > >> transport. > >> > >> A service chain defines a set of services applied to an original > >> payload. To provide chain context, service path id, classification > info, > >> etc., a service-level encapsulation/header is added. This should be > >> encapsulating-layer (transport-layer) agnostic. Second, in order get > >> that to a service node, it gets further encapsulated (in IP, IP/GRE, > >> IP/UDP, VXLAN, MPLS, etc) for delivery. > >> > >> Being a graphical person, I also really like what Surendra shared at > >> http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html > >> > >> HTH, > >> > >> -- Carlos. > >> > >> On Sep 6, 2013, at 10:17 AM, Linda Dunbar > >> wrote: > >> > >> > Ron, > >> > > >> > Great! I am glad to see that we go down this path. > >> > We should also allow: /enet/ip/udp or tcp/nsc/... > >> > i.e. not necessarily having an inner IP. > >> > > >> > Linda > >> > > >> > > >> >> -----Original Message----- > >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> >> Sent: Thursday, September 05, 2013 6:16 PM > >> >> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; > >> >> nsc@ietf.org > >> >> Subject: RE: [nsc] NSC Working Group Charter Proposal > >> >> > >> >> Hi, Linda. > >> >> > >> >> As it was recently explained on this thread, I don't think it > needs > >> >> to be necessary to always have it if we are willing to allow > >> multiple > >> >> overall "transport"+service encapsulations. For example: > >> >> > >> >> /enet/ip/udp/nsc/ip/tcp/... > >> >> /enet/ip/gre/nsc/ip/tcp/... > >> >> /enet/llc-snap/nsc/ip/tcp/... > >> >> /enet/mpls/nsc/ip/tcp/... > >> >> > >> >> As much as I don't think we'll end up there, I do find a single > >> >> overall universal transformation very attractive and any flavor > that > >> >> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same > >> subnet > >> >> or different subnet, l2 switches and/or l3 routers in between , > >> OpenFlow > >> >> or not OpenFlow, MPLS or not MPLS, ... The argument against > this > >> >> will be that the packets are bigger than they need to be for some > >> >> network topologies/protocols. Simplicity or efficiency? > >> >> > >> >> Ron > >> >> > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > >> >> Sent: Thursday, September 05, 2013 5:19 PM > >> >> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; > nsc@ietf.org > >> >> Subject: RE: [nsc] NSC Working Group Charter Proposal > >> >> > >> >> I can see the need for this "NSC" header inserted to the packets, > >> and > >> >> occasionally needing an "outer-ip" encapsulation to by-pass nodes > >> >> that can't parse the "NSC" header. > >> >> > >> >> Can someone explain why it is necessary to always have the > "outer- > >> ip" > >> >> header? > >> >> > >> >> > >> >>> -----Original Message----- > >> >>> > >> >>> Outer-ip/udp/nsc/inner-ip/tcp/payload > >> >> > >> >> > >> >> > >> >> Linda > >> > _______________________________________________ > >> > 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 jguichar@cisco.com Fri Sep 6 08:57: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 1530B11E82C7 for ; Fri, 6 Sep 2013 08:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.685 X-Spam-Level: X-Spam-Status: No, score=-9.685 tagged_above=-999 required=5 tests=[AWL=-0.839, 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 OFYgIEJsSjIK for ; Fri, 6 Sep 2013 08:57: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 0CA7411E8122 for ; Fri, 6 Sep 2013 08:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8712; q=dns/txt; s=iport; t=1378483036; x=1379692636; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=aOfCm9rhIbyumVccA4yzNJjui20my4ih7sN/ScV8m34=; b=iNGG9IZsGHtw6iX8dOqRNL6NNZJXUUY3dIb0xCh72SBSfp1Dopj6Yq6k sdHGITjcVyXmwbM4w4rVeyMU9ecYT6KUVCgSjn+L+Frt67bBDfzzxfWKR orwWj2lJqE1Y//J0kUcKO/VmoFPa9cXU6JhZnv9VufzpaHHVJjgrWv5Ng k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALX6KVKtJV2b/2dsb2JhbABbgwc1UYMqvisXgQ0WdIIkAQEBBAEBATE6CwwGAQgRBAEBAQQGHQUEJQsUCQgCBAENBQgBh3kMkQqbRAaRMIEjjSCBBgIWGwcGgl06gQADlBuVQIMggXE5 X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="scan'208";a="256532106" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 06 Sep 2013 15:56:59 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r86FuxVS025215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 15:56:59 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 10:56:58 -0500 From: "Jim Guichard (jguichar)" To: Linda Dunbar , "Carlos Pignataro (cpignata)" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAIAAKPeAgAAgwgCAAPvEAIAAEw+AgAADDoD//764AIAARk2A//+9noA= Date: Fri, 6 Sep 2013 15:56:57 +0000 Message-ID: <68B171751455884590F8E38E96416F363F67897A@xmb-rcd-x01.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9EAE4@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.246.115] Content-Type: text/plain; charset="euc-kr" Content-ID: <397573CB708AEE43904BFDCC9AB12C29@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nsc@ietf.org" , Melinda Shore , Ron Parker Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 15:57:29 -0000 VGhlbiB1c2Ugcm91dGluZy4NCg0KT24gOS82LzEzIDExOjU0IEFNLCAiTGluZGEgRHVuYmFyIiA8 bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+SmltLCANCj4NCj5XaGF0IGlmICJB IiBhbmQgIkIiIGluIHlvdXIgZXhhbXBsZSBhcmUgdG9kYXkncyBleGlzdGluZyBub2RlcywgKHRo ZXkgYXJlDQo+bm90IGF3YXJlIG9mIE5TQyBoZWFkZXIpIGFuZCB0aGUgdHJhZmZpYyBiZXR3ZWVu ICJBIiBhbmQgIkIiIG5lZWRzIGENCj5zZXF1ZW5jZSBvZiBzZXJ2aWNlIGZ1bmN0aW9ucz8NCj4N Cj5Tb21lIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBvbmUgbGluayBhd2F5IGZyb20gZm9yd2FyZGlu ZyBub2RlcyAob3INCj5jby1sb2NhdGVkKSwgd2hpY2ggbWF5IG5vdCByZXF1aXJlIGFub3RoZXIg bGF5ZXIgb2YgZW5jYXBzdWxhdGlvbi4gQnV0DQo+c29tZSBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUg YWNjZXNzaWJsZSB2aWEgbXVsdGlwbGUgbm9kZXMsIHRoZW4gdGhlcmUgaXMNCj5uZWVkIGZvciBh bm90aGVyIGxheWVyIGVuY2Fwc3VsYXRpb24uDQo+DQo+TGluZGENCj4NCj4NCj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+IEppbSBHdWljaGFyZCAoamd1 aWNoYXIpDQo+PiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAwNiwgMjAxMyAxMDo0MyBBTQ0KPj4g VG86IExpbmRhIER1bmJhcjsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+PiBDYzogbnNj QGlldGYub3JnOyBNZWxpbmRhIFNob3JlOyBSb24gUGFya2VyDQo+PiBTdWJqZWN0OiBSZTogW25z Y10gTlNDIFdvcmtpbmcgR3JvdXAgQ2hhcnRlciBQcm9wb3NhbA0KPj4gDQo+PiBMaW5kYSwNCj4+ IA0KPj4gSSBkb26p9nQgdGhpbmsgYW55b25lIGlzIHNheWluZyB0aGF0IHlvdSB1c2Ugb3V0ZXIg dHJhbnNwb3J0IGxheWVyIGZvcg0KPj4gcGFzc2luZyBpbmZvcm1hdGlvbiBhbW9uZyBzZXJ2aWNl IG5vZGVzOyB0byB0aGUgY29udHJhcnksIHRoZSBvdXRlcg0KPj4gdHJhbnNwb3J0IGxheWVyIGlz IHNpbXBseSB1c2VkIHRvIGdldCBwYWNrZXRzIGZyb20gcG9pbnQgQSB0byBwb2ludCBCDQo+PiBh bmQNCj4+ICpub3RoaW5nKiBtb3JlLiBJZiBwb2ludCBCIGhhcHBlbnMgdG8gYmUgYSBzZXJ2aWNl IG5vZGUgdGhhdCBpcyBhY3RpbmcNCj4+IG9uDQo+PiBiZWhhbGYgb2YgYW4gYXR0YWNoZWQgc2Vy dmljZSBmdW5jdGlvbiB0aGVuIHBvaW50IEIgbWF5IHVzZSB0aGUNCj4+IHNlcnZpY2UtZW5jYXBz dWxhdGlvbiB0byBmaWd1cmUgb3V0IGhvdyB0byBmb3J3YXJkIHRoZSBwYWNrZXQgdG8gdGhlDQo+ PiByaWdodA0KPj4gc2VydmljZSBmdW5jdGlvbi4NCj4+IA0KPj4gT24gOS82LzEzIDExOjM2IEFN LCAiTGluZGEgRHVuYmFyIiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gDQo+ PiA+Q2FybG9zLA0KPj4gPg0KPj4gPkkgYWdyZWUgdGhhdCB5b3UgaGF2ZSB0byB1c2UgT3V0ZXIg VHJhbnNwb3J0IExheWVyIHRvIHBhc3MgaW5mb3JtYXRpb24NCj4+ID5hbW9uZyBTZXJ2aWNlIE5v ZGVzLg0KPj4gPg0KPj4gPkhvd2V2ZXIsIEkgdGhpbmsgdGhhdCB3ZSBuZWVkIHRvIGFja25vd2xl ZGdlIHRoYXQgbWFueSBvZiB0b2RheSdzDQo+PiBTZXJ2aWNlDQo+PiA+Tm9kZXMsIGUuZy4gRlcs IExCLCBldGMsIGVzcGVjaWFsbHkgdGhlIG9uZXMgdGhhdCBhcmUgb25lIGxpbmsgYXdheQ0KPj4g ZnJvbQ0KPj4gPkZvcndhcmRpbmcgbm9kZXMsIGRvbid0IGV2ZW4gdXNlIGFueSBhZGRyZXNzZXMu IElmIHRoZSBGb3J3YXJkaW5nDQo+PiBub2Rlcw0KPj4gPmhhdmUgdGhlIG5lZWRlZCB0cmFmZmlj IGNsYXJpZmljYXRpb24gbWVhbnMsIHRoZXkgY2FuIGRpcmVjdCB0aGUNCj4+ID5zZWxlY3RpdmUg dHJhZmZpYyB0aGF0IG5lZWQgdGhlICJTZXJ2aWNlIiB0byB0aGUgc2VydmljZSBub2Rlcy4NCj4+ ID4NCj4+ID5JdCBpcyBub3QgIm9uZSBzaXplIiBmaXRzIGFsbCBmb3IgYWxsIFNlcnZpY2Ugbm9k ZXMuDQo+PiA+DQo+PiA+TGluZGENCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+IE9mDQo+PiA+PiBDYXJsb3MgUGln bmF0YXJvIChjcGlnbmF0YSkNCj4+ID4+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDA2LCAyMDEz IDEwOjI2IEFNDQo+PiA+PiBUbzogTGluZGEgRHVuYmFyDQo+PiA+PiBDYzogbnNjQGlldGYub3Jn OyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTWVsaW5kYSBTaG9yZTsgUm9uIFBhcmtlcg0KPj4g Pj4gU3ViamVjdDogUmU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwN Cj4+ID4+DQo+PiA+PiBIaSwgTGluZGEsDQo+PiA+Pg0KPj4gPj4gSSBoYXZlIHRvIGFkbWl0IHRo YXQgSSBhbSBhIGJpdCBsb3N0IHdpdGggdGhpcyBjb21tZW50IG9yIGEgY291cGxlDQo+PiBvZg0K Pj4gPj4gcHJldmlvdXMgb25lcy4gQ29uc2VxdWVudGx5LCBJIHdhbnRlZCB0byBzZW5kIGEgKGhv cGVmdWxseSkNCj4+IGNsYXJpZnlpbmcNCj4+ID4+IHN1bW1hcnkuDQo+PiA+Pg0KPj4gPj4gVGhl IGdvYWwgaXMgdG8gc2VuZCBhIHBhY2tldCAob3JpZ2luYWwtcGF5bG9hZCBmcm9tIGEgc2Vydmlj ZQ0KPj4gPj4gcGVyc3BlY3RpdmUpIHdpdGggYWRkZWQgc2VydmljZSBjb250ZXh0IHRvIGEgc2Vy dmljZSBub2RlLiBUaGlzIGlzIGENCj4+ID4+IHR3by1zdGVwIGFwcHJvYWNoOiB3ZSBjYW4gY2Fs bCB0aGUgc3RlcHMgMS4gc2VydmljZSAoaW5uZXIpLCAyLg0KPj4gPj4gdHJhbnNwb3J0Lg0KPj4g Pj4NCj4+ID4+IEEgc2VydmljZSBjaGFpbiBkZWZpbmVzIGEgc2V0IG9mIHNlcnZpY2VzIGFwcGxp ZWQgdG8gYW4gb3JpZ2luYWwNCj4+ID4+IHBheWxvYWQuIFRvIHByb3ZpZGUgY2hhaW4gY29udGV4 dCwgc2VydmljZSBwYXRoIGlkLCBjbGFzc2lmaWNhdGlvbg0KPj4gaW5mbywNCj4+ID4+IGV0Yy4s IGEgc2VydmljZS1sZXZlbCBlbmNhcHN1bGF0aW9uL2hlYWRlciBpcyBhZGRlZC4gVGhpcyBzaG91 bGQgYmUNCj4+ID4+IGVuY2Fwc3VsYXRpbmctbGF5ZXIgKHRyYW5zcG9ydC1sYXllcikgYWdub3N0 aWMuIFNlY29uZCwgaW4gb3JkZXIgZ2V0DQo+PiA+PiB0aGF0IHRvIGEgc2VydmljZSBub2RlLCBp dCBnZXRzIGZ1cnRoZXIgZW5jYXBzdWxhdGVkIChpbiBJUCwgSVAvR1JFLA0KPj4gPj4gSVAvVURQ LCBWWExBTiwgTVBMUywgZXRjKSBmb3IgZGVsaXZlcnkuDQo+PiA+Pg0KPj4gPj4gQmVpbmcgYSBn cmFwaGljYWwgcGVyc29uLCBJIGFsc28gcmVhbGx5IGxpa2Ugd2hhdCBTdXJlbmRyYSBzaGFyZWQg YXQNCj4+ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uc2MvY3VycmVu dC9tc2cwMDMxMi5odG1sDQo+PiA+Pg0KPj4gPj4gSFRILA0KPj4gPj4NCj4+ID4+IC0tIENhcmxv cy4NCj4+ID4+DQo+PiA+PiBPbiBTZXAgNiwgMjAxMywgYXQgMTA6MTcgQU0sIExpbmRhIER1bmJh ciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+DQo+PiA+PiAgd3JvdGU6DQo+PiA+Pg0KPj4gPj4g PiBSb24sDQo+PiA+PiA+DQo+PiA+PiA+IEdyZWF0ISAgSSBhbSBnbGFkIHRvIHNlZSB0aGF0IHdl IGdvIGRvd24gdGhpcyBwYXRoLg0KPj4gPj4gPiBXZSBzaG91bGQgYWxzbyBhbGxvdzogL2VuZXQv aXAvdWRwIG9yIHRjcC9uc2MvLi4uDQo+PiA+PiA+IGkuZS4gbm90IG5lY2Vzc2FyaWx5IGhhdmlu ZyBhbiBpbm5lciBJUC4NCj4+ID4+ID4NCj4+ID4+ID4gTGluZGENCj4+ID4+ID4NCj4+ID4+ID4N Cj4+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+PiBGcm9tOiBSb24g UGFya2VyIFttYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NCj4+ID4+ID4+ IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDUsIDIwMTMgNjoxNiBQTQ0KPj4gPj4gPj4gVG86 IExpbmRhIER1bmJhcjsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IE1lbGluZGEgU2hvcmU7DQo+ PiA+PiA+PiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4+IFN1YmplY3Q6IFJFOiBbbnNjXSBOU0MgV29y a2luZyBHcm91cCBDaGFydGVyIFByb3Bvc2FsDQo+PiA+PiA+Pg0KPj4gPj4gPj4gSGksIExpbmRh Lg0KPj4gPj4gPj4NCj4+ID4+ID4+IEFzIGl0IHdhcyByZWNlbnRseSBleHBsYWluZWQgb24gdGhp cyB0aHJlYWQsIEkgZG9uJ3QgdGhpbmsgaXQNCj4+IG5lZWRzDQo+PiA+PiA+PiB0byBiZSBuZWNl c3NhcnkgdG8gYWx3YXlzIGhhdmUgaXQgaWYgd2UgYXJlIHdpbGxpbmcgdG8gYWxsb3cNCj4+ID4+ IG11bHRpcGxlDQo+PiA+PiA+PiBvdmVyYWxsICJ0cmFuc3BvcnQiK3NlcnZpY2UgZW5jYXBzdWxh dGlvbnMuICAgRm9yIGV4YW1wbGU6DQo+PiA+PiA+Pg0KPj4gPj4gPj4gL2VuZXQvaXAvdWRwL25z Yy9pcC90Y3AvLi4uDQo+PiA+PiA+PiAvZW5ldC9pcC9ncmUvbnNjL2lwL3RjcC8uLi4NCj4+ID4+ ID4+IC9lbmV0L2xsYy1zbmFwL25zYy9pcC90Y3AvLi4uDQo+PiA+PiA+PiAvZW5ldC9tcGxzL25z Yy9pcC90Y3AvLi4uDQo+PiA+PiA+Pg0KPj4gPj4gPj4gQXMgbXVjaCBhcyBJIGRvbid0IHRoaW5r IHdlJ2xsIGVuZCB1cCB0aGVyZSwgSSBkbyBmaW5kIGEgc2luZ2xlDQo+PiA+PiA+PiBvdmVyYWxs IHVuaXZlcnNhbCB0cmFuc2Zvcm1hdGlvbiB2ZXJ5IGF0dHJhY3RpdmUgYW5kIGFueSBmbGF2b3IN Cj4+IHRoYXQNCj4+ID4+ID4+IGlzIC97bDJ9L2lwL3h4eC9pcC90Y3Agd291bGQgYmUgdW5pdmVy c2FsbHkgYXBwbGljYWJsZSAtLSBzYW1lDQo+PiA+PiBzdWJuZXQNCj4+ID4+ID4+IG9yIGRpZmZl cmVudCBzdWJuZXQsIGwyIHN3aXRjaGVzIGFuZC9vciBsMyByb3V0ZXJzIGluIGJldHdlZW4gLA0K Pj4gPj4gT3BlbkZsb3cNCj4+ID4+ID4+IG9yIG5vdCBPcGVuRmxvdywgTVBMUyBvciBub3QgTVBM UywgLi4uICAgICBUaGUgYXJndW1lbnQgYWdhaW5zdA0KPj4gdGhpcw0KPj4gPj4gPj4gd2lsbCBi ZSB0aGF0IHRoZSBwYWNrZXRzIGFyZSBiaWdnZXIgdGhhbiB0aGV5IG5lZWQgdG8gYmUgZm9yIHNv bWUNCj4+ID4+ID4+IG5ldHdvcmsgdG9wb2xvZ2llcy9wcm90b2NvbHMuICAgU2ltcGxpY2l0eSBv ciBlZmZpY2llbmN5Pw0KPj4gPj4gPj4NCj4+ID4+ID4+ICAgUm9uDQo+PiA+PiA+Pg0KPj4gPj4g Pj4NCj4+ID4+ID4+DQo+PiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4g Pj4gRnJvbTogTGluZGEgRHVuYmFyIFttYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb21dDQo+ PiA+PiA+PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDA1LCAyMDEzIDU6MTkgUE0NCj4+ID4+ ID4+IFRvOiBSb24gUGFya2VyOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTWVsaW5kYSBTaG9y ZTsNCj4+IG5zY0BpZXRmLm9yZw0KPj4gPj4gPj4gU3ViamVjdDogUkU6IFtuc2NdIE5TQyBXb3Jr aW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCj4+ID4+ID4+DQo+PiA+PiA+PiBJIGNhbiBzZWUg dGhlIG5lZWQgZm9yIHRoaXMgIk5TQyIgaGVhZGVyIGluc2VydGVkIHRvIHRoZSBwYWNrZXRzLA0K Pj4gPj4gYW5kDQo+PiA+PiA+PiBvY2Nhc2lvbmFsbHkgbmVlZGluZyBhbiAib3V0ZXItaXAiIGVu Y2Fwc3VsYXRpb24gdG8gYnktcGFzcyBub2Rlcw0KPj4gPj4gPj4gdGhhdCBjYW4ndCBwYXJzZSB0 aGUgIk5TQyIgaGVhZGVyLg0KPj4gPj4gPj4NCj4+ID4+ID4+IENhbiBzb21lb25lIGV4cGxhaW4g d2h5IGl0IGlzIG5lY2Vzc2FyeSB0byBhbHdheXMgaGF2ZSB0aGUNCj4+ICJvdXRlci0NCj4+ID4+ IGlwIg0KPj4gPj4gPj4gaGVhZGVyPw0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+PiA+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4+Pg0KPj4gPj4gPj4+IAlPdXRlci1pcC91 ZHAvbnNjL2lubmVyLWlwL3RjcC9wYXlsb2FkDQo+PiA+PiA+Pg0KPj4gPj4gPj4NCj4+ID4+ID4+ DQo+PiA+PiA+PiBMaW5kYQ0KPj4gPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gPj4gPiBuc2MgbWFpbGluZyBsaXN0DQo+PiA+PiA+IG5zY0Bp ZXRmLm9yZw0KPj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25z Yw0KPj4gPg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gbnNjIG1haWxpbmcgbGlzdA0KPj4gbnNjQGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KDQo= From jmoisand@juniper.net Fri Sep 6 09:02: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 BDEE411E819E for ; Fri, 6 Sep 2013 09:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-0.650, 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 bj1Ob1y3Js-R for ; Fri, 6 Sep 2013 09:01:59 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id DCB6321E810A for ; Fri, 6 Sep 2013 09:01:02 -0700 (PDT) Received: from mail85-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Fri, 6 Sep 2013 16:01:00 +0000 Received: from mail85-va3 (localhost [127.0.0.1]) by mail85-va3-R.bigfish.com (Postfix) with ESMTP id 2E0433C019A for ; Fri, 6 Sep 2013 16:01:00 +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: -21 X-BigFish: VPS-21(zzbb2dI98dI9371I542I1432I1418Idb82h853kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail85-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(51704005)(13464003)(199002)(189002)(51444003)(377454003)(479174003)(561944002)(74876001)(80976001)(74316001)(54356001)(53806001)(83322001)(19580395003)(79102001)(19580405001)(76482001)(77982001)(59766001)(54316002)(56816003)(56776001)(15202345003)(77096001)(83072001)(80022001)(66066001)(65816001)(46102001)(33646001)(63696002)(81816001)(69226001)(81686001)(47446002)(74662001)(74502001)(74366001)(15975445006)(74706001)(31966008)(47736001)(47976001)(81342001)(49866001)(50986001)(51856001)(81542001)(76786001)(76796001)(4396001)(76576001)(21314002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB249; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail85-va3 (localhost.localdomain [127.0.0.1]) by mail85-va3 (MessageSwitch) id 1378483257799484_9016; Fri, 6 Sep 2013 16:00:57 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.248]) by mail85-va3.bigfish.com (Postfix) with ESMTP id B73D6200060 for ; Fri, 6 Sep 2013 16:00:57 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 6 Sep 2013 16:00:57 +0000 Received: from BN1PR05MB249.namprd05.prod.outlook.com (10.255.206.11) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.353.4; Fri, 6 Sep 2013 16:00:56 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BN1PR05MB249.namprd05.prod.outlook.com (10.255.206.11) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 6 Sep 2013 16:00:55 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.204]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.204]) with mapi id 15.00.0745.000; Fri, 6 Sep 2013 16:00:54 +0000 From: Jerome Moisand To: "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAIAAKPeAgAAgwgCAAPvEAIAAEw+AgAADDoD//764AP//8nyAAAAVxIAAABhNoA== Date: Fri, 6 Sep 2013 16:00:54 +0000 Message-ID: <6c93fdea00d64a949b31ff6feb647cd7@BN1PR05MB251.namprd05.prod.outlook.com> References: <4A95BA014132FF49AE685FAB4B9F17F645B9EAE4@dfweml509-mbx.china.huawei.com> <68B171751455884590F8E38E96416F363F67897A@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F67897A@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.232.2] x-forefront-prvs: 0961DF5286 Content-Type: text/plain; charset="iso-8859-1" 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] NSC Working Group Charter Proposal 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, 06 Sep 2013 16:02:05 -0000 Guys, could we please keep this discussion for later? We're supposed to dis= cuss a charter here. Not a specific solution.=20 Fair enough? -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Friday, September 06, 2013 11:57 AM To: Linda Dunbar; Carlos Pignataro (cpignata) Cc: nsc@ietf.org; Melinda Shore; Ron Parker Subject: Re: [nsc] NSC Working Group Charter Proposal Then use routing. On 9/6/13 11:54 AM, "Linda Dunbar" wrote: >Jim, > >What if "A" and "B" in your example are today's existing nodes, (they=20 >are not aware of NSC header) and the traffic between "A" and "B" needs=20 >a sequence of service functions? > >Some service functions are one link away from forwarding nodes (or=20 >co-located), which may not require another layer of encapsulation. But=20 >some service functions are accessible via multiple nodes, then there is=20 >need for another layer encapsulation. > >Linda > > >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >> Jim Guichard (jguichar) >> Sent: Friday, September 06, 2013 10:43 AM >> To: Linda Dunbar; Carlos Pignataro (cpignata) >> Cc: nsc@ietf.org; Melinda Shore; Ron Parker >> Subject: Re: [nsc] NSC Working Group Charter Proposal >>=20 >> Linda, >>=20 >> I don=B9t think anyone is saying that you use outer transport layer for= =20 >> passing information among service nodes; to the contrary, the outer=20 >> transport layer is simply used to get packets from point A to point B=20 >> and >> *nothing* more. If point B happens to be a service node that is=20 >> acting on behalf of an attached service function then point B may use=20 >> the service-encapsulation to figure out how to forward the packet to=20 >> the right service function. >>=20 >> On 9/6/13 11:36 AM, "Linda Dunbar" wrote: >>=20 >> >Carlos, >> > >> >I agree that you have to use Outer Transport Layer to pass=20 >> >information among Service Nodes. >> > >> >However, I think that we need to acknowledge that many of today's >> Service >> >Nodes, e.g. FW, LB, etc, especially the ones that are one link away >> from >> >Forwarding nodes, don't even use any addresses. If the Forwarding >> nodes >> >have the needed traffic clarification means, they can direct the=20 >> >selective traffic that need the "Service" to the service nodes. >> > >> >It is not "one size" fits all for all Service nodes. >> > >> >Linda >> > >> > >> > >> >> -----Original Message----- >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >> >> Carlos Pignataro (cpignata) >> >> Sent: Friday, September 06, 2013 10:26 AM >> >> To: Linda Dunbar >> >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore; Ron=20 >> >> Parker >> >> Subject: Re: [nsc] NSC Working Group Charter Proposal >> >> >> >> Hi, Linda, >> >> >> >> I have to admit that I am a bit lost with this comment or a couple >> of >> >> previous ones. Consequently, I wanted to send a (hopefully) >> clarifying >> >> summary. >> >> >> >> The goal is to send a packet (original-payload from a service >> >> perspective) with added service context to a service node. This is=20 >> >> a two-step approach: we can call the steps 1. service (inner), 2. >> >> transport. >> >> >> >> A service chain defines a set of services applied to an original=20 >> >> payload. To provide chain context, service path id, classification >> info, >> >> etc., a service-level encapsulation/header is added. This should=20 >> >> be encapsulating-layer (transport-layer) agnostic. Second, in=20 >> >> order get that to a service node, it gets further encapsulated (in=20 >> >> IP, IP/GRE, IP/UDP, VXLAN, MPLS, etc) for delivery. >> >> >> >> Being a graphical person, I also really like what Surendra shared=20 >> >> at http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html >> >> >> >> HTH, >> >> >> >> -- Carlos. >> >> >> >> On Sep 6, 2013, at 10:17 AM, Linda Dunbar=20 >> >> >> >> wrote: >> >> >> >> > Ron, >> >> > >> >> > Great! I am glad to see that we go down this path. >> >> > We should also allow: /enet/ip/udp or tcp/nsc/... >> >> > i.e. not necessarily having an inner IP. >> >> > >> >> > Linda >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> >> Sent: Thursday, September 05, 2013 6:16 PM >> >> >> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore;=20 >> >> >> nsc@ietf.org >> >> >> Subject: RE: [nsc] NSC Working Group Charter Proposal >> >> >> >> >> >> Hi, Linda. >> >> >> >> >> >> As it was recently explained on this thread, I don't think it >> needs >> >> >> to be necessary to always have it if we are willing to allow >> >> multiple >> >> >> overall "transport"+service encapsulations. For example: >> >> >> >> >> >> /enet/ip/udp/nsc/ip/tcp/... >> >> >> /enet/ip/gre/nsc/ip/tcp/... >> >> >> /enet/llc-snap/nsc/ip/tcp/... >> >> >> /enet/mpls/nsc/ip/tcp/... >> >> >> >> >> >> As much as I don't think we'll end up there, I do find a single=20 >> >> >> overall universal transformation very attractive and any flavor >> that >> >> >> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same >> >> subnet >> >> >> or different subnet, l2 switches and/or l3 routers in between , >> >> OpenFlow >> >> >> or not OpenFlow, MPLS or not MPLS, ... The argument against >> this >> >> >> will be that the packets are bigger than they need to be for some >> >> >> network topologies/protocols. Simplicity or efficiency? >> >> >> >> >> >> Ron >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> >> >> Sent: Thursday, September 05, 2013 5:19 PM >> >> >> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; >> nsc@ietf.org >> >> >> Subject: RE: [nsc] NSC Working Group Charter Proposal >> >> >> >> >> >> I can see the need for this "NSC" header inserted to the=20 >> >> >> packets, >> >> and >> >> >> occasionally needing an "outer-ip" encapsulation to by-pass=20 >> >> >> nodes that can't parse the "NSC" header. >> >> >> >> >> >> Can someone explain why it is necessary to always have the >> "outer- >> >> ip" >> >> >> header? >> >> >> >> >> >> >> >> >>> -----Original Message----- >> >> >>> >> >> >>> Outer-ip/udp/nsc/inner-ip/tcp/payload >> >> >> >> >> >> >> >> >> >> >> >> Linda >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> > >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Fri Sep 6 09:03: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 A6E9F11E81B2 for ; Fri, 6 Sep 2013 09:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.653 X-Spam-Level: X-Spam-Status: No, score=-9.653 tagged_above=-999 required=5 tests=[AWL=-0.807, 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 wOVp5h8cKkx0 for ; Fri, 6 Sep 2013 09:03:46 -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 A19DD11E81B1 for ; Fri, 6 Sep 2013 09:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10096; q=dns/txt; s=iport; t=1378483426; x=1379693026; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=LTNL8kTElw59tQkrPXNnSP9BkccYrgfQHfI5eVgaq20=; b=eHBqvTYo10VGKzhicau8G6esUkXuCXEapxh6ktGipFevphOAg5ReURd6 XphKjQH2QcpRLvFJQy5LML46Axuwdvm+MSqRpPHZTCzWStJ1LpKFtUDFg 2dMJiVEPr80EWOW+qJI6q3xjWvkaMPGLNVFEt/JgdGkSS+e7FiLwI8gbX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFANP7KVKtJXG//2dsb2JhbABbgwc1UYMqvisXgQ0WdIIkAQEBBAEBATE6FwYBCA4DBAEBAQQGHQUEJQsUCQgCBAESCAESh2cMkQWbRAaRLoEjjSCBBgIWIgaCXTqBAAOUG5VAgyCBcTk X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="scan'208";a="256535083" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 06 Sep 2013 16:03:38 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r86G3cLj027643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 16:03:38 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 11:03:38 -0500 From: "Jim Guichard (jguichar)" To: Jerome Moisand , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAIAAKPeAgAAgwgCAAPvEAIAAEw+AgAADDoD//764AIAARk2A//+9noAACIVqAP//vbGA Date: Fri, 6 Sep 2013 16:03:37 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6789EF@xmb-rcd-x01.cisco.com> In-Reply-To: <6c93fdea00d64a949b31ff6feb647cd7@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.86.246.115] Content-Type: text/plain; charset="euc-kr" Content-ID: <22CACEDA1AC81A4E9531834CB95723DD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 16:03:51 -0000 WmlwIDstKQ0KDQpPbiA5LzYvMTMgMTI6MDAgUE0sICJKZXJvbWUgTW9pc2FuZCIgPGptb2lzYW5k QGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPkd1eXMsIGNvdWxkIHdlIHBsZWFzZSBrZWVwIHRoaXMg ZGlzY3Vzc2lvbiBmb3IgbGF0ZXI/IFdlJ3JlIHN1cHBvc2VkIHRvDQo+ZGlzY3VzcyBhIGNoYXJ0 ZXIgaGVyZS4gTm90IGEgc3BlY2lmaWMgc29sdXRpb24uDQo+DQo+RmFpciBlbm91Z2g/DQo+DQo+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltDQo+R3VpY2hhcmQg KGpndWljaGFyKQ0KPlNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDA2LCAyMDEzIDExOjU3IEFNDQo+ VG86IExpbmRhIER1bmJhcjsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+Q2M6IG5zY0Bp ZXRmLm9yZzsgTWVsaW5kYSBTaG9yZTsgUm9uIFBhcmtlcg0KPlN1YmplY3Q6IFJlOiBbbnNjXSBO U0MgV29ya2luZyBHcm91cCBDaGFydGVyIFByb3Bvc2FsDQo+DQo+VGhlbiB1c2Ugcm91dGluZy4N Cj4NCj5PbiA5LzYvMTMgMTE6NTQgQU0sICJMaW5kYSBEdW5iYXIiIDxsaW5kYS5kdW5iYXJAaHVh d2VpLmNvbT4gd3JvdGU6DQo+DQo+PkppbSwNCj4+DQo+PldoYXQgaWYgIkEiIGFuZCAiQiIgaW4g eW91ciBleGFtcGxlIGFyZSB0b2RheSdzIGV4aXN0aW5nIG5vZGVzLCAodGhleQ0KPj5hcmUgbm90 IGF3YXJlIG9mIE5TQyBoZWFkZXIpIGFuZCB0aGUgdHJhZmZpYyBiZXR3ZWVuICJBIiBhbmQgIkIi IG5lZWRzDQo+PmEgc2VxdWVuY2Ugb2Ygc2VydmljZSBmdW5jdGlvbnM/DQo+Pg0KPj5Tb21lIHNl cnZpY2UgZnVuY3Rpb25zIGFyZSBvbmUgbGluayBhd2F5IGZyb20gZm9yd2FyZGluZyBub2RlcyAo b3INCj4+Y28tbG9jYXRlZCksIHdoaWNoIG1heSBub3QgcmVxdWlyZSBhbm90aGVyIGxheWVyIG9m IGVuY2Fwc3VsYXRpb24uIEJ1dA0KPj5zb21lIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBhY2Nlc3Np YmxlIHZpYSBtdWx0aXBsZSBub2RlcywgdGhlbiB0aGVyZSBpcw0KPj5uZWVkIGZvciBhbm90aGVy IGxheWVyIGVuY2Fwc3VsYXRpb24uDQo+Pg0KPj5MaW5kYQ0KPj4NCj4+DQo+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+PiBKaW0gR3VpY2hhcmQgKGpn dWljaGFyKQ0KPj4+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDA2LCAyMDEzIDEwOjQzIEFNDQo+ Pj4gVG86IExpbmRhIER1bmJhcjsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+Pj4gQ2M6 IG5zY0BpZXRmLm9yZzsgTWVsaW5kYSBTaG9yZTsgUm9uIFBhcmtlcg0KPj4+IFN1YmplY3Q6IFJl OiBbbnNjXSBOU0MgV29ya2luZyBHcm91cCBDaGFydGVyIFByb3Bvc2FsDQo+Pj4gDQo+Pj4gTGlu ZGEsDQo+Pj4gDQo+Pj4gSSBkb26p9nQgdGhpbmsgYW55b25lIGlzIHNheWluZyB0aGF0IHlvdSB1 c2Ugb3V0ZXIgdHJhbnNwb3J0IGxheWVyIGZvcg0KPj4+IHBhc3NpbmcgaW5mb3JtYXRpb24gYW1v bmcgc2VydmljZSBub2RlczsgdG8gdGhlIGNvbnRyYXJ5LCB0aGUgb3V0ZXINCj4+PiB0cmFuc3Bv cnQgbGF5ZXIgaXMgc2ltcGx5IHVzZWQgdG8gZ2V0IHBhY2tldHMgZnJvbSBwb2ludCBBIHRvIHBv aW50IEINCj4+PiBhbmQNCj4+PiAqbm90aGluZyogbW9yZS4gSWYgcG9pbnQgQiBoYXBwZW5zIHRv IGJlIGEgc2VydmljZSBub2RlIHRoYXQgaXMNCj4+PiBhY3Rpbmcgb24gYmVoYWxmIG9mIGFuIGF0 dGFjaGVkIHNlcnZpY2UgZnVuY3Rpb24gdGhlbiBwb2ludCBCIG1heSB1c2UNCj4+PiB0aGUgc2Vy dmljZS1lbmNhcHN1bGF0aW9uIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGZvcndhcmQgdGhlIHBhY2tl dCB0bw0KPj4+IHRoZSByaWdodCBzZXJ2aWNlIGZ1bmN0aW9uLg0KPj4+IA0KPj4+IE9uIDkvNi8x MyAxMTozNiBBTSwgIkxpbmRhIER1bmJhciIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPiB3cm90 ZToNCj4+PiANCj4+PiA+Q2FybG9zLA0KPj4+ID4NCj4+PiA+SSBhZ3JlZSB0aGF0IHlvdSBoYXZl IHRvIHVzZSBPdXRlciBUcmFuc3BvcnQgTGF5ZXIgdG8gcGFzcw0KPj4+ID5pbmZvcm1hdGlvbiBh bW9uZyBTZXJ2aWNlIE5vZGVzLg0KPj4+ID4NCj4+PiA+SG93ZXZlciwgSSB0aGluayB0aGF0IHdl IG5lZWQgdG8gYWNrbm93bGVkZ2UgdGhhdCBtYW55IG9mIHRvZGF5J3MNCj4+PiBTZXJ2aWNlDQo+ Pj4gPk5vZGVzLCBlLmcuIEZXLCBMQiwgZXRjLCBlc3BlY2lhbGx5IHRoZSBvbmVzIHRoYXQgYXJl IG9uZSBsaW5rIGF3YXkNCj4+PiBmcm9tDQo+Pj4gPkZvcndhcmRpbmcgbm9kZXMsIGRvbid0IGV2 ZW4gdXNlIGFueSBhZGRyZXNzZXMuIElmIHRoZSBGb3J3YXJkaW5nDQo+Pj4gbm9kZXMNCj4+PiA+ aGF2ZSB0aGUgbmVlZGVkIHRyYWZmaWMgY2xhcmlmaWNhdGlvbiBtZWFucywgdGhleSBjYW4gZGly ZWN0IHRoZQ0KPj4+ID5zZWxlY3RpdmUgdHJhZmZpYyB0aGF0IG5lZWQgdGhlICJTZXJ2aWNlIiB0 byB0aGUgc2VydmljZSBub2Rlcy4NCj4+PiA+DQo+Pj4gPkl0IGlzIG5vdCAib25lIHNpemUiIGZp dHMgYWxsIGZvciBhbGwgU2VydmljZSBub2Rlcy4NCj4+PiA+DQo+Pj4gPkxpbmRhDQo+Pj4gPg0K Pj4+ID4NCj4+PiA+DQo+Pj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiA+PiBG cm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYNCj4+PiBPZg0KPj4+ID4+IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0KPj4+ ID4+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDA2LCAyMDEzIDEwOjI2IEFNDQo+Pj4gPj4gVG86 IExpbmRhIER1bmJhcg0KPj4+ID4+IENjOiBuc2NAaWV0Zi5vcmc7IEppbSBHdWljaGFyZCAoamd1 aWNoYXIpOyBNZWxpbmRhIFNob3JlOyBSb24NCj4+PiA+PiBQYXJrZXINCj4+PiA+PiBTdWJqZWN0 OiBSZTogW25zY10gTlNDIFdvcmtpbmcgR3JvdXAgQ2hhcnRlciBQcm9wb3NhbA0KPj4+ID4+DQo+ Pj4gPj4gSGksIExpbmRhLA0KPj4+ID4+DQo+Pj4gPj4gSSBoYXZlIHRvIGFkbWl0IHRoYXQgSSBh bSBhIGJpdCBsb3N0IHdpdGggdGhpcyBjb21tZW50IG9yIGEgY291cGxlDQo+Pj4gb2YNCj4+PiA+ PiBwcmV2aW91cyBvbmVzLiBDb25zZXF1ZW50bHksIEkgd2FudGVkIHRvIHNlbmQgYSAoaG9wZWZ1 bGx5KQ0KPj4+IGNsYXJpZnlpbmcNCj4+PiA+PiBzdW1tYXJ5Lg0KPj4+ID4+DQo+Pj4gPj4gVGhl IGdvYWwgaXMgdG8gc2VuZCBhIHBhY2tldCAob3JpZ2luYWwtcGF5bG9hZCBmcm9tIGEgc2Vydmlj ZQ0KPj4+ID4+IHBlcnNwZWN0aXZlKSB3aXRoIGFkZGVkIHNlcnZpY2UgY29udGV4dCB0byBhIHNl cnZpY2Ugbm9kZS4gVGhpcyBpcw0KPj4+ID4+IGEgdHdvLXN0ZXAgYXBwcm9hY2g6IHdlIGNhbiBj YWxsIHRoZSBzdGVwcyAxLiBzZXJ2aWNlIChpbm5lciksIDIuDQo+Pj4gPj4gdHJhbnNwb3J0Lg0K Pj4+ID4+DQo+Pj4gPj4gQSBzZXJ2aWNlIGNoYWluIGRlZmluZXMgYSBzZXQgb2Ygc2VydmljZXMg YXBwbGllZCB0byBhbiBvcmlnaW5hbA0KPj4+ID4+IHBheWxvYWQuIFRvIHByb3ZpZGUgY2hhaW4g Y29udGV4dCwgc2VydmljZSBwYXRoIGlkLCBjbGFzc2lmaWNhdGlvbg0KPj4+IGluZm8sDQo+Pj4g Pj4gZXRjLiwgYSBzZXJ2aWNlLWxldmVsIGVuY2Fwc3VsYXRpb24vaGVhZGVyIGlzIGFkZGVkLiBU aGlzIHNob3VsZA0KPj4+ID4+IGJlIGVuY2Fwc3VsYXRpbmctbGF5ZXIgKHRyYW5zcG9ydC1sYXll cikgYWdub3N0aWMuIFNlY29uZCwgaW4NCj4+PiA+PiBvcmRlciBnZXQgdGhhdCB0byBhIHNlcnZp Y2Ugbm9kZSwgaXQgZ2V0cyBmdXJ0aGVyIGVuY2Fwc3VsYXRlZCAoaW4NCj4+PiA+PiBJUCwgSVAv R1JFLCBJUC9VRFAsIFZYTEFOLCBNUExTLCBldGMpIGZvciBkZWxpdmVyeS4NCj4+PiA+Pg0KPj4+ ID4+IEJlaW5nIGEgZ3JhcGhpY2FsIHBlcnNvbiwgSSBhbHNvIHJlYWxseSBsaWtlIHdoYXQgU3Vy ZW5kcmEgc2hhcmVkDQo+Pj4gPj4gYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL25zYy9jdXJyZW50L21zZzAwMzEyLmh0bWwNCj4+PiA+Pg0KPj4+ID4+IEhUSCwNCj4+PiA+ Pg0KPj4+ID4+IC0tIENhcmxvcy4NCj4+PiA+Pg0KPj4+ID4+IE9uIFNlcCA2LCAyMDEzLCBhdCAx MDoxNyBBTSwgTGluZGEgRHVuYmFyDQo+Pj4gPj4gPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPg0K Pj4+ID4+ICB3cm90ZToNCj4+PiA+Pg0KPj4+ID4+ID4gUm9uLA0KPj4+ID4+ID4NCj4+PiA+PiA+ IEdyZWF0ISAgSSBhbSBnbGFkIHRvIHNlZSB0aGF0IHdlIGdvIGRvd24gdGhpcyBwYXRoLg0KPj4+ ID4+ID4gV2Ugc2hvdWxkIGFsc28gYWxsb3c6IC9lbmV0L2lwL3VkcCBvciB0Y3AvbnNjLy4uLg0K Pj4+ID4+ID4gaS5lLiBub3QgbmVjZXNzYXJpbHkgaGF2aW5nIGFuIGlubmVyIElQLg0KPj4+ID4+ ID4NCj4+PiA+PiA+IExpbmRhDQo+Pj4gPj4gPg0KPj4+ID4+ID4NCj4+PiA+PiA+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ID4+ID4+IEZyb206IFJvbiBQYXJrZXIgW21haWx0bzpS b25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXQ0KPj4+ID4+ID4+IFNlbnQ6IFRodXJzZGF5 LCBTZXB0ZW1iZXIgMDUsIDIwMTMgNjoxNiBQTQ0KPj4+ID4+ID4+IFRvOiBMaW5kYSBEdW5iYXI7 IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBNZWxpbmRhIFNob3JlOw0KPj4+ID4+ID4+IG5zY0Bp ZXRmLm9yZw0KPj4+ID4+ID4+IFN1YmplY3Q6IFJFOiBbbnNjXSBOU0MgV29ya2luZyBHcm91cCBD aGFydGVyIFByb3Bvc2FsDQo+Pj4gPj4gPj4NCj4+PiA+PiA+PiBIaSwgTGluZGEuDQo+Pj4gPj4g Pj4NCj4+PiA+PiA+PiBBcyBpdCB3YXMgcmVjZW50bHkgZXhwbGFpbmVkIG9uIHRoaXMgdGhyZWFk LCBJIGRvbid0IHRoaW5rIGl0DQo+Pj4gbmVlZHMNCj4+PiA+PiA+PiB0byBiZSBuZWNlc3Nhcnkg dG8gYWx3YXlzIGhhdmUgaXQgaWYgd2UgYXJlIHdpbGxpbmcgdG8gYWxsb3cNCj4+PiA+PiBtdWx0 aXBsZQ0KPj4+ID4+ID4+IG92ZXJhbGwgInRyYW5zcG9ydCIrc2VydmljZSBlbmNhcHN1bGF0aW9u cy4gICBGb3IgZXhhbXBsZToNCj4+PiA+PiA+Pg0KPj4+ID4+ID4+IC9lbmV0L2lwL3VkcC9uc2Mv aXAvdGNwLy4uLg0KPj4+ID4+ID4+IC9lbmV0L2lwL2dyZS9uc2MvaXAvdGNwLy4uLg0KPj4+ID4+ ID4+IC9lbmV0L2xsYy1zbmFwL25zYy9pcC90Y3AvLi4uDQo+Pj4gPj4gPj4gL2VuZXQvbXBscy9u c2MvaXAvdGNwLy4uLg0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4gQXMgbXVjaCBhcyBJIGRvbid0IHRo aW5rIHdlJ2xsIGVuZCB1cCB0aGVyZSwgSSBkbyBmaW5kIGEgc2luZ2xlDQo+Pj4gPj4gPj4gb3Zl cmFsbCB1bml2ZXJzYWwgdHJhbnNmb3JtYXRpb24gdmVyeSBhdHRyYWN0aXZlIGFuZCBhbnkgZmxh dm9yDQo+Pj4gdGhhdA0KPj4+ID4+ID4+IGlzIC97bDJ9L2lwL3h4eC9pcC90Y3Agd291bGQgYmUg dW5pdmVyc2FsbHkgYXBwbGljYWJsZSAtLSBzYW1lDQo+Pj4gPj4gc3VibmV0DQo+Pj4gPj4gPj4g b3IgZGlmZmVyZW50IHN1Ym5ldCwgbDIgc3dpdGNoZXMgYW5kL29yIGwzIHJvdXRlcnMgaW4gYmV0 d2VlbiAsDQo+Pj4gPj4gT3BlbkZsb3cNCj4+PiA+PiA+PiBvciBub3QgT3BlbkZsb3csIE1QTFMg b3Igbm90IE1QTFMsIC4uLiAgICAgVGhlIGFyZ3VtZW50IGFnYWluc3QNCj4+PiB0aGlzDQo+Pj4g Pj4gPj4gd2lsbCBiZSB0aGF0IHRoZSBwYWNrZXRzIGFyZSBiaWdnZXIgdGhhbiB0aGV5IG5lZWQg dG8gYmUgZm9yIHNvbWUNCj4+PiA+PiA+PiBuZXR3b3JrIHRvcG9sb2dpZXMvcHJvdG9jb2xzLiAg IFNpbXBsaWNpdHkgb3IgZWZmaWNpZW5jeT8NCj4+PiA+PiA+Pg0KPj4+ID4+ID4+ICAgUm9uDQo+ Pj4gPj4gPj4NCj4+PiA+PiA+Pg0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+PiA+PiA+PiBGcm9tOiBMaW5kYSBEdW5iYXIgW21haWx0bzpsaW5kYS5k dW5iYXJAaHVhd2VpLmNvbV0NCj4+PiA+PiA+PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDA1 LCAyMDEzIDU6MTkgUE0NCj4+PiA+PiA+PiBUbzogUm9uIFBhcmtlcjsgSmltIEd1aWNoYXJkIChq Z3VpY2hhcik7IE1lbGluZGEgU2hvcmU7DQo+Pj4gbnNjQGlldGYub3JnDQo+Pj4gPj4gPj4gU3Vi amVjdDogUkU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCj4+PiA+ PiA+Pg0KPj4+ID4+ID4+IEkgY2FuIHNlZSB0aGUgbmVlZCBmb3IgdGhpcyAiTlNDIiBoZWFkZXIg aW5zZXJ0ZWQgdG8gdGhlDQo+Pj4gPj4gPj4gcGFja2V0cywNCj4+PiA+PiBhbmQNCj4+PiA+PiA+ PiBvY2Nhc2lvbmFsbHkgbmVlZGluZyBhbiAib3V0ZXItaXAiIGVuY2Fwc3VsYXRpb24gdG8gYnkt cGFzcw0KPj4+ID4+ID4+IG5vZGVzIHRoYXQgY2FuJ3QgcGFyc2UgdGhlICJOU0MiIGhlYWRlci4N Cj4+PiA+PiA+Pg0KPj4+ID4+ID4+IENhbiBzb21lb25lIGV4cGxhaW4gd2h5IGl0IGlzIG5lY2Vz c2FyeSB0byBhbHdheXMgaGF2ZSB0aGUNCj4+PiAib3V0ZXItDQo+Pj4gPj4gaXAiDQo+Pj4gPj4g Pj4gaGVhZGVyPw0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4NCj4+PiA+PiA+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PiA+PiA+Pj4NCj4+PiA+PiA+Pj4gCU91dGVyLWlwL3VkcC9uc2Mv aW5uZXItaXAvdGNwL3BheWxvYWQNCj4+PiA+PiA+Pg0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4NCj4+ PiA+PiA+PiBMaW5kYQ0KPj4+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PiA+PiA+IG5zYyBtYWlsaW5nIGxpc3QNCj4+PiA+PiA+IG5zY0Bp ZXRmLm9yZw0KPj4+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u c2MNCj4+PiA+DQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4gbnNjQGlldGYub3JnDQo+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4NCj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5zYyBtYWlsaW5nIGxpc3QN Cj5uc2NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25z Yw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ bnNjIG1haWxpbmcgbGlzdA0KPm5zY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbnNjDQoNCg== From smkumar@cisco.com Fri Sep 6 09:17: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 5ABF211E82D0 for ; Fri, 6 Sep 2013 09:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.723 X-Spam-Level: X-Spam-Status: No, score=-9.723 tagged_above=-999 required=5 tests=[AWL=-0.877, 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 4Zx2i4eXoLxT for ; Fri, 6 Sep 2013 09:17:26 -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 A91D611E82B1 for ; Fri, 6 Sep 2013 09:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8980; q=dns/txt; s=iport; t=1378484245; x=1379693845; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=g69UU/ww1D6u6QNLGXUQ0FLBgQhBipeI1EzIGNoZlMk=; b=D3Vm2kfqQI9Ru6u11/kCq/2pQ23j1wxM99U59mcmPai4GTiVo8Hz6dz1 SQk+USeXI3D4jnnqAvgsuUBIAlZRIkorS7ATmMJ05TBlKLvXTrVCuAv+q 29jsZCPCynfzQLlwLHZy5WaiyskkdlHTP4jYyZXAZEMfP9oxw+OnzRCn0 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAOb+KVKtJXG8/2dsb2JhbABbgwc1UYMqvisXgQ4WdIIkAQEBBAEBATE6CwwGAQgRBAEBAQQGHQUEJQsUCQgCBAENBQgBh3kMkQmbRAaRLYEjjSCBBgIWGwcGgl06gQADlBuVQIMggXE5 X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="scan'208";a="256540887" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 06 Sep 2013 16:17:18 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r86GHI7x000462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 16:17:18 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.152]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 11:17:17 -0500 From: "Surendra Kumar (smkumar)" To: Linda Dunbar , "Jim Guichard (jguichar)" , "Carlos Pignataro (cpignata)" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAIAAKPeAgAAgwgCAAPvEAIAAEw+AgAADDoD//764AIAARk2A//+RAoA= Date: Fri, 6 Sep 2013 16:17:16 +0000 Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C9211198C3@xmb-aln-x09.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9EAE4@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.84.213] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nsc@ietf.org" , Melinda Shore , Ron Parker Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 16:17:31 -0000 DQoNCk9uIDkvNi8xMyA4OjU0IEFNLCAiTGluZGEgRHVuYmFyIiA8bGluZGEuZHVuYmFyQGh1YXdl aS5jb20+IHdyb3RlOg0KDQo+SmltLCANCj4NCj5XaGF0IGlmICJBIiBhbmQgIkIiIGluIHlvdXIg ZXhhbXBsZSBhcmUgdG9kYXkncyBleGlzdGluZyBub2RlcywgKHRoZXkgYXJlDQo+bm90IGF3YXJl IG9mIE5TQyBoZWFkZXIpIGFuZCB0aGUgdHJhZmZpYyBiZXR3ZWVuICJBIiBhbmQgIkIiIG5lZWRz IGENCj5zZXF1ZW5jZSBvZiBzZXJ2aWNlIGZ1bmN0aW9ucz8NCj4NCj5Tb21lIHNlcnZpY2UgZnVu Y3Rpb25zIGFyZSBvbmUgbGluayBhd2F5IGZyb20gZm9yd2FyZGluZyBub2RlcyAob3INCj5jby1s b2NhdGVkKSwgd2hpY2ggbWF5IG5vdCByZXF1aXJlIGFub3RoZXIgbGF5ZXIgb2YgZW5jYXBzdWxh dGlvbi4NClNLPiBJcyB0cnVlIG9ubHkgaW4gcGh5c2ljYWwgZW52aXJvbm1lbnRzIG5vdCBpbiB2 aXJ0dWFsIG9yIGh5YnJpZC4NCg0KDQpTdXJlbmRyYS4NCj5CdXQgc29tZSBzZXJ2aWNlIGZ1bmN0 aW9ucyBhcmUgYWNjZXNzaWJsZSB2aWEgbXVsdGlwbGUgbm9kZXMsIHRoZW4gdGhlcmUNCj5pcyBu ZWVkIGZvciBhbm90aGVyIGxheWVyIGVuY2Fwc3VsYXRpb24uDQo+DQo+TGluZGENCj4NCj4NCj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+IEppbSBHdWlj aGFyZCAoamd1aWNoYXIpDQo+PiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAwNiwgMjAxMyAxMDo0 MyBBTQ0KPj4gVG86IExpbmRhIER1bmJhcjsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+ PiBDYzogbnNjQGlldGYub3JnOyBNZWxpbmRhIFNob3JlOyBSb24gUGFya2VyDQo+PiBTdWJqZWN0 OiBSZTogW25zY10gTlNDIFdvcmtpbmcgR3JvdXAgQ2hhcnRlciBQcm9wb3NhbA0KPj4gDQo+PiBM aW5kYSwNCj4+IA0KPj4gSSBkb26p9nQgdGhpbmsgYW55b25lIGlzIHNheWluZyB0aGF0IHlvdSB1 c2Ugb3V0ZXIgdHJhbnNwb3J0IGxheWVyIGZvcg0KPj4gcGFzc2luZyBpbmZvcm1hdGlvbiBhbW9u ZyBzZXJ2aWNlIG5vZGVzOyB0byB0aGUgY29udHJhcnksIHRoZSBvdXRlcg0KPj4gdHJhbnNwb3J0 IGxheWVyIGlzIHNpbXBseSB1c2VkIHRvIGdldCBwYWNrZXRzIGZyb20gcG9pbnQgQSB0byBwb2lu dCBCDQo+PiBhbmQNCj4+ICpub3RoaW5nKiBtb3JlLiBJZiBwb2ludCBCIGhhcHBlbnMgdG8gYmUg YSBzZXJ2aWNlIG5vZGUgdGhhdCBpcyBhY3RpbmcNCj4+IG9uDQo+PiBiZWhhbGYgb2YgYW4gYXR0 YWNoZWQgc2VydmljZSBmdW5jdGlvbiB0aGVuIHBvaW50IEIgbWF5IHVzZSB0aGUNCj4+IHNlcnZp Y2UtZW5jYXBzdWxhdGlvbiB0byBmaWd1cmUgb3V0IGhvdyB0byBmb3J3YXJkIHRoZSBwYWNrZXQg dG8gdGhlDQo+PiByaWdodA0KPj4gc2VydmljZSBmdW5jdGlvbi4NCj4+IA0KPj4gT24gOS82LzEz IDExOjM2IEFNLCAiTGluZGEgRHVuYmFyIiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3Rl Og0KPj4gDQo+PiA+Q2FybG9zLA0KPj4gPg0KPj4gPkkgYWdyZWUgdGhhdCB5b3UgaGF2ZSB0byB1 c2UgT3V0ZXIgVHJhbnNwb3J0IExheWVyIHRvIHBhc3MgaW5mb3JtYXRpb24NCj4+ID5hbW9uZyBT ZXJ2aWNlIE5vZGVzLg0KPj4gPg0KPj4gPkhvd2V2ZXIsIEkgdGhpbmsgdGhhdCB3ZSBuZWVkIHRv IGFja25vd2xlZGdlIHRoYXQgbWFueSBvZiB0b2RheSdzDQo+PiBTZXJ2aWNlDQo+PiA+Tm9kZXMs IGUuZy4gRlcsIExCLCBldGMsIGVzcGVjaWFsbHkgdGhlIG9uZXMgdGhhdCBhcmUgb25lIGxpbmsg YXdheQ0KPj4gZnJvbQ0KPj4gPkZvcndhcmRpbmcgbm9kZXMsIGRvbid0IGV2ZW4gdXNlIGFueSBh ZGRyZXNzZXMuIElmIHRoZSBGb3J3YXJkaW5nDQo+PiBub2Rlcw0KPj4gPmhhdmUgdGhlIG5lZWRl ZCB0cmFmZmljIGNsYXJpZmljYXRpb24gbWVhbnMsIHRoZXkgY2FuIGRpcmVjdCB0aGUNCj4+ID5z ZWxlY3RpdmUgdHJhZmZpYyB0aGF0IG5lZWQgdGhlICJTZXJ2aWNlIiB0byB0aGUgc2VydmljZSBu b2Rlcy4NCj4+ID4NCj4+ID5JdCBpcyBub3QgIm9uZSBzaXplIiBmaXRzIGFsbCBmb3IgYWxsIFNl cnZpY2Ugbm9kZXMuDQo+PiA+DQo+PiA+TGluZGENCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+IE9mDQo+PiA+PiBD YXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNCj4+ID4+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVy IDA2LCAyMDEzIDEwOjI2IEFNDQo+PiA+PiBUbzogTGluZGEgRHVuYmFyDQo+PiA+PiBDYzogbnNj QGlldGYub3JnOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTWVsaW5kYSBTaG9yZTsgUm9uIFBh cmtlcg0KPj4gPj4gU3ViamVjdDogUmU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIg UHJvcG9zYWwNCj4+ID4+DQo+PiA+PiBIaSwgTGluZGEsDQo+PiA+Pg0KPj4gPj4gSSBoYXZlIHRv IGFkbWl0IHRoYXQgSSBhbSBhIGJpdCBsb3N0IHdpdGggdGhpcyBjb21tZW50IG9yIGEgY291cGxl DQo+PiBvZg0KPj4gPj4gcHJldmlvdXMgb25lcy4gQ29uc2VxdWVudGx5LCBJIHdhbnRlZCB0byBz ZW5kIGEgKGhvcGVmdWxseSkNCj4+IGNsYXJpZnlpbmcNCj4+ID4+IHN1bW1hcnkuDQo+PiA+Pg0K Pj4gPj4gVGhlIGdvYWwgaXMgdG8gc2VuZCBhIHBhY2tldCAob3JpZ2luYWwtcGF5bG9hZCBmcm9t IGEgc2VydmljZQ0KPj4gPj4gcGVyc3BlY3RpdmUpIHdpdGggYWRkZWQgc2VydmljZSBjb250ZXh0 IHRvIGEgc2VydmljZSBub2RlLiBUaGlzIGlzIGENCj4+ID4+IHR3by1zdGVwIGFwcHJvYWNoOiB3 ZSBjYW4gY2FsbCB0aGUgc3RlcHMgMS4gc2VydmljZSAoaW5uZXIpLCAyLg0KPj4gPj4gdHJhbnNw b3J0Lg0KPj4gPj4NCj4+ID4+IEEgc2VydmljZSBjaGFpbiBkZWZpbmVzIGEgc2V0IG9mIHNlcnZp Y2VzIGFwcGxpZWQgdG8gYW4gb3JpZ2luYWwNCj4+ID4+IHBheWxvYWQuIFRvIHByb3ZpZGUgY2hh aW4gY29udGV4dCwgc2VydmljZSBwYXRoIGlkLCBjbGFzc2lmaWNhdGlvbg0KPj4gaW5mbywNCj4+ ID4+IGV0Yy4sIGEgc2VydmljZS1sZXZlbCBlbmNhcHN1bGF0aW9uL2hlYWRlciBpcyBhZGRlZC4g VGhpcyBzaG91bGQgYmUNCj4+ID4+IGVuY2Fwc3VsYXRpbmctbGF5ZXIgKHRyYW5zcG9ydC1sYXll cikgYWdub3N0aWMuIFNlY29uZCwgaW4gb3JkZXIgZ2V0DQo+PiA+PiB0aGF0IHRvIGEgc2Vydmlj ZSBub2RlLCBpdCBnZXRzIGZ1cnRoZXIgZW5jYXBzdWxhdGVkIChpbiBJUCwgSVAvR1JFLA0KPj4g Pj4gSVAvVURQLCBWWExBTiwgTVBMUywgZXRjKSBmb3IgZGVsaXZlcnkuDQo+PiA+Pg0KPj4gPj4g QmVpbmcgYSBncmFwaGljYWwgcGVyc29uLCBJIGFsc28gcmVhbGx5IGxpa2Ugd2hhdCBTdXJlbmRy YSBzaGFyZWQgYXQNCj4+ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9u c2MvY3VycmVudC9tc2cwMDMxMi5odG1sDQo+PiA+Pg0KPj4gPj4gSFRILA0KPj4gPj4NCj4+ID4+ IC0tIENhcmxvcy4NCj4+ID4+DQo+PiA+PiBPbiBTZXAgNiwgMjAxMywgYXQgMTA6MTcgQU0sIExp bmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+DQo+PiA+PiAgd3JvdGU6DQo+PiA+ Pg0KPj4gPj4gPiBSb24sDQo+PiA+PiA+DQo+PiA+PiA+IEdyZWF0ISAgSSBhbSBnbGFkIHRvIHNl ZSB0aGF0IHdlIGdvIGRvd24gdGhpcyBwYXRoLg0KPj4gPj4gPiBXZSBzaG91bGQgYWxzbyBhbGxv dzogL2VuZXQvaXAvdWRwIG9yIHRjcC9uc2MvLi4uDQo+PiA+PiA+IGkuZS4gbm90IG5lY2Vzc2Fy aWx5IGhhdmluZyBhbiBpbm5lciBJUC4NCj4+ID4+ID4NCj4+ID4+ID4gTGluZGENCj4+ID4+ID4N Cj4+ID4+ID4NCj4+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+PiBG cm9tOiBSb24gUGFya2VyIFttYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0N Cj4+ID4+ID4+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDUsIDIwMTMgNjoxNiBQTQ0KPj4g Pj4gPj4gVG86IExpbmRhIER1bmJhcjsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IE1lbGluZGEg U2hvcmU7DQo+PiA+PiA+PiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4+IFN1YmplY3Q6IFJFOiBbbnNj XSBOU0MgV29ya2luZyBHcm91cCBDaGFydGVyIFByb3Bvc2FsDQo+PiA+PiA+Pg0KPj4gPj4gPj4g SGksIExpbmRhLg0KPj4gPj4gPj4NCj4+ID4+ID4+IEFzIGl0IHdhcyByZWNlbnRseSBleHBsYWlu ZWQgb24gdGhpcyB0aHJlYWQsIEkgZG9uJ3QgdGhpbmsgaXQNCj4+IG5lZWRzDQo+PiA+PiA+PiB0 byBiZSBuZWNlc3NhcnkgdG8gYWx3YXlzIGhhdmUgaXQgaWYgd2UgYXJlIHdpbGxpbmcgdG8gYWxs b3cNCj4+ID4+IG11bHRpcGxlDQo+PiA+PiA+PiBvdmVyYWxsICJ0cmFuc3BvcnQiK3NlcnZpY2Ug ZW5jYXBzdWxhdGlvbnMuICAgRm9yIGV4YW1wbGU6DQo+PiA+PiA+Pg0KPj4gPj4gPj4gL2VuZXQv aXAvdWRwL25zYy9pcC90Y3AvLi4uDQo+PiA+PiA+PiAvZW5ldC9pcC9ncmUvbnNjL2lwL3RjcC8u Li4NCj4+ID4+ID4+IC9lbmV0L2xsYy1zbmFwL25zYy9pcC90Y3AvLi4uDQo+PiA+PiA+PiAvZW5l dC9tcGxzL25zYy9pcC90Y3AvLi4uDQo+PiA+PiA+Pg0KPj4gPj4gPj4gQXMgbXVjaCBhcyBJIGRv bid0IHRoaW5rIHdlJ2xsIGVuZCB1cCB0aGVyZSwgSSBkbyBmaW5kIGEgc2luZ2xlDQo+PiA+PiA+ PiBvdmVyYWxsIHVuaXZlcnNhbCB0cmFuc2Zvcm1hdGlvbiB2ZXJ5IGF0dHJhY3RpdmUgYW5kIGFu eSBmbGF2b3INCj4+IHRoYXQNCj4+ID4+ID4+IGlzIC97bDJ9L2lwL3h4eC9pcC90Y3Agd291bGQg YmUgdW5pdmVyc2FsbHkgYXBwbGljYWJsZSAtLSBzYW1lDQo+PiA+PiBzdWJuZXQNCj4+ID4+ID4+ IG9yIGRpZmZlcmVudCBzdWJuZXQsIGwyIHN3aXRjaGVzIGFuZC9vciBsMyByb3V0ZXJzIGluIGJl dHdlZW4gLA0KPj4gPj4gT3BlbkZsb3cNCj4+ID4+ID4+IG9yIG5vdCBPcGVuRmxvdywgTVBMUyBv ciBub3QgTVBMUywgLi4uICAgICBUaGUgYXJndW1lbnQgYWdhaW5zdA0KPj4gdGhpcw0KPj4gPj4g Pj4gd2lsbCBiZSB0aGF0IHRoZSBwYWNrZXRzIGFyZSBiaWdnZXIgdGhhbiB0aGV5IG5lZWQgdG8g YmUgZm9yIHNvbWUNCj4+ID4+ID4+IG5ldHdvcmsgdG9wb2xvZ2llcy9wcm90b2NvbHMuICAgU2lt cGxpY2l0eSBvciBlZmZpY2llbmN5Pw0KPj4gPj4gPj4NCj4+ID4+ID4+ICAgUm9uDQo+PiA+PiA+ Pg0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4gPj4gPj4gRnJvbTogTGluZGEgRHVuYmFyIFttYWlsdG86bGluZGEuZHVuYmFyQGh1YXdl aS5jb21dDQo+PiA+PiA+PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDA1LCAyMDEzIDU6MTkg UE0NCj4+ID4+ID4+IFRvOiBSb24gUGFya2VyOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTWVs aW5kYSBTaG9yZTsNCj4+IG5zY0BpZXRmLm9yZw0KPj4gPj4gPj4gU3ViamVjdDogUkU6IFtuc2Nd IE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCj4+ID4+ID4+DQo+PiA+PiA+PiBJ IGNhbiBzZWUgdGhlIG5lZWQgZm9yIHRoaXMgIk5TQyIgaGVhZGVyIGluc2VydGVkIHRvIHRoZSBw YWNrZXRzLA0KPj4gPj4gYW5kDQo+PiA+PiA+PiBvY2Nhc2lvbmFsbHkgbmVlZGluZyBhbiAib3V0 ZXItaXAiIGVuY2Fwc3VsYXRpb24gdG8gYnktcGFzcyBub2Rlcw0KPj4gPj4gPj4gdGhhdCBjYW4n dCBwYXJzZSB0aGUgIk5TQyIgaGVhZGVyLg0KPj4gPj4gPj4NCj4+ID4+ID4+IENhbiBzb21lb25l IGV4cGxhaW4gd2h5IGl0IGlzIG5lY2Vzc2FyeSB0byBhbHdheXMgaGF2ZSB0aGUNCj4+ICJvdXRl ci0NCj4+ID4+IGlwIg0KPj4gPj4gPj4gaGVhZGVyPw0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+ PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4+Pg0KPj4gPj4gPj4+IAlP dXRlci1pcC91ZHAvbnNjL2lubmVyLWlwL3RjcC9wYXlsb2FkDQo+PiA+PiA+Pg0KPj4gPj4gPj4N Cj4+ID4+ID4+DQo+PiA+PiA+PiBMaW5kYQ0KPj4gPj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPiBuc2MgbWFpbGluZyBsaXN0DQo+PiA+ PiA+IG5zY0BpZXRmLm9yZw0KPj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25zYw0KPj4gPg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gbnNjIG1haWxpbmcgbGlzdA0KPj4gbnNjQGlldGYub3JnDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bnNjIG1haWxpbmcgbGlzdA0K Pm5zY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNj DQoNCg== From linda.dunbar@huawei.com Fri Sep 6 09:21: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 0D91221E8063 for ; Fri, 6 Sep 2013 09:21:38 -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, 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 h-q0rdSBZbWr for ; Fri, 6 Sep 2013 09:21:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 61D4A21E80B8 for ; Fri, 6 Sep 2013 09:21:19 -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.5-GA FastPath queued) with ESMTP id AWZ00916; Fri, 06 Sep 2013 16:21:18 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 17:20:55 +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.146.0; Fri, 6 Sep 2013 17:21:15 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Fri, 6 Sep 2013 09:21:11 -0700 From: Linda Dunbar To: Jerome Moisand , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAJ5aAP//lE3ggAB58wD//5m/sIAAGcwQgAAwdeCAAP1hUIAAiQiA//+L0XAADyDKAAAOd6ew//+QLYCAAAEaAIAAcMYw Date: Fri, 6 Sep 2013 16:21:10 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9EB9A@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645B9EAE4@dfweml509-mbx.china.huawei.com> <68B171751455884590F8E38E96416F363F67897A@xmb-rcd-x01.cisco.com> <6c93fdea00d64a949b31ff6feb647cd7@BN1PR05MB251.namprd05.prod.outlook.com> In-Reply-To: <6c93fdea00d64a949b31ff6feb647cd7@BN1PR05MB251.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.59] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 16:21:38 -0000 The discussion is about using "A Single Encapsulation.." in the Charter.=20 Even though it is ideal and everyone (myself included) loves it, but I am a= fraid that not every Service Chain case will need outer encapsulation.=20 Linda > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Jerome Moisand > Sent: Friday, September 06, 2013 11:01 AM > To: nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal >=20 > Guys, could we please keep this discussion for later? We're supposed to > discuss a charter here. Not a specific solution. >=20 > Fair enough? >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Jim Guichard (jguichar) > Sent: Friday, September 06, 2013 11:57 AM > To: Linda Dunbar; Carlos Pignataro (cpignata) > Cc: nsc@ietf.org; Melinda Shore; Ron Parker > Subject: Re: [nsc] NSC Working Group Charter Proposal >=20 > Then use routing. >=20 > On 9/6/13 11:54 AM, "Linda Dunbar" wrote: >=20 > >Jim, > > > >What if "A" and "B" in your example are today's existing nodes, (they > >are not aware of NSC header) and the traffic between "A" and "B" needs > >a sequence of service functions? > > > >Some service functions are one link away from forwarding nodes (or > >co-located), which may not require another layer of encapsulation. But > >some service functions are accessible via multiple nodes, then there > is > >need for another layer encapsulation. > > > >Linda > > > > > >> -----Original Message----- > >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > >> Jim Guichard (jguichar) > >> Sent: Friday, September 06, 2013 10:43 AM > >> To: Linda Dunbar; Carlos Pignataro (cpignata) > >> Cc: nsc@ietf.org; Melinda Shore; Ron Parker > >> Subject: Re: [nsc] NSC Working Group Charter Proposal > >> > >> Linda, > >> > >> I don=B9t think anyone is saying that you use outer transport layer > for > >> passing information among service nodes; to the contrary, the outer > >> transport layer is simply used to get packets from point A to point > B > >> and > >> *nothing* more. If point B happens to be a service node that is > >> acting on behalf of an attached service function then point B may > use > >> the service-encapsulation to figure out how to forward the packet to > >> the right service function. > >> > >> On 9/6/13 11:36 AM, "Linda Dunbar" wrote: > >> > >> >Carlos, > >> > > >> >I agree that you have to use Outer Transport Layer to pass > >> >information among Service Nodes. > >> > > >> >However, I think that we need to acknowledge that many of today's > >> Service > >> >Nodes, e.g. FW, LB, etc, especially the ones that are one link away > >> from > >> >Forwarding nodes, don't even use any addresses. If the Forwarding > >> nodes > >> >have the needed traffic clarification means, they can direct the > >> >selective traffic that need the "Service" to the service nodes. > >> > > >> >It is not "one size" fits all for all Service nodes. > >> > > >> >Linda > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > Behalf > >> Of > >> >> Carlos Pignataro (cpignata) > >> >> Sent: Friday, September 06, 2013 10:26 AM > >> >> To: Linda Dunbar > >> >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore; Ron > >> >> Parker > >> >> Subject: Re: [nsc] NSC Working Group Charter Proposal > >> >> > >> >> Hi, Linda, > >> >> > >> >> I have to admit that I am a bit lost with this comment or a > couple > >> of > >> >> previous ones. Consequently, I wanted to send a (hopefully) > >> clarifying > >> >> summary. > >> >> > >> >> The goal is to send a packet (original-payload from a service > >> >> perspective) with added service context to a service node. This > is > >> >> a two-step approach: we can call the steps 1. service (inner), 2. > >> >> transport. > >> >> > >> >> A service chain defines a set of services applied to an original > >> >> payload. To provide chain context, service path id, > classification > >> info, > >> >> etc., a service-level encapsulation/header is added. This should > >> >> be encapsulating-layer (transport-layer) agnostic. Second, in > >> >> order get that to a service node, it gets further encapsulated > (in > >> >> IP, IP/GRE, IP/UDP, VXLAN, MPLS, etc) for delivery. > >> >> > >> >> Being a graphical person, I also really like what Surendra shared > >> >> at http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html > >> >> > >> >> HTH, > >> >> > >> >> -- Carlos. > >> >> > >> >> On Sep 6, 2013, at 10:17 AM, Linda Dunbar > >> >> > >> >> wrote: > >> >> > >> >> > Ron, > >> >> > > >> >> > Great! I am glad to see that we go down this path. > >> >> > We should also allow: /enet/ip/udp or tcp/nsc/... > >> >> > i.e. not necessarily having an inner IP. > >> >> > > >> >> > Linda > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> >> >> Sent: Thursday, September 05, 2013 6:16 PM > >> >> >> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; > >> >> >> nsc@ietf.org > >> >> >> Subject: RE: [nsc] NSC Working Group Charter Proposal > >> >> >> > >> >> >> Hi, Linda. > >> >> >> > >> >> >> As it was recently explained on this thread, I don't think it > >> needs > >> >> >> to be necessary to always have it if we are willing to allow > >> >> multiple > >> >> >> overall "transport"+service encapsulations. For example: > >> >> >> > >> >> >> /enet/ip/udp/nsc/ip/tcp/... > >> >> >> /enet/ip/gre/nsc/ip/tcp/... > >> >> >> /enet/llc-snap/nsc/ip/tcp/... > >> >> >> /enet/mpls/nsc/ip/tcp/... > >> >> >> > >> >> >> As much as I don't think we'll end up there, I do find a > single > >> >> >> overall universal transformation very attractive and any > flavor > >> that > >> >> >> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same > >> >> subnet > >> >> >> or different subnet, l2 switches and/or l3 routers in between , > >> >> OpenFlow > >> >> >> or not OpenFlow, MPLS or not MPLS, ... The argument > against > >> this > >> >> >> will be that the packets are bigger than they need to be for > some > >> >> >> network topologies/protocols. Simplicity or efficiency? > >> >> >> > >> >> >> Ron > >> >> >> > >> >> >> > >> >> >> > >> >> >> -----Original Message----- > >> >> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > >> >> >> Sent: Thursday, September 05, 2013 5:19 PM > >> >> >> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; > >> nsc@ietf.org > >> >> >> Subject: RE: [nsc] NSC Working Group Charter Proposal > >> >> >> > >> >> >> I can see the need for this "NSC" header inserted to the > >> >> >> packets, > >> >> and > >> >> >> occasionally needing an "outer-ip" encapsulation to by-pass > >> >> >> nodes that can't parse the "NSC" header. > >> >> >> > >> >> >> Can someone explain why it is necessary to always have the > >> "outer- > >> >> ip" > >> >> >> header? > >> >> >> > >> >> >> > >> >> >>> -----Original Message----- > >> >> >>> > >> >> >>> Outer-ip/udp/nsc/inner-ip/tcp/payload > >> >> >> > >> >> >> > >> >> >> > >> >> >> 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 >=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 jmh@joelhalpern.com Fri Sep 6 09:29:34 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 CD46921E80BB for ; Fri, 6 Sep 2013 09:29:33 -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 s-s64LjStKvc for ; Fri, 6 Sep 2013 09:29:29 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 8B11821F9D5C for ; Fri, 6 Sep 2013 09:29:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 36EAD1BDC73F; Fri, 6 Sep 2013 09:29:25 -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 D75771BDC704; Fri, 6 Sep 2013 09:29:22 -0700 (PDT) Message-ID: <522A02E5.4080800@joelhalpern.com> Date: Fri, 06 Sep 2013 12:29:25 -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: "Carlos Pignataro (cpignata)" References: <68B171751455884590F8E38E96416F363F6788C8@xmb-rcd-x01.cisco.com> <95067C434CE250468B77282634C96ED325EFE166@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED325EFE166@xmb-aln-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore , Ron Parker , Linda Dunbar Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 16:29:34 -0000 I am somewhat confused between the musts and the mays. I do think that there are circumstances where the outer ("transport" header can carry and use with existing forwarding information that identifies / directs the service chaining. I equally agree that we don't need to mandate that. And I have little problem duplicating any such information in a consistent a reusable intermediate encapsulation header so that it can be handled in other ways. Yours, Joel On 9/6/13 11:46 AM, Carlos Pignataro (cpignata) wrote: > Linda, > > What Jim said. > > I was not saying this: >> Carlos, >> > >> I agree that you have to use Outer Transport Layer to pass information >> among Service Nodes. > > -- Carlos. > > > On Sep 6, 2013, at 11:42 AM, "Jim Guichard (jguichar)" > wrote: > >> Linda, >> >> I don¹t think anyone is saying that you use outer transport layer for >> passing information among service nodes; to the contrary, the outer >> transport layer is simply used to get packets from point A to point B and >> *nothing* more. If point B happens to be a service node that is acting on >> behalf of an attached service function then point B may use the >> service-encapsulation to figure out how to forward the packet to the right >> service function. >> >> On 9/6/13 11:36 AM, "Linda Dunbar" wrote: >> >>> Carlos, >>> >>> I agree that you have to use Outer Transport Layer to pass information >>> among Service Nodes. >>> >>> However, I think that we need to acknowledge that many of today's Service >>> Nodes, e.g. FW, LB, etc, especially the ones that are one link away from >>> Forwarding nodes, don't even use any addresses. If the Forwarding nodes >>> have the needed traffic clarification means, they can direct the >>> selective traffic that need the "Service" to the service nodes. >>> >>> It is not "one size" fits all for all Service nodes. >>> >>> Linda >>> >>> >>> >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>>> Carlos Pignataro (cpignata) >>>> Sent: Friday, September 06, 2013 10:26 AM >>>> To: Linda Dunbar >>>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore; Ron Parker >>>> Subject: Re: [nsc] NSC Working Group Charter Proposal >>>> >>>> Hi, Linda, >>>> >>>> I have to admit that I am a bit lost with this comment or a couple of >>>> previous ones. Consequently, I wanted to send a (hopefully) clarifying >>>> summary. >>>> >>>> The goal is to send a packet (original-payload from a service >>>> perspective) with added service context to a service node. This is a >>>> two-step approach: we can call the steps 1. service (inner), 2. >>>> transport. >>>> >>>> A service chain defines a set of services applied to an original >>>> payload. To provide chain context, service path id, classification info, >>>> etc., a service-level encapsulation/header is added. This should be >>>> encapsulating-layer (transport-layer) agnostic. Second, in order get >>>> that to a service node, it gets further encapsulated (in IP, IP/GRE, >>>> IP/UDP, VXLAN, MPLS, etc) for delivery. >>>> >>>> Being a graphical person, I also really like what Surendra shared at >>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html >>>> >>>> HTH, >>>> >>>> -- Carlos. >>>> >>>> On Sep 6, 2013, at 10:17 AM, Linda Dunbar >>>> wrote: >>>> >>>>> Ron, >>>>> >>>>> Great! I am glad to see that we go down this path. >>>>> We should also allow: /enet/ip/udp or tcp/nsc/... >>>>> i.e. not necessarily having an inner IP. >>>>> >>>>> Linda >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>> Sent: Thursday, September 05, 2013 6:16 PM >>>>>> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; >>>>>> nsc@ietf.org >>>>>> Subject: RE: [nsc] NSC Working Group Charter Proposal >>>>>> >>>>>> Hi, Linda. >>>>>> >>>>>> As it was recently explained on this thread, I don't think it needs >>>>>> to be necessary to always have it if we are willing to allow >>>> multiple >>>>>> overall "transport"+service encapsulations. For example: >>>>>> >>>>>> /enet/ip/udp/nsc/ip/tcp/... >>>>>> /enet/ip/gre/nsc/ip/tcp/... >>>>>> /enet/llc-snap/nsc/ip/tcp/... >>>>>> /enet/mpls/nsc/ip/tcp/... >>>>>> >>>>>> As much as I don't think we'll end up there, I do find a single >>>>>> overall universal transformation very attractive and any flavor that >>>>>> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same >>>> subnet >>>>>> or different subnet, l2 switches and/or l3 routers in between , >>>> OpenFlow >>>>>> or not OpenFlow, MPLS or not MPLS, ... The argument against this >>>>>> will be that the packets are bigger than they need to be for some >>>>>> network topologies/protocols. Simplicity or efficiency? >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>>>> Sent: Thursday, September 05, 2013 5:19 PM >>>>>> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org >>>>>> Subject: RE: [nsc] NSC Working Group Charter Proposal >>>>>> >>>>>> I can see the need for this "NSC" header inserted to the packets, >>>> and >>>>>> occasionally needing an "outer-ip" encapsulation to by-pass nodes >>>>>> that can't parse the "NSC" header. >>>>>> >>>>>> Can someone explain why it is necessary to always have the "outer- >>>> ip" >>>>>> header? >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> >>>>>>> Outer-ip/udp/nsc/inner-ip/tcp/payload >>>>>> >>>>>> >>>>>> >>>>>> 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 kgray@juniper.net Fri Sep 6 09:29:43 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D9E21E80C7 for ; Fri, 6 Sep 2013 09:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.368 X-Spam-Level: X-Spam-Status: No, score=-4.368 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 qf5bb1Xg4vcX for ; Fri, 6 Sep 2013 09:29:34 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id BBC0411E81A7 for ; Fri, 6 Sep 2013 09:29:30 -0700 (PDT) Received: from mail192-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.22; Fri, 6 Sep 2013 16:29:29 +0000 Received: from mail192-tx2 (localhost [127.0.0.1]) by mail192-tx2-R.bigfish.com (Postfix) with ESMTP id DE3BD201D5 for ; Fri, 6 Sep 2013 16:29:29 +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(zzbb2dI98dI9371Ic89bh542I1432I1418Idb82h853kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h942he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail192-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(51704005)(377454003)(189002)(199002)(24454002)(51444003)(13464003)(19580395003)(65816001)(19580405001)(83322001)(46102001)(51856001)(47976001)(80022001)(47736001)(4396001)(69226001)(49866001)(81342001)(50986001)(47446002)(74502001)(561944002)(74662001)(63696002)(31966008)(74366001)(1941001)(74706001)(80976001)(15975445006)(76796001)(76176001)(36756003)(76786001)(83072001)(81542001)(15202345003)(59766001)(56776001)(77982001)(54316002)(83506001)(81816001)(77096001)(56816003)(74876001)(54356001)(79102001)(53806001)(76482001)(81686001)(21314002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB244; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail192-tx2 (localhost.localdomain [127.0.0.1]) by mail192-tx2 (MessageSwitch) id 1378484967908174_20177; Fri, 6 Sep 2013 16:29:27 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.235]) by mail192-tx2.bigfish.com (Postfix) with ESMTP id CFE762A004D for ; Fri, 6 Sep 2013 16:29:27 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 6 Sep 2013 16:29:24 +0000 Received: from BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.353.4; Fri, 6 Sep 2013 16:29:24 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 6 Sep 2013 16:29:23 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.191]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.191]) with mapi id 15.00.0745.000; Fri, 6 Sep 2013 16:29:22 +0000 From: Ken Gray To: Jerome Moisand , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAACkCAIAADRKAgAABLQCAABHdAIAAKPeAgAAgwwCAAPvDAIAAEw+AgAADD4CAAAHIAIAAAz2AgAAAroCAAAEaAP//xOCA Date: Fri, 6 Sep 2013 16:29:22 +0000 Message-ID: In-Reply-To: <6c93fdea00d64a949b31ff6feb647cd7@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.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 0961DF5286 Content-Type: text/plain; charset="euc-kr" Content-ID: <64D985F43C11C34EA2E50C182BAF21A2@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 16:29:44 -0000 KzEgDQoNClRoZXJlIGFyZSBkb2N1bWVudHMgZXh0YW50IG9uIHRoZSBvdGhlciB0b3BpY3MgYW5k IGEgdGltZSB3aWxsIGNvbWUgdG8NCmNvbW1lbnQgb24gdGhlbS4gIExldCdzIGRvIHRoZSBkYXJu IGNoYXJ0ZXIgZmlyc3QuICBXZSdyZSBwb2xsdXRpbmcgdGhlDQpzdWJqZWN0IGxpbmUuDQoNCkxp bmRhLCB0aGUgc2VudGVuY2UgaXMgIkEgc2luZ2xlIGVuY2Fwc3VsYXRpb24gd2lsbCBiZSBzZWxl Y3RlZCBpbiBvcmRlcg0KdG8gZW5hYmxlIGludGVyb3BlcmFiaWxpdHkgb2YgZGF0YSBwbGFuZSBj b21wb25lbnRzLiIgIEl0IGhhcyBBTFJFQURZIGJlZW4NCm5vdGVkIHRoYXQgdmFyaW91cyBjb21w b25lbnRzIG9mIGFuIG92ZXJhbGwgZW5jYXBzdWxhdGlvbiB3aWxsIG9yIHdvbid0IGJlDQp1c2Vk IGFzIGFwcHJvcHJpYXRlLiAgRm9yIGFuIGFic3RyYWN0IHN0YXRlbWVudCwgSSBkb24ndCB0aGlu ayBKaW0gY2FuIGdldA0KbW9yZSB2YWd1ZS4NCg0KTW9yZSBjaGFydGVyIGNvbW1lbnRzLCBhbnlv bmU/DQoNCk9uIDkvNi8xMyAxMjowMCBQTSwgIkplcm9tZSBNb2lzYW5kIiA8am1vaXNhbmRAanVu aXBlci5uZXQ+IHdyb3RlOg0KDQo+R3V5cywgY291bGQgd2UgcGxlYXNlIGtlZXAgdGhpcyBkaXNj dXNzaW9uIGZvciBsYXRlcj8gV2UncmUgc3VwcG9zZWQgdG8NCj5kaXNjdXNzIGEgY2hhcnRlciBo ZXJlLiBOb3QgYSBzcGVjaWZpYyBzb2x1dGlvbi4NCj4NCj5GYWlyIGVub3VnaD8NCj4NCj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0NCj5HdWljaGFyZCAoamd1 aWNoYXIpDQo+U2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMDYsIDIwMTMgMTE6NTcgQU0NCj5Ubzog TGluZGEgRHVuYmFyOyBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNCj5DYzogbnNjQGlldGYu b3JnOyBNZWxpbmRhIFNob3JlOyBSb24gUGFya2VyDQo+U3ViamVjdDogUmU6IFtuc2NdIE5TQyBX b3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCj4NCj5UaGVuIHVzZSByb3V0aW5nLg0KPg0K Pk9uIDkvNi8xMyAxMTo1NCBBTSwgIkxpbmRhIER1bmJhciIgPGxpbmRhLmR1bmJhckBodWF3ZWku Y29tPiB3cm90ZToNCj4NCj4+SmltLA0KPj4NCj4+V2hhdCBpZiAiQSIgYW5kICJCIiBpbiB5b3Vy IGV4YW1wbGUgYXJlIHRvZGF5J3MgZXhpc3Rpbmcgbm9kZXMsICh0aGV5DQo+PmFyZSBub3QgYXdh cmUgb2YgTlNDIGhlYWRlcikgYW5kIHRoZSB0cmFmZmljIGJldHdlZW4gIkEiIGFuZCAiQiIgbmVl ZHMNCj4+YSBzZXF1ZW5jZSBvZiBzZXJ2aWNlIGZ1bmN0aW9ucz8NCj4+DQo+PlNvbWUgc2Vydmlj ZSBmdW5jdGlvbnMgYXJlIG9uZSBsaW5rIGF3YXkgZnJvbSBmb3J3YXJkaW5nIG5vZGVzIChvcg0K Pj5jby1sb2NhdGVkKSwgd2hpY2ggbWF5IG5vdCByZXF1aXJlIGFub3RoZXIgbGF5ZXIgb2YgZW5j YXBzdWxhdGlvbi4gQnV0DQo+PnNvbWUgc2VydmljZSBmdW5jdGlvbnMgYXJlIGFjY2Vzc2libGUg dmlhIG11bHRpcGxlIG5vZGVzLCB0aGVuIHRoZXJlIGlzDQo+Pm5lZWQgZm9yIGFub3RoZXIgbGF5 ZXIgZW5jYXBzdWxhdGlvbi4NCj4+DQo+PkxpbmRhDQo+Pg0KPj4NCj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4+IEppbSBHdWljaGFyZCAoamd1aWNo YXIpDQo+Pj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMDYsIDIwMTMgMTA6NDMgQU0NCj4+PiBU bzogTGluZGEgRHVuYmFyOyBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNCj4+PiBDYzogbnNj QGlldGYub3JnOyBNZWxpbmRhIFNob3JlOyBSb24gUGFya2VyDQo+Pj4gU3ViamVjdDogUmU6IFtu c2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCj4+PiANCj4+PiBMaW5kYSwN Cj4+PiANCj4+PiBJIGRvbqn2dCB0aGluayBhbnlvbmUgaXMgc2F5aW5nIHRoYXQgeW91IHVzZSBv dXRlciB0cmFuc3BvcnQgbGF5ZXIgZm9yDQo+Pj4gcGFzc2luZyBpbmZvcm1hdGlvbiBhbW9uZyBz ZXJ2aWNlIG5vZGVzOyB0byB0aGUgY29udHJhcnksIHRoZSBvdXRlcg0KPj4+IHRyYW5zcG9ydCBs YXllciBpcyBzaW1wbHkgdXNlZCB0byBnZXQgcGFja2V0cyBmcm9tIHBvaW50IEEgdG8gcG9pbnQg Qg0KPj4+IGFuZA0KPj4+ICpub3RoaW5nKiBtb3JlLiBJZiBwb2ludCBCIGhhcHBlbnMgdG8gYmUg YSBzZXJ2aWNlIG5vZGUgdGhhdCBpcw0KPj4+IGFjdGluZyBvbiBiZWhhbGYgb2YgYW4gYXR0YWNo ZWQgc2VydmljZSBmdW5jdGlvbiB0aGVuIHBvaW50IEIgbWF5IHVzZQ0KPj4+IHRoZSBzZXJ2aWNl LWVuY2Fwc3VsYXRpb24gdG8gZmlndXJlIG91dCBob3cgdG8gZm9yd2FyZCB0aGUgcGFja2V0IHRv DQo+Pj4gdGhlIHJpZ2h0IHNlcnZpY2UgZnVuY3Rpb24uDQo+Pj4gDQo+Pj4gT24gOS82LzEzIDEx OjM2IEFNLCAiTGluZGEgRHVuYmFyIiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3RlOg0K Pj4+IA0KPj4+ID5DYXJsb3MsDQo+Pj4gPg0KPj4+ID5JIGFncmVlIHRoYXQgeW91IGhhdmUgdG8g dXNlIE91dGVyIFRyYW5zcG9ydCBMYXllciB0byBwYXNzDQo+Pj4gPmluZm9ybWF0aW9uIGFtb25n IFNlcnZpY2UgTm9kZXMuDQo+Pj4gPg0KPj4+ID5Ib3dldmVyLCBJIHRoaW5rIHRoYXQgd2UgbmVl ZCB0byBhY2tub3dsZWRnZSB0aGF0IG1hbnkgb2YgdG9kYXkncw0KPj4+IFNlcnZpY2UNCj4+PiA+ Tm9kZXMsIGUuZy4gRlcsIExCLCBldGMsIGVzcGVjaWFsbHkgdGhlIG9uZXMgdGhhdCBhcmUgb25l IGxpbmsgYXdheQ0KPj4+IGZyb20NCj4+PiA+Rm9yd2FyZGluZyBub2RlcywgZG9uJ3QgZXZlbiB1 c2UgYW55IGFkZHJlc3Nlcy4gSWYgdGhlIEZvcndhcmRpbmcNCj4+PiBub2Rlcw0KPj4+ID5oYXZl IHRoZSBuZWVkZWQgdHJhZmZpYyBjbGFyaWZpY2F0aW9uIG1lYW5zLCB0aGV5IGNhbiBkaXJlY3Qg dGhlDQo+Pj4gPnNlbGVjdGl2ZSB0cmFmZmljIHRoYXQgbmVlZCB0aGUgIlNlcnZpY2UiIHRvIHRo ZSBzZXJ2aWNlIG5vZGVzLg0KPj4+ID4NCj4+PiA+SXQgaXMgbm90ICJvbmUgc2l6ZSIgZml0cyBh bGwgZm9yIGFsbCBTZXJ2aWNlIG5vZGVzLg0KPj4+ID4NCj4+PiA+TGluZGENCj4+PiA+DQo+Pj4g Pg0KPj4+ID4NCj4+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ID4+IEZyb206 IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZg0KPj4+IE9mDQo+Pj4gPj4gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+Pj4gPj4g U2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMDYsIDIwMTMgMTA6MjYgQU0NCj4+PiA+PiBUbzogTGlu ZGEgRHVuYmFyDQo+Pj4gPj4gQ2M6IG5zY0BpZXRmLm9yZzsgSmltIEd1aWNoYXJkIChqZ3VpY2hh cik7IE1lbGluZGEgU2hvcmU7IFJvbg0KPj4+ID4+IFBhcmtlcg0KPj4+ID4+IFN1YmplY3Q6IFJl OiBbbnNjXSBOU0MgV29ya2luZyBHcm91cCBDaGFydGVyIFByb3Bvc2FsDQo+Pj4gPj4NCj4+PiA+ PiBIaSwgTGluZGEsDQo+Pj4gPj4NCj4+PiA+PiBJIGhhdmUgdG8gYWRtaXQgdGhhdCBJIGFtIGEg Yml0IGxvc3Qgd2l0aCB0aGlzIGNvbW1lbnQgb3IgYSBjb3VwbGUNCj4+PiBvZg0KPj4+ID4+IHBy ZXZpb3VzIG9uZXMuIENvbnNlcXVlbnRseSwgSSB3YW50ZWQgdG8gc2VuZCBhIChob3BlZnVsbHkp DQo+Pj4gY2xhcmlmeWluZw0KPj4+ID4+IHN1bW1hcnkuDQo+Pj4gPj4NCj4+PiA+PiBUaGUgZ29h bCBpcyB0byBzZW5kIGEgcGFja2V0IChvcmlnaW5hbC1wYXlsb2FkIGZyb20gYSBzZXJ2aWNlDQo+ Pj4gPj4gcGVyc3BlY3RpdmUpIHdpdGggYWRkZWQgc2VydmljZSBjb250ZXh0IHRvIGEgc2Vydmlj ZSBub2RlLiBUaGlzIGlzDQo+Pj4gPj4gYSB0d28tc3RlcCBhcHByb2FjaDogd2UgY2FuIGNhbGwg dGhlIHN0ZXBzIDEuIHNlcnZpY2UgKGlubmVyKSwgMi4NCj4+PiA+PiB0cmFuc3BvcnQuDQo+Pj4g Pj4NCj4+PiA+PiBBIHNlcnZpY2UgY2hhaW4gZGVmaW5lcyBhIHNldCBvZiBzZXJ2aWNlcyBhcHBs aWVkIHRvIGFuIG9yaWdpbmFsDQo+Pj4gPj4gcGF5bG9hZC4gVG8gcHJvdmlkZSBjaGFpbiBjb250 ZXh0LCBzZXJ2aWNlIHBhdGggaWQsIGNsYXNzaWZpY2F0aW9uDQo+Pj4gaW5mbywNCj4+PiA+PiBl dGMuLCBhIHNlcnZpY2UtbGV2ZWwgZW5jYXBzdWxhdGlvbi9oZWFkZXIgaXMgYWRkZWQuIFRoaXMg c2hvdWxkDQo+Pj4gPj4gYmUgZW5jYXBzdWxhdGluZy1sYXllciAodHJhbnNwb3J0LWxheWVyKSBh Z25vc3RpYy4gU2Vjb25kLCBpbg0KPj4+ID4+IG9yZGVyIGdldCB0aGF0IHRvIGEgc2VydmljZSBu b2RlLCBpdCBnZXRzIGZ1cnRoZXIgZW5jYXBzdWxhdGVkIChpbg0KPj4+ID4+IElQLCBJUC9HUkUs IElQL1VEUCwgVlhMQU4sIE1QTFMsIGV0YykgZm9yIGRlbGl2ZXJ5Lg0KPj4+ID4+DQo+Pj4gPj4g QmVpbmcgYSBncmFwaGljYWwgcGVyc29uLCBJIGFsc28gcmVhbGx5IGxpa2Ugd2hhdCBTdXJlbmRy YSBzaGFyZWQNCj4+PiA+PiBhdCBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bnNjL2N1cnJlbnQvbXNnMDAzMTIuaHRtbA0KPj4+ID4+DQo+Pj4gPj4gSFRILA0KPj4+ID4+DQo+ Pj4gPj4gLS0gQ2FybG9zLg0KPj4+ID4+DQo+Pj4gPj4gT24gU2VwIDYsIDIwMTMsIGF0IDEwOjE3 IEFNLCBMaW5kYSBEdW5iYXINCj4+PiA+PiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+DQo+Pj4g Pj4gIHdyb3RlOg0KPj4+ID4+DQo+Pj4gPj4gPiBSb24sDQo+Pj4gPj4gPg0KPj4+ID4+ID4gR3Jl YXQhICBJIGFtIGdsYWQgdG8gc2VlIHRoYXQgd2UgZ28gZG93biB0aGlzIHBhdGguDQo+Pj4gPj4g PiBXZSBzaG91bGQgYWxzbyBhbGxvdzogL2VuZXQvaXAvdWRwIG9yIHRjcC9uc2MvLi4uDQo+Pj4g Pj4gPiBpLmUuIG5vdCBuZWNlc3NhcmlseSBoYXZpbmcgYW4gaW5uZXIgSVAuDQo+Pj4gPj4gPg0K Pj4+ID4+ID4gTGluZGENCj4+PiA+PiA+DQo+Pj4gPj4gPg0KPj4+ID4+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4gPj4gPj4gRnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9Q YXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb21dDQo+Pj4gPj4gPj4gU2VudDogVGh1cnNkYXksIFNl cHRlbWJlciAwNSwgMjAxMyA2OjE2IFBNDQo+Pj4gPj4gPj4gVG86IExpbmRhIER1bmJhcjsgSmlt IEd1aWNoYXJkIChqZ3VpY2hhcik7IE1lbGluZGEgU2hvcmU7DQo+Pj4gPj4gPj4gbnNjQGlldGYu b3JnDQo+Pj4gPj4gPj4gU3ViamVjdDogUkU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0 ZXIgUHJvcG9zYWwNCj4+PiA+PiA+Pg0KPj4+ID4+ID4+IEhpLCBMaW5kYS4NCj4+PiA+PiA+Pg0K Pj4+ID4+ID4+IEFzIGl0IHdhcyByZWNlbnRseSBleHBsYWluZWQgb24gdGhpcyB0aHJlYWQsIEkg ZG9uJ3QgdGhpbmsgaXQNCj4+PiBuZWVkcw0KPj4+ID4+ID4+IHRvIGJlIG5lY2Vzc2FyeSB0byBh bHdheXMgaGF2ZSBpdCBpZiB3ZSBhcmUgd2lsbGluZyB0byBhbGxvdw0KPj4+ID4+IG11bHRpcGxl DQo+Pj4gPj4gPj4gb3ZlcmFsbCAidHJhbnNwb3J0IitzZXJ2aWNlIGVuY2Fwc3VsYXRpb25zLiAg IEZvciBleGFtcGxlOg0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4gL2VuZXQvaXAvdWRwL25zYy9pcC90 Y3AvLi4uDQo+Pj4gPj4gPj4gL2VuZXQvaXAvZ3JlL25zYy9pcC90Y3AvLi4uDQo+Pj4gPj4gPj4g L2VuZXQvbGxjLXNuYXAvbnNjL2lwL3RjcC8uLi4NCj4+PiA+PiA+PiAvZW5ldC9tcGxzL25zYy9p cC90Y3AvLi4uDQo+Pj4gPj4gPj4NCj4+PiA+PiA+PiBBcyBtdWNoIGFzIEkgZG9uJ3QgdGhpbmsg d2UnbGwgZW5kIHVwIHRoZXJlLCBJIGRvIGZpbmQgYSBzaW5nbGUNCj4+PiA+PiA+PiBvdmVyYWxs IHVuaXZlcnNhbCB0cmFuc2Zvcm1hdGlvbiB2ZXJ5IGF0dHJhY3RpdmUgYW5kIGFueSBmbGF2b3IN Cj4+PiB0aGF0DQo+Pj4gPj4gPj4gaXMgL3tsMn0vaXAveHh4L2lwL3RjcCB3b3VsZCBiZSB1bml2 ZXJzYWxseSBhcHBsaWNhYmxlIC0tIHNhbWUNCj4+PiA+PiBzdWJuZXQNCj4+PiA+PiA+PiBvciBk aWZmZXJlbnQgc3VibmV0LCBsMiBzd2l0Y2hlcyBhbmQvb3IgbDMgcm91dGVycyBpbiBiZXR3ZWVu ICwNCj4+PiA+PiBPcGVuRmxvdw0KPj4+ID4+ID4+IG9yIG5vdCBPcGVuRmxvdywgTVBMUyBvciBu b3QgTVBMUywgLi4uICAgICBUaGUgYXJndW1lbnQgYWdhaW5zdA0KPj4+IHRoaXMNCj4+PiA+PiA+ PiB3aWxsIGJlIHRoYXQgdGhlIHBhY2tldHMgYXJlIGJpZ2dlciB0aGFuIHRoZXkgbmVlZCB0byBi ZSBmb3Igc29tZQ0KPj4+ID4+ID4+IG5ldHdvcmsgdG9wb2xvZ2llcy9wcm90b2NvbHMuICAgU2lt cGxpY2l0eSBvciBlZmZpY2llbmN5Pw0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4gICBSb24NCj4+PiA+ PiA+Pg0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4NCj4+PiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+ID4+ID4+IEZyb206IExpbmRhIER1bmJhciBbbWFpbHRvOmxpbmRhLmR1bmJh ckBodWF3ZWkuY29tXQ0KPj4+ID4+ID4+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDUsIDIw MTMgNToxOSBQTQ0KPj4+ID4+ID4+IFRvOiBSb24gUGFya2VyOyBKaW0gR3VpY2hhcmQgKGpndWlj aGFyKTsgTWVsaW5kYSBTaG9yZTsNCj4+PiBuc2NAaWV0Zi5vcmcNCj4+PiA+PiA+PiBTdWJqZWN0 OiBSRTogW25zY10gTlNDIFdvcmtpbmcgR3JvdXAgQ2hhcnRlciBQcm9wb3NhbA0KPj4+ID4+ID4+ DQo+Pj4gPj4gPj4gSSBjYW4gc2VlIHRoZSBuZWVkIGZvciB0aGlzICJOU0MiIGhlYWRlciBpbnNl cnRlZCB0byB0aGUNCj4+PiA+PiA+PiBwYWNrZXRzLA0KPj4+ID4+IGFuZA0KPj4+ID4+ID4+IG9j Y2FzaW9uYWxseSBuZWVkaW5nIGFuICJvdXRlci1pcCIgZW5jYXBzdWxhdGlvbiB0byBieS1wYXNz DQo+Pj4gPj4gPj4gbm9kZXMgdGhhdCBjYW4ndCBwYXJzZSB0aGUgIk5TQyIgaGVhZGVyLg0KPj4+ ID4+ID4+DQo+Pj4gPj4gPj4gQ2FuIHNvbWVvbmUgZXhwbGFpbiB3aHkgaXQgaXMgbmVjZXNzYXJ5 IHRvIGFsd2F5cyBoYXZlIHRoZQ0KPj4+ICJvdXRlci0NCj4+PiA+PiBpcCINCj4+PiA+PiA+PiBo ZWFkZXI/DQo+Pj4gPj4gPj4NCj4+PiA+PiA+Pg0KPj4+ID4+ID4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+ID4+ID4+Pg0KPj4+ID4+ID4+PiAJT3V0ZXItaXAvdWRwL25zYy9pbm5l ci1pcC90Y3AvcGF5bG9hZA0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4NCj4+PiA+PiA+Pg0KPj4+ID4+ ID4+IExpbmRhDQo+Pj4gPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+ID4+ID4gbnNjIG1haWxpbmcgbGlzdA0KPj4+ID4+ID4gbnNjQGlldGYu b3JnDQo+Pj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0K Pj4+ID4NCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+PiBuc2NAaWV0Zi5vcmcNCj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bnNjIG1haWxpbmcgbGlzdA0KPm5z Y0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uc2Mg bWFpbGluZyBsaXN0DQo+bnNjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uc2MNCj4NCj4NCg0K From mn1921@att.com Fri Sep 6 09:31: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 B281E11E81A5 for ; Fri, 6 Sep 2013 09:31:24 -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=[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 O5dI861bDXPr for ; Fri, 6 Sep 2013 09:31:17 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id E3D7221F9D5C for ; Fri, 6 Sep 2013 09:31:16 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 4530a225.505d1940.726783.00-592.2019225.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 06 Sep 2013 16:31:16 +0000 (UTC) X-MXL-Hash: 522a03546fab783f-daf760121a9bc47baeebe95d46066e2bc2077b38 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 3530a225.0.726778.00-325.2019200.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 06 Sep 2013 16:31:16 +0000 (UTC) X-MXL-Hash: 522a035450c78ee5-c711d7e505d9efa344950ec3fe1a9f813772da6d 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 r86GVER4021036; Fri, 6 Sep 2013 12:31:15 -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 r86GUviE020620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Sep 2013 12:31:08 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (MISOUT7MSGHUB9C.itservices.sbc.com [144.151.223.82]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 6 Sep 2013 16:30:48 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.03.0158.001; Fri, 6 Sep 2013 12:30:48 -0400 From: "NAPIERALA, MARIA H" To: "mohamed.boucadair@orange.com" , "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1Ee0QgADYD4CAAVD8UIABr9gQ Date: Fri, 6 Sep 2013 16:30:47 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E0123E6CE@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F675870@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EF06D03B0@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF06D03B0@PUEXCB1B.nanterre.francetelecom.fr> 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: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E0123E6CEMISOUT7MSGUSR9I_" 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=FdKAMuC6 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=-s3I2kwCOWQA:10 a=nkr3x_9TwrAA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=vO7vSaQi-] X-AnalysisOut: [zEA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=AUd_NHdVAAAA:8 ] X-AnalysisOut: [a=VJ7RWGmWAhe4yHaqELUA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:] X-AnalysisOut: [10 a=oAXR_kdF8uMA:10 a=JfD0Fch1gWkA:10 a=Zm6F9pthKbSK-v-n:] X-AnalysisOut: [21 a=O5aYZ83dOP2jgB0U:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8] X-AnalysisOut: [ a=wrzB1q8Dgvpk1Vf3AVkA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A] X-AnalysisOut: [:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=i5rIUn4-ywawSXVi] X-AnalysisOut: [:21 a=zh1DDXMCD2HJfGfJ:21 a=hFkAyYZGkJYxHOsl:21] Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 16:31:24 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E0123E6CEMISOUT7MSGUSR9I_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jim, et al., Service chaining solutions are currently being deployed without carrying, s= o called, metadata. I believe the proposal for carrying the metadata should cover the interoper= ability with the existing service chaining infrastructures. Maria From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of moham= ed.boucadair@orange.com Sent: Thursday, September 05, 2013 10:51 AM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Hi Jim, I have nothing against the word "metadata" itself. You can maintain it if you prefer, but it seems odd to call only that techn= ical aspect for that milestone. Cheers, Med De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mercredi 4 septembre 2013 19:37 =C0 : BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org Objet : Re: NSC Working Group Charter Proposal Hi Med, Comment inline .. From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Wednesday, September 4, 2013 10:05 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: NSC Working Group Charter Proposal Hi Jim, Thank you for preparing the text. I fully agree that, for the sake of interoperability, one standard track so= lution must be specified by the working group. I'm fully supportive to ment= ion this in the charter and avoid that during the lifetime of the working g= roup multiple solutions are envisaged. I have some comments about the proposed deliverables and the proposed timin= g: (1) I don't think it is a good idea to split the requirements into multiple= documents. For the sake of consistency and also to have the big picture, I= suggest only one single document be chartered to record the requirements. = The requirements document should include functional requirements, manageabi= lity requirements (as per RFC5706) and security requirements. The full set = of requirements should be taken into account during the design phase. (2) The specification effort should start once the requirements are almost = stable, not before. (3) I would remove the word "metadata" from the milestones. Jim> this wording is directly associated to REQ#24 of draft-boucadair-chain= ing-requirements so would a replacement of "metadata" with "context data" w= ork for you? If not please suggest an alternative, other than removal ;-). (4) I personally don't see a value to add dedicated items for detailed use = cases. There is already an undergoing effort in other fora; no need to have= redundant effort in this space. Having an abstract description level in th= e Problem Statement is sufficient IMHO. (5) I suggest to add a "Analysis and Design Choices" document: Details rate= d to design motivations and justifications will be recorded in the analysis= document while the specification document(s) focuses exclusively on the sp= ecification part. Past experience has shown that some questions are raised = multiple times during the lifetime of the wg and it is not sometimes obviou= s to find where the decision was made and for what reason. This kind of det= ails are hard (sometime) to find: either you need to check mailing list arc= hives, or contact the authors. I see the design analysis document as a form= al tool to record the consensus on controversial design issues. The documen= t can also answer to "why not my favourite solution" solve the problem(s). (6) We don't know at this stage how many specification documents will be ne= eded. Perhaps only one Standard Track document will be required. I suggest = we leave the decision on the exact number of Standard Track documents open. To sum up: my suggestion is to go for this set of deliverables: (a) Problem Statement document (b) Framework document (terminology, functional elements, architecture, and= overall procedure) (c) Requirements document (d) Design Analysis document (e) Specification document(s) I wouldn't object if the first charter of the future WG covers only items (= a) to (d). An updated charter can be envisaged once the future WG has more = visibility on the detailed set of specification documents. Cheers, Med De : nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] De la part de Jim Guichard (jguichar) Envoy=E9 : mardi 3 septembre 2013 18:01 =C0 : nsc@ietf.org Objet : [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_1D70D757A2C9D54D83B4CBD7625FA80E0123E6CEMISOUT7MSGUSR9I_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Jim, et al.,

 <= /p>

Service chaining solution= s are currently being deployed without carrying, so called, metadata.

I believe the proposal fo= r carrying the metadata should cover the interoperability with the existing= service chaining infrastructures.

 <= /p>

Maria

 <= /p>

 <= /p>

From: nsc-boun= ces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, September 05, 2013 10:51 AM
To: Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

Hi Jim,

 

I have nothing against the word “metad= ata” itself.

You can maintain it if you prefer, but it se= ems odd to call only that technical aspect for that milestone.

 

Cheers,

Med

 

De : Jim = Guichard (jguichar) [mailto:jguichar@= cisco.com]
Envoy=E9 : mercredi 4 septembre 2013 19:37
=C0 : BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org
Objet : Re: NSC Working Group Charter Proposal

 

Hi Med,

 

Comment inline ..

 

From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Date: Wednesday, September 4, 2013 10:05 AM
To: Microsoft Office User <= jguichar@cisco.com>, "nsc@ietf.= org" <nsc@ietf.org>
Subject: RE: NSC Working Group Charter Proposal

 

Hi Jim,

 

Thank you for preparing the text.

 

I fully agree that, for the sake of interope= rability, one standard track solution must be specified by the working grou= p. I’m fully supportive to mention this in the charter and avoid that during the lifetime of the working group multiple s= olutions are envisaged.

 

I have some comments about the proposed deli= verables and the proposed timing:

 

(1) I don’t think it is a good idea to= split the requirements into multiple documents. For the sake of consistenc= y and also to have the big picture, I suggest only one single document be chartered to record the requirements. The requirements = document should include functional requirements, manageability requirements= (as per RFC5706) and security requirements. The full set of requirements s= hould be taken into account during the design phase.

 

(2) The specification effort should start on= ce the requirements are almost stable, not before.

 

(3) I would remove the word “metadata&= #8221; from the milestones.

 

Jim> this wording is direc= tly associated to REQ#24 of draft-boucadair-chaining-requirements so would = a replacement of "metadata" with "context data" work fo= r you? If not please suggest an alternative, other than removal ;-).

 

(4) I personally don’t see a value to = add dedicated items for detailed use cases. There is already an undergoing = effort in other fora; no need to have redundant effort in this space. Having an abstract description level in the Problem Stateme= nt is sufficient IMHO.=

 

(5) I suggest to add a “Analysis and D= esign Choices” document: Details rated to design motivations and just= ifications will be recorded in the analysis document while the specification document(s) focuses exclusively on the specification par= t. Past experience has shown that some questions are raised multiple times = during the lifetime of the wg and it is not sometimes obvious to find where= the decision was made and for what reason. This kind of details are hard (sometime) to find: either you need = to check mailing list archives, or contact the authors. I see the design an= alysis document as a formal tool to record the consensus on controversial d= esign issues. The document can also answer to “why not my favourite solution” solve the problem(s)= .

 

(6) We don’t know at this stage how ma= ny specification documents will be needed. Perhaps only one Standard Track = document will be required. I suggest we leave the decision on the exact number of Standard Track documents open.

 

To sum up: my suggestion is to go for this s= et of deliverables:

 

(a) Problem Statement document

(b) Framework document (terminology, functio= nal elements, architecture, and overall procedure)

(c) Requirements document=

(d) Design Analysis document

(e) Specification document(s)

 

I wouldn’t object if the first charter= of the future WG covers only items (a) to (d). An updated charter can be e= nvisaged once the future WG has more visibility on the detailed set of specification documents.

 

Cheers,

Med

 

 

De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoy=E9 : mardi 3 septembre 2013 18:01
=C0 : nsc@ietf.org
Objet : [nsc] NSC Working Group Charter Proposal

 =

Greetings,

 

As we look forward to the f= ormation of a working group that will focus on network service chaining, I = would like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area= AD's. The following is a first draft of the charter and I invite you to ac= tively participate and provide inputs into this process.

 

Proposed NSC WG Charter<= /span>

 

Existing service insertion = and deployment techniques have not evolved to meet modern network architect= ures and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, st= orage, and applications, have all undergone significant change in recent ye= ars: virtualization, network overlays, and orchestration are increasingly t= he norm. All of these have profound effects on network and services design.=

 

Today, deploying new servic= es, or making changes to existing services, often requires network topology= changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o mostly-static service definitions. New service insertion and deployment t= echniques must enable the concept of service functions as shared resources,= and enable the linkage of these resources using service chains that represent the abstracted view of the r= equired service functions, and define the order in which they should be app= lied. When a service chain is instantiated in a network, specific instances= of service functions are selected, and a service topology is created and used for forwarding packets through = the service chain.

 

A basic service chain might= simply utilize an existing overlay technology to force traffic through the= necessary service functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chainin= g (NSC) working group focuses on new approaches to service insertion and de= ployment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary proto= cols for the creation of service chains, and the passing of metadata from t= he network to service functions, and between service functions. When possib= le, the WG will extend existing protocols to provide service chaining functionality, and any protocol exte= nsions will be reviewed by both the Network Service Chaining WG and by the = WG responsible for the protocol being extended.  

 

Specifically, the Network S= ervice Chaining WG is chartered to deliver the following work items: <= /span>

 

1) Problem Statement: this = document will provide a summary of the problem space to be addressed by the= Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.=

 

2) System Architecture: thi= s set of documents will provide a description of the architecture building = blocks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pl= ane: this document will describe on the wire data plane encapsulation in su= pport of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docu= ment will address service chaining operation, monitoring and troubleshootin= g including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are rea= lized.

 

Proposed Milestones:=

 

Dec 2013 Request publicatio= n of an Informational document defining the Network Service Chaining proble= m statement to the IESG

 

Mar 2014 Request publicatio= n of informational documents defining the system architecture including pro= tocol requirements and framework to the IESG

 

May 2014 Request publicatio= n of a Standards Track document specifying the data-plane (including metada= ta) for Service Chaining to IESG

 

May 2014 Request publicatio= n of an informational document specifying Service Chaining Control Plane re= quirements to IESG

 

Dec 2014 Request publicatio= n of informational documents defining Service Chaining manageability requir= ements including MIBs, OAM, and information models to IESG 

 

 

--_000_1D70D757A2C9D54D83B4CBD7625FA80E0123E6CEMISOUT7MSGUSR9I_-- From cpignata@cisco.com Fri Sep 6 09:31:45 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4E711E82B1 for ; Fri, 6 Sep 2013 09:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.622 X-Spam-Level: X-Spam-Status: No, score=-109.622 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 0eQlY5m8b1lR for ; Fri, 6 Sep 2013 09:31:34 -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 6C07911E82C8 for ; Fri, 6 Sep 2013 09:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12370; q=dns/txt; s=iport; t=1378485091; x=1379694691; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=y8STGBFkda9uGBotaV2yvYkFQ9La69ZzPqAGy4+05Uw=; b=DdT4jNgTIg+Wkm904KUzEtJRxAikOWN6B0bwzUc73kktUnPuwLfnraL8 3RvQMhoETA+k3TManx8mVCeokJF+QeVfLakIdCVlo1X05Vx+sH94jfCEM lWGYVxEYjLxgJzqq2QTMrAWjV5l3joKPeKTqn442598luulhpwLB67y60 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFANkCKlKtJV2Y/2dsb2JhbABbgwc1UYMqvisXgQ8WdIIkAQEBBAEBASQNMwcXBgEIEQQBAQEEBh0FBCULFAkIAgQBEggBEodnDJEQm0QGkSyBI40ggQYCFiIGgl06gQADlBuVQIMggXE5 X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="scan'208";a="256542004" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 06 Sep 2013 16:31:28 +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 r86GVRbR029732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 16:31:27 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 11:31:27 -0500 From: "Carlos Pignataro (cpignata)" To: Linda Dunbar , Jerome Moisand , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAIAAKPeAgAAgwgCAAPvEAIAAEw+AgAADDoD//764AIAARk2A//+9noAACIVqAAAAtTMA//+/z4A= Date: Fri, 6 Sep 2013 16:31:27 +0000 Message-ID: <95067C434CE250468B77282634C96ED325EFFA37@xmb-aln-x02.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9EB9A@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.117.115.50] Content-Type: text/plain; charset="euc-kr" Content-ID: <77F2E50AC77434459BCF040B664D2701@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 16:31:45 -0000 TGluZGEsDQoNClNldmVyYWwgZG96ZW4gZW1haWxzIGFnbywgSmltIHNlbnQgdGhlIGZvbGxvd2lu ZyAtLSB3aGF0IGlzIHlvdXIgdGFrZT8NCg0KLS0tPjgtLS0NCg0KMykgU2VydmljZSBDaGFpbmlu ZyBEYXRhICYgQ29udHJvbCBQbGFuZTogQSBkYXRhIHBsYW5lIGRvY3VtZW50IHdpbGwNCmRlc2Ny aWJlIG9uIHRoZSB3aXJlIGRhdGEgcGxhbmUgZW5jYXBzdWxhdGlvbiBpbiBzdXBwb3J0IG9mICgy KS4gQSBzaW5nbGUNCnNlcnZpY2UtbGV2ZWwgZW5jYXBzdWxhdGlvbiB3aWxsIGJlIHNlbGVjdGVk IGluIG9yZGVyIHRvIGVuYWJsZQ0KaW50ZXJvcGVyYWJpbGl0eSBvZiBkYXRhIHBsYW5lIGNvbXBv bmVudHMsIHdoaWNoIGNhbiBpbiB0dXJuIGJlIGNhcnJpZWQgaW4NCnZhcmlvdXMgdHJhbnNwb3J0 IGVuY2Fwc3VsYXRpb25zIChlLmcuLCBJUCwgTVBMUywgb3Igb3RoZXIgb3ZlcmxheXMpLg0KU3Vw cG9ydGluZyBjb250cm9sIHBsYW5lIHByb3RvY29sIGVsZW1lbnRzIHdpbGwgYmUgYWRkZWQgYXMg bmVlZGVkIChhcyBhDQpzZXBhcmF0ZSBkb2N1bWVudCkuDQotLS0+OC0tLQ0KDQoNClRoYW5rcywN Cg0KLS0gQ2FybG9zLg0KDQpPbiA5LzYvMTMgMTI6MjEgUE0sICJMaW5kYSBEdW5iYXIiIDxsaW5k YS5kdW5iYXJAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5UaGUgZGlzY3Vzc2lvbiBpcyBhYm91dCB1 c2luZyAiQSBTaW5nbGUgRW5jYXBzdWxhdGlvbi4uIiBpbiB0aGUgQ2hhcnRlci4NCj4NCj5FdmVu IHRob3VnaCBpdCBpcyBpZGVhbCBhbmQgZXZlcnlvbmUgKG15c2VsZiBpbmNsdWRlZCkgbG92ZXMg aXQsIGJ1dCBJIGFtDQo+YWZyYWlkIHRoYXQgbm90IGV2ZXJ5IFNlcnZpY2UgQ2hhaW4gY2FzZSB3 aWxsIG5lZWQgb3V0ZXIgZW5jYXBzdWxhdGlvbi4NCj4NCj4NCj5MaW5kYQ0KPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4gSmVyb21lIE1vaXNhbmQNCj4+ IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDA2LCAyMDEzIDExOjAxIEFNDQo+PiBUbzogbnNjQGll dGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW25zY10gTlNDIFdvcmtpbmcgR3JvdXAgQ2hhcnRlciBQ cm9wb3NhbA0KPj4gDQo+PiBHdXlzLCBjb3VsZCB3ZSBwbGVhc2Uga2VlcCB0aGlzIGRpc2N1c3Np b24gZm9yIGxhdGVyPyBXZSdyZSBzdXBwb3NlZCB0bw0KPj4gZGlzY3VzcyBhIGNoYXJ0ZXIgaGVy ZS4gTm90IGEgc3BlY2lmaWMgc29sdXRpb24uDQo+PiANCj4+IEZhaXIgZW5vdWdoPw0KPj4gDQo+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+PiBKaW0gR3Vp Y2hhcmQgKGpndWljaGFyKQ0KPj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMDYsIDIwMTMgMTE6 NTcgQU0NCj4+IFRvOiBMaW5kYSBEdW5iYXI7IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0K Pj4gQ2M6IG5zY0BpZXRmLm9yZzsgTWVsaW5kYSBTaG9yZTsgUm9uIFBhcmtlcg0KPj4gU3ViamVj dDogUmU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCj4+IA0KPj4g VGhlbiB1c2Ugcm91dGluZy4NCj4+IA0KPj4gT24gOS82LzEzIDExOjU0IEFNLCAiTGluZGEgRHVu YmFyIiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gDQo+PiA+SmltLA0KPj4g Pg0KPj4gPldoYXQgaWYgIkEiIGFuZCAiQiIgaW4geW91ciBleGFtcGxlIGFyZSB0b2RheSdzIGV4 aXN0aW5nIG5vZGVzLCAodGhleQ0KPj4gPmFyZSBub3QgYXdhcmUgb2YgTlNDIGhlYWRlcikgYW5k IHRoZSB0cmFmZmljIGJldHdlZW4gIkEiIGFuZCAiQiIgbmVlZHMNCj4+ID5hIHNlcXVlbmNlIG9m IHNlcnZpY2UgZnVuY3Rpb25zPw0KPj4gPg0KPj4gPlNvbWUgc2VydmljZSBmdW5jdGlvbnMgYXJl IG9uZSBsaW5rIGF3YXkgZnJvbSBmb3J3YXJkaW5nIG5vZGVzIChvcg0KPj4gPmNvLWxvY2F0ZWQp LCB3aGljaCBtYXkgbm90IHJlcXVpcmUgYW5vdGhlciBsYXllciBvZiBlbmNhcHN1bGF0aW9uLiBC dXQNCj4+ID5zb21lIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBhY2Nlc3NpYmxlIHZpYSBtdWx0aXBs ZSBub2RlcywgdGhlbiB0aGVyZQ0KPj4gaXMNCj4+ID5uZWVkIGZvciBhbm90aGVyIGxheWVyIGVu Y2Fwc3VsYXRpb24uDQo+PiA+DQo+PiA+TGluZGENCj4+ID4NCj4+ID4NCj4+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+IE9mDQo+PiA+PiBKaW0gR3Vp Y2hhcmQgKGpndWljaGFyKQ0KPj4gPj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMDYsIDIwMTMg MTA6NDMgQU0NCj4+ID4+IFRvOiBMaW5kYSBEdW5iYXI7IENhcmxvcyBQaWduYXRhcm8gKGNwaWdu YXRhKQ0KPj4gPj4gQ2M6IG5zY0BpZXRmLm9yZzsgTWVsaW5kYSBTaG9yZTsgUm9uIFBhcmtlcg0K Pj4gPj4gU3ViamVjdDogUmU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9z YWwNCj4+ID4+DQo+PiA+PiBMaW5kYSwNCj4+ID4+DQo+PiA+PiBJIGRvbqn2dCB0aGluayBhbnlv bmUgaXMgc2F5aW5nIHRoYXQgeW91IHVzZSBvdXRlciB0cmFuc3BvcnQgbGF5ZXINCj4+IGZvcg0K Pj4gPj4gcGFzc2luZyBpbmZvcm1hdGlvbiBhbW9uZyBzZXJ2aWNlIG5vZGVzOyB0byB0aGUgY29u dHJhcnksIHRoZSBvdXRlcg0KPj4gPj4gdHJhbnNwb3J0IGxheWVyIGlzIHNpbXBseSB1c2VkIHRv IGdldCBwYWNrZXRzIGZyb20gcG9pbnQgQSB0byBwb2ludA0KPj4gQg0KPj4gPj4gYW5kDQo+PiA+ PiAqbm90aGluZyogbW9yZS4gSWYgcG9pbnQgQiBoYXBwZW5zIHRvIGJlIGEgc2VydmljZSBub2Rl IHRoYXQgaXMNCj4+ID4+IGFjdGluZyBvbiBiZWhhbGYgb2YgYW4gYXR0YWNoZWQgc2VydmljZSBm dW5jdGlvbiB0aGVuIHBvaW50IEIgbWF5DQo+PiB1c2UNCj4+ID4+IHRoZSBzZXJ2aWNlLWVuY2Fw c3VsYXRpb24gdG8gZmlndXJlIG91dCBob3cgdG8gZm9yd2FyZCB0aGUgcGFja2V0IHRvDQo+PiA+ PiB0aGUgcmlnaHQgc2VydmljZSBmdW5jdGlvbi4NCj4+ID4+DQo+PiA+PiBPbiA5LzYvMTMgMTE6 MzYgQU0sICJMaW5kYSBEdW5iYXIiIDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ PiA+Pg0KPj4gPj4gPkNhcmxvcywNCj4+ID4+ID4NCj4+ID4+ID5JIGFncmVlIHRoYXQgeW91IGhh dmUgdG8gdXNlIE91dGVyIFRyYW5zcG9ydCBMYXllciB0byBwYXNzDQo+PiA+PiA+aW5mb3JtYXRp b24gYW1vbmcgU2VydmljZSBOb2Rlcy4NCj4+ID4+ID4NCj4+ID4+ID5Ib3dldmVyLCBJIHRoaW5r IHRoYXQgd2UgbmVlZCB0byBhY2tub3dsZWRnZSB0aGF0IG1hbnkgb2YgdG9kYXkncw0KPj4gPj4g U2VydmljZQ0KPj4gPj4gPk5vZGVzLCBlLmcuIEZXLCBMQiwgZXRjLCBlc3BlY2lhbGx5IHRoZSBv bmVzIHRoYXQgYXJlIG9uZSBsaW5rIGF3YXkNCj4+ID4+IGZyb20NCj4+ID4+ID5Gb3J3YXJkaW5n IG5vZGVzLCBkb24ndCBldmVuIHVzZSBhbnkgYWRkcmVzc2VzLiBJZiB0aGUgRm9yd2FyZGluZw0K Pj4gPj4gbm9kZXMNCj4+ID4+ID5oYXZlIHRoZSBuZWVkZWQgdHJhZmZpYyBjbGFyaWZpY2F0aW9u IG1lYW5zLCB0aGV5IGNhbiBkaXJlY3QgdGhlDQo+PiA+PiA+c2VsZWN0aXZlIHRyYWZmaWMgdGhh dCBuZWVkIHRoZSAiU2VydmljZSIgdG8gdGhlIHNlcnZpY2Ugbm9kZXMuDQo+PiA+PiA+DQo+PiA+ PiA+SXQgaXMgbm90ICJvbmUgc2l6ZSIgZml0cyBhbGwgZm9yIGFsbCBTZXJ2aWNlIG5vZGVzLg0K Pj4gPj4gPg0KPj4gPj4gPkxpbmRhDQo+PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPj4gRnJvbTogbnNjLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+IEJlaGFsZg0KPj4g Pj4gT2YNCj4+ID4+ID4+IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0KPj4gPj4gPj4gU2Vu dDogRnJpZGF5LCBTZXB0ZW1iZXIgMDYsIDIwMTMgMTA6MjYgQU0NCj4+ID4+ID4+IFRvOiBMaW5k YSBEdW5iYXINCj4+ID4+ID4+IENjOiBuc2NAaWV0Zi5vcmc7IEppbSBHdWljaGFyZCAoamd1aWNo YXIpOyBNZWxpbmRhIFNob3JlOyBSb24NCj4+ID4+ID4+IFBhcmtlcg0KPj4gPj4gPj4gU3ViamVj dDogUmU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCj4+ID4+ID4+ DQo+PiA+PiA+PiBIaSwgTGluZGEsDQo+PiA+PiA+Pg0KPj4gPj4gPj4gSSBoYXZlIHRvIGFkbWl0 IHRoYXQgSSBhbSBhIGJpdCBsb3N0IHdpdGggdGhpcyBjb21tZW50IG9yIGENCj4+IGNvdXBsZQ0K Pj4gPj4gb2YNCj4+ID4+ID4+IHByZXZpb3VzIG9uZXMuIENvbnNlcXVlbnRseSwgSSB3YW50ZWQg dG8gc2VuZCBhIChob3BlZnVsbHkpDQo+PiA+PiBjbGFyaWZ5aW5nDQo+PiA+PiA+PiBzdW1tYXJ5 Lg0KPj4gPj4gPj4NCj4+ID4+ID4+IFRoZSBnb2FsIGlzIHRvIHNlbmQgYSBwYWNrZXQgKG9yaWdp bmFsLXBheWxvYWQgZnJvbSBhIHNlcnZpY2UNCj4+ID4+ID4+IHBlcnNwZWN0aXZlKSB3aXRoIGFk ZGVkIHNlcnZpY2UgY29udGV4dCB0byBhIHNlcnZpY2Ugbm9kZS4gVGhpcw0KPj4gaXMNCj4+ID4+ ID4+IGEgdHdvLXN0ZXAgYXBwcm9hY2g6IHdlIGNhbiBjYWxsIHRoZSBzdGVwcyAxLiBzZXJ2aWNl IChpbm5lciksIDIuDQo+PiA+PiA+PiB0cmFuc3BvcnQuDQo+PiA+PiA+Pg0KPj4gPj4gPj4gQSBz ZXJ2aWNlIGNoYWluIGRlZmluZXMgYSBzZXQgb2Ygc2VydmljZXMgYXBwbGllZCB0byBhbiBvcmln aW5hbA0KPj4gPj4gPj4gcGF5bG9hZC4gVG8gcHJvdmlkZSBjaGFpbiBjb250ZXh0LCBzZXJ2aWNl IHBhdGggaWQsDQo+PiBjbGFzc2lmaWNhdGlvbg0KPj4gPj4gaW5mbywNCj4+ID4+ID4+IGV0Yy4s IGEgc2VydmljZS1sZXZlbCBlbmNhcHN1bGF0aW9uL2hlYWRlciBpcyBhZGRlZC4gVGhpcyBzaG91 bGQNCj4+ID4+ID4+IGJlIGVuY2Fwc3VsYXRpbmctbGF5ZXIgKHRyYW5zcG9ydC1sYXllcikgYWdu b3N0aWMuIFNlY29uZCwgaW4NCj4+ID4+ID4+IG9yZGVyIGdldCB0aGF0IHRvIGEgc2VydmljZSBu b2RlLCBpdCBnZXRzIGZ1cnRoZXIgZW5jYXBzdWxhdGVkDQo+PiAoaW4NCj4+ID4+ID4+IElQLCBJ UC9HUkUsIElQL1VEUCwgVlhMQU4sIE1QTFMsIGV0YykgZm9yIGRlbGl2ZXJ5Lg0KPj4gPj4gPj4N Cj4+ID4+ID4+IEJlaW5nIGEgZ3JhcGhpY2FsIHBlcnNvbiwgSSBhbHNvIHJlYWxseSBsaWtlIHdo YXQgU3VyZW5kcmEgc2hhcmVkDQo+PiA+PiA+PiBhdCBodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvbnNjL2N1cnJlbnQvbXNnMDAzMTIuaHRtbA0KPj4gPj4gPj4NCj4+ID4+ID4+ IEhUSCwNCj4+ID4+ID4+DQo+PiA+PiA+PiAtLSBDYXJsb3MuDQo+PiA+PiA+Pg0KPj4gPj4gPj4g T24gU2VwIDYsIDIwMTMsIGF0IDEwOjE3IEFNLCBMaW5kYSBEdW5iYXINCj4+ID4+ID4+IDxsaW5k YS5kdW5iYXJAaHVhd2VpLmNvbT4NCj4+ID4+ID4+ICB3cm90ZToNCj4+ID4+ID4+DQo+PiA+PiA+ PiA+IFJvbiwNCj4+ID4+ID4+ID4NCj4+ID4+ID4+ID4gR3JlYXQhICBJIGFtIGdsYWQgdG8gc2Vl IHRoYXQgd2UgZ28gZG93biB0aGlzIHBhdGguDQo+PiA+PiA+PiA+IFdlIHNob3VsZCBhbHNvIGFs bG93OiAvZW5ldC9pcC91ZHAgb3IgdGNwL25zYy8uLi4NCj4+ID4+ID4+ID4gaS5lLiBub3QgbmVj ZXNzYXJpbHkgaGF2aW5nIGFuIGlubmVyIElQLg0KPj4gPj4gPj4gPg0KPj4gPj4gPj4gPiBMaW5k YQ0KPj4gPj4gPj4gPg0KPj4gPj4gPj4gPg0KPj4gPj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+ID4+ID4+ID4+IEZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2Vy QGFmZmlybWVkbmV0d29ya3MuY29tXQ0KPj4gPj4gPj4gPj4gU2VudDogVGh1cnNkYXksIFNlcHRl bWJlciAwNSwgMjAxMyA2OjE2IFBNDQo+PiA+PiA+PiA+PiBUbzogTGluZGEgRHVuYmFyOyBKaW0g R3VpY2hhcmQgKGpndWljaGFyKTsgTWVsaW5kYSBTaG9yZTsNCj4+ID4+ID4+ID4+IG5zY0BpZXRm Lm9yZw0KPj4gPj4gPj4gPj4gU3ViamVjdDogUkU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENo YXJ0ZXIgUHJvcG9zYWwNCj4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiBIaSwgTGluZGEuDQo+PiA+ PiA+PiA+Pg0KPj4gPj4gPj4gPj4gQXMgaXQgd2FzIHJlY2VudGx5IGV4cGxhaW5lZCBvbiB0aGlz IHRocmVhZCwgSSBkb24ndCB0aGluayBpdA0KPj4gPj4gbmVlZHMNCj4+ID4+ID4+ID4+IHRvIGJl IG5lY2Vzc2FyeSB0byBhbHdheXMgaGF2ZSBpdCBpZiB3ZSBhcmUgd2lsbGluZyB0byBhbGxvdw0K Pj4gPj4gPj4gbXVsdGlwbGUNCj4+ID4+ID4+ID4+IG92ZXJhbGwgInRyYW5zcG9ydCIrc2Vydmlj ZSBlbmNhcHN1bGF0aW9ucy4gICBGb3IgZXhhbXBsZToNCj4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+ PiAvZW5ldC9pcC91ZHAvbnNjL2lwL3RjcC8uLi4NCj4+ID4+ID4+ID4+IC9lbmV0L2lwL2dyZS9u c2MvaXAvdGNwLy4uLg0KPj4gPj4gPj4gPj4gL2VuZXQvbGxjLXNuYXAvbnNjL2lwL3RjcC8uLi4N Cj4+ID4+ID4+ID4+IC9lbmV0L21wbHMvbnNjL2lwL3RjcC8uLi4NCj4+ID4+ID4+ID4+DQo+PiA+ PiA+PiA+PiBBcyBtdWNoIGFzIEkgZG9uJ3QgdGhpbmsgd2UnbGwgZW5kIHVwIHRoZXJlLCBJIGRv IGZpbmQgYQ0KPj4gc2luZ2xlDQo+PiA+PiA+PiA+PiBvdmVyYWxsIHVuaXZlcnNhbCB0cmFuc2Zv cm1hdGlvbiB2ZXJ5IGF0dHJhY3RpdmUgYW5kIGFueQ0KPj4gZmxhdm9yDQo+PiA+PiB0aGF0DQo+ PiA+PiA+PiA+PiBpcyAve2wyfS9pcC94eHgvaXAvdGNwIHdvdWxkIGJlIHVuaXZlcnNhbGx5IGFw cGxpY2FibGUgLS0gc2FtZQ0KPj4gPj4gPj4gc3VibmV0DQo+PiA+PiA+PiA+PiBvciBkaWZmZXJl bnQgc3VibmV0LCBsMiBzd2l0Y2hlcyBhbmQvb3IgbDMgcm91dGVycyBpbiBiZXR3ZWVuICwNCj4+ ID4+ID4+IE9wZW5GbG93DQo+PiA+PiA+PiA+PiBvciBub3QgT3BlbkZsb3csIE1QTFMgb3Igbm90 IE1QTFMsIC4uLiAgICAgVGhlIGFyZ3VtZW50DQo+PiBhZ2FpbnN0DQo+PiA+PiB0aGlzDQo+PiA+ PiA+PiA+PiB3aWxsIGJlIHRoYXQgdGhlIHBhY2tldHMgYXJlIGJpZ2dlciB0aGFuIHRoZXkgbmVl ZCB0byBiZSBmb3INCj4+IHNvbWUNCj4+ID4+ID4+ID4+IG5ldHdvcmsgdG9wb2xvZ2llcy9wcm90 b2NvbHMuICAgU2ltcGxpY2l0eSBvciBlZmZpY2llbmN5Pw0KPj4gPj4gPj4gPj4NCj4+ID4+ID4+ ID4+ICAgUm9uDQo+PiA+PiA+PiA+Pg0KPj4gPj4gPj4gPj4NCj4+ID4+ID4+ID4+DQo+PiA+PiA+ PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPj4gPj4gRnJvbTogTGluZGEg RHVuYmFyIFttYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb21dDQo+PiA+PiA+PiA+PiBTZW50 OiBUaHVyc2RheSwgU2VwdGVtYmVyIDA1LCAyMDEzIDU6MTkgUE0NCj4+ID4+ID4+ID4+IFRvOiBS b24gUGFya2VyOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTWVsaW5kYSBTaG9yZTsNCj4+ID4+ IG5zY0BpZXRmLm9yZw0KPj4gPj4gPj4gPj4gU3ViamVjdDogUkU6IFtuc2NdIE5TQyBXb3JraW5n IEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCj4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiBJIGNhbiBz ZWUgdGhlIG5lZWQgZm9yIHRoaXMgIk5TQyIgaGVhZGVyIGluc2VydGVkIHRvIHRoZQ0KPj4gPj4g Pj4gPj4gcGFja2V0cywNCj4+ID4+ID4+IGFuZA0KPj4gPj4gPj4gPj4gb2NjYXNpb25hbGx5IG5l ZWRpbmcgYW4gIm91dGVyLWlwIiBlbmNhcHN1bGF0aW9uIHRvIGJ5LXBhc3MNCj4+ID4+ID4+ID4+ IG5vZGVzIHRoYXQgY2FuJ3QgcGFyc2UgdGhlICJOU0MiIGhlYWRlci4NCj4+ID4+ID4+ID4+DQo+ PiA+PiA+PiA+PiBDYW4gc29tZW9uZSBleHBsYWluIHdoeSBpdCBpcyBuZWNlc3NhcnkgdG8gYWx3 YXlzIGhhdmUgdGhlDQo+PiA+PiAib3V0ZXItDQo+PiA+PiA+PiBpcCINCj4+ID4+ID4+ID4+IGhl YWRlcj8NCj4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+Pg0KPj4gPj4gPj4gPj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+PiAJT3V0ZXItaXAvdWRw L25zYy9pbm5lci1pcC90Y3AvcGF5bG9hZA0KPj4gPj4gPj4gPj4NCj4+ID4+ID4+ID4+DQo+PiA+ PiA+PiA+Pg0KPj4gPj4gPj4gPj4gTGluZGENCj4+ID4+ID4+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+ID4gbnNjIG1haWxpbmcgbGlz dA0KPj4gPj4gPj4gPiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+ID4+ID4NCj4+ID4+DQo+PiA+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gbnNjIG1haWxpbmcg bGlzdA0KPj4gPj4gbnNjQGlldGYub3JnDQo+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25zYw0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gbnNjIG1haWxpbmcgbGlzdA0KPj4gbnNjQGlldGYub3JnDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4gDQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbnNjIG1haWxp bmcgbGlzdA0KPj4gbnNjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25zYw0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+bnNjIG1haWxpbmcgbGlzdA0KPm5zY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQoNCg== From jguichar@cisco.com Fri Sep 6 09:38: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 6F34711E8199 for ; Fri, 6 Sep 2013 09:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[AWL=-0.750, 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 b9qgn8QbjBGe for ; Fri, 6 Sep 2013 09:38:46 -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 D13A521F9FF6 for ; Fri, 6 Sep 2013 09:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8876; q=dns/txt; s=iport; t=1378485526; x=1379695126; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=f2xCEyy5hKcR3E1peoC8n8Cn+C5mI7Fr2bBL/Vr55pU=; b=jWfye+q/ZJwzk6dd/WJwI81T+Qbx5EfImtHR3zDWY+tzM7BB8vLXK+wV WBimmgGe4sCbGl5zYdWDTFGVP28Qia7sT+Yl5KSoo5jqKr1mfHJBE3F3g zez65FSiyBVLwL8hLwGRPQlAVYb9yxaMoXGgV3JDhvCTD/dn5cq8kB2Rz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAMoDKlKtJXG9/2dsb2JhbABbgwc1UYMqvisXgQ8WdIIkAQEBBAEBATE6CwwGAQgRBAEBAQQGHQUEJQsUCQgCBAENBQgBh3kMkRKbRAaRLIEjjSCBBgIWGwcGgl06gQADlBuVQIMggXE5 X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="scan'208";a="256355670" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 06 Sep 2013 16:38:39 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r86GccM7020234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 16:38:38 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 11:38:38 -0500 From: "Jim Guichard (jguichar)" To: "Joel M. Halpern" , "Carlos Pignataro (cpignata)" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAIAAKPeAgAAgwgCAAPvEAIAAEw+AgAADDoD//764AIAARAkAgAAMBYD//7+CAA== Date: Fri, 6 Sep 2013 16:38:37 +0000 Message-ID: <68B171751455884590F8E38E96416F363F678AF7@xmb-rcd-x01.cisco.com> In-Reply-To: <522A02E5.4080800@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.246.115] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nsc@ietf.org" , Melinda Shore , Ron Parker , Linda Dunbar Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 16:38:51 -0000 SGkgSm9lbCwNCg0KQm90aCBhcmUgdmFsaWQgYW5kIEkgYmVsaWV2ZSBpdGVtIDMpIGluIHRoZSBj aGFydGVyIGlzIHdyaXR0ZW4gaW4gc3VjaCBhDQp3YXkgYXMgdG8gcHV0IGJvdGggaW4tc2NvcGUu DQoNCk9uIDkvNi8xMyAxMjoyOSBQTSwgIkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVy bi5jb20+IHdyb3RlOg0KDQo+SSBhbSBzb21ld2hhdCBjb25mdXNlZCBiZXR3ZWVuIHRoZSBtdXN0 cyBhbmQgdGhlIG1heXMuDQo+SSBkbyB0aGluayB0aGF0IHRoZXJlIGFyZSBjaXJjdW1zdGFuY2Vz IHdoZXJlIHRoZSBvdXRlciAoInRyYW5zcG9ydCINCj5oZWFkZXIgY2FuIGNhcnJ5IGFuZCB1c2Ug d2l0aCBleGlzdGluZyBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIHRoYXQNCj5pZGVudGlmaWVzIC8g ZGlyZWN0cyB0aGUgc2VydmljZSBjaGFpbmluZy4NCj5JIGVxdWFsbHkgYWdyZWUgdGhhdCB3ZSBk b24ndCBuZWVkIHRvIG1hbmRhdGUgdGhhdC4NCj5BbmQgSSBoYXZlIGxpdHRsZSBwcm9ibGVtIGR1 cGxpY2F0aW5nIGFueSBzdWNoIGluZm9ybWF0aW9uIGluIGENCj5jb25zaXN0ZW50IGEgcmV1c2Fi bGUgaW50ZXJtZWRpYXRlIGVuY2Fwc3VsYXRpb24gaGVhZGVyIHNvIHRoYXQgaXQgY2FuDQo+YmUg aGFuZGxlZCBpbiBvdGhlciB3YXlzLg0KPg0KPllvdXJzLA0KPkpvZWwNCj4NCj5PbiA5LzYvMTMg MTE6NDYgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSB3cm90ZToNCj4+IExpbmRhLA0K Pj4NCj4+IFdoYXQgSmltIHNhaWQuDQo+Pg0KPj4gSSB3YXMgbm90IHNheWluZyB0aGlzOg0KPj4+ IENhcmxvcywNCj4+Pg0KPj4NCj4+PiBJIGFncmVlIHRoYXQgeW91IGhhdmUgdG8gdXNlIE91dGVy IFRyYW5zcG9ydCBMYXllciB0byBwYXNzIGluZm9ybWF0aW9uDQo+Pj4gYW1vbmcgU2VydmljZSBO b2Rlcy4NCj4+DQo+PiAtLSBDYXJsb3MuDQo+Pg0KPj4NCj4+IE9uIFNlcCA2LCAyMDEzLCBhdCAx MTo0MiBBTSwgIkppbSBHdWljaGFyZCAoamd1aWNoYXIpIg0KPj48amd1aWNoYXJAY2lzY28uY29t Pg0KPj4gICB3cm90ZToNCj4+DQo+Pj4gTGluZGEsDQo+Pj4NCj4+PiBJIGRvbqn2dCB0aGluayBh bnlvbmUgaXMgc2F5aW5nIHRoYXQgeW91IHVzZSBvdXRlciB0cmFuc3BvcnQgbGF5ZXIgZm9yDQo+ Pj4gcGFzc2luZyBpbmZvcm1hdGlvbiBhbW9uZyBzZXJ2aWNlIG5vZGVzOyB0byB0aGUgY29udHJh cnksIHRoZSBvdXRlcg0KPj4+IHRyYW5zcG9ydCBsYXllciBpcyBzaW1wbHkgdXNlZCB0byBnZXQg cGFja2V0cyBmcm9tIHBvaW50IEEgdG8gcG9pbnQgQg0KPj4+YW5kDQo+Pj4gKm5vdGhpbmcqIG1v cmUuIElmIHBvaW50IEIgaGFwcGVucyB0byBiZSBhIHNlcnZpY2Ugbm9kZSB0aGF0IGlzIGFjdGlu Zw0KPj4+b24NCj4+PiBiZWhhbGYgb2YgYW4gYXR0YWNoZWQgc2VydmljZSBmdW5jdGlvbiB0aGVu IHBvaW50IEIgbWF5IHVzZSB0aGUNCj4+PiBzZXJ2aWNlLWVuY2Fwc3VsYXRpb24gdG8gZmlndXJl IG91dCBob3cgdG8gZm9yd2FyZCB0aGUgcGFja2V0IHRvIHRoZQ0KPj4+cmlnaHQNCj4+PiBzZXJ2 aWNlIGZ1bmN0aW9uLg0KPj4+DQo+Pj4gT24gOS82LzEzIDExOjM2IEFNLCAiTGluZGEgRHVuYmFy IiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4+DQo+Pj4+IENhcmxvcywNCj4+ Pj4NCj4+Pj4gSSBhZ3JlZSB0aGF0IHlvdSBoYXZlIHRvIHVzZSBPdXRlciBUcmFuc3BvcnQgTGF5 ZXIgdG8gcGFzcyBpbmZvcm1hdGlvbg0KPj4+PiBhbW9uZyBTZXJ2aWNlIE5vZGVzLg0KPj4+Pg0K Pj4+PiBIb3dldmVyLCBJIHRoaW5rIHRoYXQgd2UgbmVlZCB0byBhY2tub3dsZWRnZSB0aGF0IG1h bnkgb2YgdG9kYXkncw0KPj4+PlNlcnZpY2UNCj4+Pj4gTm9kZXMsIGUuZy4gRlcsIExCLCBldGMs IGVzcGVjaWFsbHkgdGhlIG9uZXMgdGhhdCBhcmUgb25lIGxpbmsgYXdheQ0KPj4+PmZyb20NCj4+ Pj4gRm9yd2FyZGluZyBub2RlcywgZG9uJ3QgZXZlbiB1c2UgYW55IGFkZHJlc3Nlcy4gSWYgdGhl IEZvcndhcmRpbmcNCj4+Pj5ub2Rlcw0KPj4+PiBoYXZlIHRoZSBuZWVkZWQgdHJhZmZpYyBjbGFy aWZpY2F0aW9uIG1lYW5zLCB0aGV5IGNhbiBkaXJlY3QgdGhlDQo+Pj4+IHNlbGVjdGl2ZSB0cmFm ZmljIHRoYXQgbmVlZCB0aGUgIlNlcnZpY2UiIHRvIHRoZSBzZXJ2aWNlIG5vZGVzLg0KPj4+Pg0K Pj4+PiBJdCBpcyBub3QgIm9uZSBzaXplIiBmaXRzIGFsbCBmb3IgYWxsIFNlcnZpY2Ugbm9kZXMu DQo+Pj4+DQo+Pj4+IExpbmRhDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpu c2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+Pj4+PiBDYXJsb3MgUGlnbmF0YXJv IChjcGlnbmF0YSkNCj4+Pj4+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDA2LCAyMDEzIDEwOjI2 IEFNDQo+Pj4+PiBUbzogTGluZGEgRHVuYmFyDQo+Pj4+PiBDYzogbnNjQGlldGYub3JnOyBKaW0g R3VpY2hhcmQgKGpndWljaGFyKTsgTWVsaW5kYSBTaG9yZTsgUm9uIFBhcmtlcg0KPj4+Pj4gU3Vi amVjdDogUmU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCj4+Pj4+ DQo+Pj4+PiBIaSwgTGluZGEsDQo+Pj4+Pg0KPj4+Pj4gSSBoYXZlIHRvIGFkbWl0IHRoYXQgSSBh bSBhIGJpdCBsb3N0IHdpdGggdGhpcyBjb21tZW50IG9yIGEgY291cGxlIG9mDQo+Pj4+PiBwcmV2 aW91cyBvbmVzLiBDb25zZXF1ZW50bHksIEkgd2FudGVkIHRvIHNlbmQgYSAoaG9wZWZ1bGx5KQ0K Pj4+Pj5jbGFyaWZ5aW5nDQo+Pj4+PiBzdW1tYXJ5Lg0KPj4+Pj4NCj4+Pj4+IFRoZSBnb2FsIGlz IHRvIHNlbmQgYSBwYWNrZXQgKG9yaWdpbmFsLXBheWxvYWQgZnJvbSBhIHNlcnZpY2UNCj4+Pj4+ IHBlcnNwZWN0aXZlKSB3aXRoIGFkZGVkIHNlcnZpY2UgY29udGV4dCB0byBhIHNlcnZpY2Ugbm9k ZS4gVGhpcyBpcyBhDQo+Pj4+PiB0d28tc3RlcCBhcHByb2FjaDogd2UgY2FuIGNhbGwgdGhlIHN0 ZXBzIDEuIHNlcnZpY2UgKGlubmVyKSwgMi4NCj4+Pj4+IHRyYW5zcG9ydC4NCj4+Pj4+DQo+Pj4+ PiBBIHNlcnZpY2UgY2hhaW4gZGVmaW5lcyBhIHNldCBvZiBzZXJ2aWNlcyBhcHBsaWVkIHRvIGFu IG9yaWdpbmFsDQo+Pj4+PiBwYXlsb2FkLiBUbyBwcm92aWRlIGNoYWluIGNvbnRleHQsIHNlcnZp Y2UgcGF0aCBpZCwgY2xhc3NpZmljYXRpb24NCj4+Pj4+aW5mbywNCj4+Pj4+IGV0Yy4sIGEgc2Vy dmljZS1sZXZlbCBlbmNhcHN1bGF0aW9uL2hlYWRlciBpcyBhZGRlZC4gVGhpcyBzaG91bGQgYmUN Cj4+Pj4+IGVuY2Fwc3VsYXRpbmctbGF5ZXIgKHRyYW5zcG9ydC1sYXllcikgYWdub3N0aWMuIFNl Y29uZCwgaW4gb3JkZXIgZ2V0DQo+Pj4+PiB0aGF0IHRvIGEgc2VydmljZSBub2RlLCBpdCBnZXRz IGZ1cnRoZXIgZW5jYXBzdWxhdGVkIChpbiBJUCwgSVAvR1JFLA0KPj4+Pj4gSVAvVURQLCBWWExB TiwgTVBMUywgZXRjKSBmb3IgZGVsaXZlcnkuDQo+Pj4+Pg0KPj4+Pj4gQmVpbmcgYSBncmFwaGlj YWwgcGVyc29uLCBJIGFsc28gcmVhbGx5IGxpa2Ugd2hhdCBTdXJlbmRyYSBzaGFyZWQgYXQNCj4+ Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uc2MvY3VycmVudC9tc2cw MDMxMi5odG1sDQo+Pj4+Pg0KPj4+Pj4gSFRILA0KPj4+Pj4NCj4+Pj4+IC0tIENhcmxvcy4NCj4+ Pj4+DQo+Pj4+PiBPbiBTZXAgNiwgMjAxMywgYXQgMTA6MTcgQU0sIExpbmRhIER1bmJhciA8bGlu ZGEuZHVuYmFyQGh1YXdlaS5jb20+DQo+Pj4+PiB3cm90ZToNCj4+Pj4+DQo+Pj4+Pj4gUm9uLA0K Pj4+Pj4+DQo+Pj4+Pj4gR3JlYXQhICBJIGFtIGdsYWQgdG8gc2VlIHRoYXQgd2UgZ28gZG93biB0 aGlzIHBhdGguDQo+Pj4+Pj4gV2Ugc2hvdWxkIGFsc28gYWxsb3c6IC9lbmV0L2lwL3VkcCBvciB0 Y3AvbnNjLy4uLg0KPj4+Pj4+IGkuZS4gbm90IG5lY2Vzc2FyaWx5IGhhdmluZyBhbiBpbm5lciBJ UC4NCj4+Pj4+Pg0KPj4+Pj4+IExpbmRhDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBSb24gUGFya2VyIFttYWlsdG86Um9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NCj4+Pj4+Pj4gU2VudDogVGh1cnNkYXksIFNl cHRlbWJlciAwNSwgMjAxMyA2OjE2IFBNDQo+Pj4+Pj4+IFRvOiBMaW5kYSBEdW5iYXI7IEppbSBH dWljaGFyZCAoamd1aWNoYXIpOyBNZWxpbmRhIFNob3JlOw0KPj4+Pj4+PiBuc2NAaWV0Zi5vcmcN Cj4+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJv cG9zYWwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gSGksIExpbmRhLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBBcyBp dCB3YXMgcmVjZW50bHkgZXhwbGFpbmVkIG9uIHRoaXMgdGhyZWFkLCBJIGRvbid0IHRoaW5rIGl0 IG5lZWRzDQo+Pj4+Pj4+IHRvIGJlIG5lY2Vzc2FyeSB0byBhbHdheXMgaGF2ZSBpdCBpZiB3ZSBh cmUgd2lsbGluZyB0byBhbGxvdw0KPj4+Pj4gbXVsdGlwbGUNCj4+Pj4+Pj4gb3ZlcmFsbCAidHJh bnNwb3J0IitzZXJ2aWNlIGVuY2Fwc3VsYXRpb25zLiAgIEZvciBleGFtcGxlOg0KPj4+Pj4+Pg0K Pj4+Pj4+PiAvZW5ldC9pcC91ZHAvbnNjL2lwL3RjcC8uLi4NCj4+Pj4+Pj4gL2VuZXQvaXAvZ3Jl L25zYy9pcC90Y3AvLi4uDQo+Pj4+Pj4+IC9lbmV0L2xsYy1zbmFwL25zYy9pcC90Y3AvLi4uDQo+ Pj4+Pj4+IC9lbmV0L21wbHMvbnNjL2lwL3RjcC8uLi4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQXMgbXVj aCBhcyBJIGRvbid0IHRoaW5rIHdlJ2xsIGVuZCB1cCB0aGVyZSwgSSBkbyBmaW5kIGEgc2luZ2xl DQo+Pj4+Pj4+IG92ZXJhbGwgdW5pdmVyc2FsIHRyYW5zZm9ybWF0aW9uIHZlcnkgYXR0cmFjdGl2 ZSBhbmQgYW55IGZsYXZvcg0KPj4+Pj4+PnRoYXQNCj4+Pj4+Pj4gaXMgL3tsMn0vaXAveHh4L2lw L3RjcCB3b3VsZCBiZSB1bml2ZXJzYWxseSBhcHBsaWNhYmxlIC0tIHNhbWUNCj4+Pj4+IHN1Ym5l dA0KPj4+Pj4+PiBvciBkaWZmZXJlbnQgc3VibmV0LCBsMiBzd2l0Y2hlcyBhbmQvb3IgbDMgcm91 dGVycyBpbiBiZXR3ZWVuICwNCj4+Pj4+IE9wZW5GbG93DQo+Pj4+Pj4+IG9yIG5vdCBPcGVuRmxv dywgTVBMUyBvciBub3QgTVBMUywgLi4uICAgICBUaGUgYXJndW1lbnQgYWdhaW5zdA0KPj4+Pj4+ PnRoaXMNCj4+Pj4+Pj4gd2lsbCBiZSB0aGF0IHRoZSBwYWNrZXRzIGFyZSBiaWdnZXIgdGhhbiB0 aGV5IG5lZWQgdG8gYmUgZm9yIHNvbWUNCj4+Pj4+Pj4gbmV0d29yayB0b3BvbG9naWVzL3Byb3Rv Y29scy4gICBTaW1wbGljaXR5IG9yIGVmZmljaWVuY3k/DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgUm9u DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+Pj4+IEZyb206IExpbmRhIER1bmJhciBbbWFpbHRvOmxpbmRhLmR1bmJhckBo dWF3ZWkuY29tXQ0KPj4+Pj4+PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDA1LCAyMDEzIDU6 MTkgUE0NCj4+Pj4+Pj4gVG86IFJvbiBQYXJrZXI7IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBN ZWxpbmRhIFNob3JlOw0KPj4+Pj4+Pm5zY0BpZXRmLm9yZw0KPj4+Pj4+PiBTdWJqZWN0OiBSRTog W25zY10gTlNDIFdvcmtpbmcgR3JvdXAgQ2hhcnRlciBQcm9wb3NhbA0KPj4+Pj4+Pg0KPj4+Pj4+ PiBJIGNhbiBzZWUgdGhlIG5lZWQgZm9yIHRoaXMgIk5TQyIgaGVhZGVyIGluc2VydGVkIHRvIHRo ZSBwYWNrZXRzLA0KPj4+Pj4gYW5kDQo+Pj4+Pj4+IG9jY2FzaW9uYWxseSBuZWVkaW5nIGFuICJv dXRlci1pcCIgZW5jYXBzdWxhdGlvbiB0byBieS1wYXNzIG5vZGVzDQo+Pj4+Pj4+IHRoYXQgY2Fu J3QgcGFyc2UgdGhlICJOU0MiIGhlYWRlci4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQ2FuIHNvbWVvbmUg ZXhwbGFpbiB3aHkgaXQgaXMgbmVjZXNzYXJ5IHRvIGFsd2F5cyBoYXZlIHRoZSAib3V0ZXItDQo+ Pj4+PiBpcCINCj4+Pj4+Pj4gaGVhZGVyPw0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAJT3V0ZXItaXAvdWRw L25zYy9pbm5lci1pcC90Y3AvcGF5bG9hZA0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+ Pj4+PiBMaW5kYQ0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+Pj4+IG5zY0BpZXRmLm9yZw0K Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+DQo+ Pj4NCj4+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiBuc2MgbWFpbGluZyBsaXN0DQo+PiBuc2NAaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pg0KDQo= From linda.dunbar@huawei.com Fri Sep 6 09:50: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 0FB7811E82C3 for ; Fri, 6 Sep 2013 09:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 KzubiHEqC7qu for ; Fri, 6 Sep 2013 09:50:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E04911E81A7 for ; Fri, 6 Sep 2013 09:50:43 -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.5-GA FastPath queued) with ESMTP id AVC88997; Fri, 06 Sep 2013 16:50:42 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 17:50:19 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 17:50:42 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Fri, 6 Sep 2013 09:50:36 -0700 From: Linda Dunbar To: "Carlos Pignataro (cpignata)" , Jerome Moisand , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAJ5aAP//lE3ggAB58wD//5m/sIAAGcwQgAAwdeCAAP1hUIAAiQiA//+L0XAADyDKAAAOd6ew//+QLYCAAAEaAIAAcMYw//+Xw4CAAHMq8A== Date: Fri, 6 Sep 2013 16:50:36 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9EC1A@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645B9EB9A@dfweml509-mbx.china.huawei.com> <95067C434CE250468B77282634C96ED325EFFA37@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED325EFFA37@xmb-aln-x02.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.59] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 16:50:49 -0000 If the second sentence can be modified a little, (suggested below), then it= would be easier for new solutions to interoperate with today's service cha= in: A service-level header or a header field inserted into existing transport h= eader will be specified in order to enable interoperability of data plane c= omponents over existing networks (e.g., IP, MPLS, or others). Linda > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Carlos Pignataro (cpignata) > Sent: Friday, September 06, 2013 11:31 AM > To: Linda Dunbar; Jerome Moisand; nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal >=20 > Linda, >=20 > Several dozen emails ago, Jim sent the following -- what is your take? >=20 > --->8--- >=20 > 3) Service Chaining Data & Control Plane: A data plane document will > describe on the wire data plane encapsulation in support of (2). A > single > service-level encapsulation will be selected in order to enable > interoperability of data plane components, which can in turn be carried > in > various transport encapsulations (e.g., IP, MPLS, or other overlays). > Supporting control plane protocol elements will be added as needed (as > a > separate document). > --->8--- >=20 >=20 > Thanks, >=20 > -- Carlos. >=20 > On 9/6/13 12:21 PM, "Linda Dunbar" wrote: >=20 > >The discussion is about using "A Single Encapsulation.." in the > Charter. > > > >Even though it is ideal and everyone (myself included) loves it, but I > am > >afraid that not every Service Chain case will need outer encapsulation. > > > > > >Linda > >> -----Original Message----- > >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > >> Jerome Moisand > >> Sent: Friday, September 06, 2013 11:01 AM > >> To: nsc@ietf.org > >> Subject: Re: [nsc] NSC Working Group Charter Proposal > >> > >> Guys, could we please keep this discussion for later? We're supposed > to > >> discuss a charter here. Not a specific solution. > >> > >> Fair enough? > >> > >> -----Original Message----- > >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > >> Jim Guichard (jguichar) > >> Sent: Friday, September 06, 2013 11:57 AM > >> To: Linda Dunbar; Carlos Pignataro (cpignata) > >> Cc: nsc@ietf.org; Melinda Shore; Ron Parker > >> Subject: Re: [nsc] NSC Working Group Charter Proposal > >> > >> Then use routing. > >> > >> On 9/6/13 11:54 AM, "Linda Dunbar" wrote: > >> > >> >Jim, > >> > > >> >What if "A" and "B" in your example are today's existing nodes, > (they > >> >are not aware of NSC header) and the traffic between "A" and "B" > needs > >> >a sequence of service functions? > >> > > >> >Some service functions are one link away from forwarding nodes (or > >> >co-located), which may not require another layer of encapsulation. > But > >> >some service functions are accessible via multiple nodes, then > there > >> is > >> >need for another layer encapsulation. > >> > > >> >Linda > >> > > >> > > >> >> -----Original Message----- > >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > Behalf > >> Of > >> >> Jim Guichard (jguichar) > >> >> Sent: Friday, September 06, 2013 10:43 AM > >> >> To: Linda Dunbar; Carlos Pignataro (cpignata) > >> >> Cc: nsc@ietf.org; Melinda Shore; Ron Parker > >> >> Subject: Re: [nsc] NSC Working Group Charter Proposal > >> >> > >> >> Linda, > >> >> > >> >> I don=B9t think anyone is saying that you use outer transport layer > >> for > >> >> passing information among service nodes; to the contrary, the > outer > >> >> transport layer is simply used to get packets from point A to > point > >> B > >> >> and > >> >> *nothing* more. If point B happens to be a service node that is > >> >> acting on behalf of an attached service function then point B may > >> use > >> >> the service-encapsulation to figure out how to forward the packet > to > >> >> the right service function. > >> >> > >> >> On 9/6/13 11:36 AM, "Linda Dunbar" > wrote: > >> >> > >> >> >Carlos, > >> >> > > >> >> >I agree that you have to use Outer Transport Layer to pass > >> >> >information among Service Nodes. > >> >> > > >> >> >However, I think that we need to acknowledge that many of > today's > >> >> Service > >> >> >Nodes, e.g. FW, LB, etc, especially the ones that are one link > away > >> >> from > >> >> >Forwarding nodes, don't even use any addresses. If the > Forwarding > >> >> nodes > >> >> >have the needed traffic clarification means, they can direct the > >> >> >selective traffic that need the "Service" to the service nodes. > >> >> > > >> >> >It is not "one size" fits all for all Service nodes. > >> >> > > >> >> >Linda > >> >> > > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >> Behalf > >> >> Of > >> >> >> Carlos Pignataro (cpignata) > >> >> >> Sent: Friday, September 06, 2013 10:26 AM > >> >> >> To: Linda Dunbar > >> >> >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore; Ron > >> >> >> Parker > >> >> >> Subject: Re: [nsc] NSC Working Group Charter Proposal > >> >> >> > >> >> >> Hi, Linda, > >> >> >> > >> >> >> I have to admit that I am a bit lost with this comment or a > >> couple > >> >> of > >> >> >> previous ones. Consequently, I wanted to send a (hopefully) > >> >> clarifying > >> >> >> summary. > >> >> >> > >> >> >> The goal is to send a packet (original-payload from a service > >> >> >> perspective) with added service context to a service node. > This > >> is > >> >> >> a two-step approach: we can call the steps 1. service (inner), > 2. > >> >> >> transport. > >> >> >> > >> >> >> A service chain defines a set of services applied to an > original > >> >> >> payload. To provide chain context, service path id, > >> classification > >> >> info, > >> >> >> etc., a service-level encapsulation/header is added. This > should > >> >> >> be encapsulating-layer (transport-layer) agnostic. Second, in > >> >> >> order get that to a service node, it gets further encapsulated > >> (in > >> >> >> IP, IP/GRE, IP/UDP, VXLAN, MPLS, etc) for delivery. > >> >> >> > >> >> >> Being a graphical person, I also really like what Surendra > shared > >> >> >> at http://www.ietf.org/mail- > archive/web/nsc/current/msg00312.html > >> >> >> > >> >> >> HTH, > >> >> >> > >> >> >> -- Carlos. > >> >> >> > >> >> >> On Sep 6, 2013, at 10:17 AM, Linda Dunbar > >> >> >> > >> >> >> wrote: > >> >> >> > >> >> >> > Ron, > >> >> >> > > >> >> >> > Great! I am glad to see that we go down this path. > >> >> >> > We should also allow: /enet/ip/udp or tcp/nsc/... > >> >> >> > i.e. not necessarily having an inner IP. > >> >> >> > > >> >> >> > Linda > >> >> >> > > >> >> >> > > >> >> >> >> -----Original Message----- > >> >> >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> >> >> >> Sent: Thursday, September 05, 2013 6:16 PM > >> >> >> >> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; > >> >> >> >> nsc@ietf.org > >> >> >> >> Subject: RE: [nsc] NSC Working Group Charter Proposal > >> >> >> >> > >> >> >> >> Hi, Linda. > >> >> >> >> > >> >> >> >> As it was recently explained on this thread, I don't think > it > >> >> needs > >> >> >> >> to be necessary to always have it if we are willing to > allow > >> >> >> multiple > >> >> >> >> overall "transport"+service encapsulations. For example: > >> >> >> >> > >> >> >> >> /enet/ip/udp/nsc/ip/tcp/... > >> >> >> >> /enet/ip/gre/nsc/ip/tcp/... > >> >> >> >> /enet/llc-snap/nsc/ip/tcp/... > >> >> >> >> /enet/mpls/nsc/ip/tcp/... > >> >> >> >> > >> >> >> >> As much as I don't think we'll end up there, I do find a > >> single > >> >> >> >> overall universal transformation very attractive and any > >> flavor > >> >> that > >> >> >> >> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- > same > >> >> >> subnet > >> >> >> >> or different subnet, l2 switches and/or l3 routers in > between , > >> >> >> OpenFlow > >> >> >> >> or not OpenFlow, MPLS or not MPLS, ... The argument > >> against > >> >> this > >> >> >> >> will be that the packets are bigger than they need to be > for > >> some > >> >> >> >> network topologies/protocols. Simplicity or efficiency? > >> >> >> >> > >> >> >> >> Ron > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> -----Original Message----- > >> >> >> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > >> >> >> >> Sent: Thursday, September 05, 2013 5:19 PM > >> >> >> >> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; > >> >> nsc@ietf.org > >> >> >> >> Subject: RE: [nsc] NSC Working Group Charter Proposal > >> >> >> >> > >> >> >> >> I can see the need for this "NSC" header inserted to the > >> >> >> >> packets, > >> >> >> and > >> >> >> >> occasionally needing an "outer-ip" encapsulation to by-pass > >> >> >> >> nodes that can't parse the "NSC" header. > >> >> >> >> > >> >> >> >> Can someone explain why it is necessary to always have the > >> >> "outer- > >> >> >> ip" > >> >> >> >> header? > >> >> >> >> > >> >> >> >> > >> >> >> >>> -----Original Message----- > >> >> >> >>> > >> >> >> >>> Outer-ip/udp/nsc/inner-ip/tcp/payload > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> 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 > >> > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > >> > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ > >nsc mailing list > >nsc@ietf.org > >https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From mn1921@att.com Fri Sep 6 09:56:51 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D34C21E80C2 for ; Fri, 6 Sep 2013 09:56:51 -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 WN1+JqJ0Hpa8 for ; Fri, 6 Sep 2013 09:56:33 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7343211E81A7 for ; Fri, 6 Sep 2013 09:56:18 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 4390a225.2aaade823940.741574.00-570.2061589.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 06 Sep 2013 16:56:20 +0000 (UTC) X-MXL-Hash: 522a093459d7c31f-1673acc49369458fe5f5c7ca3a6a98c5a13ef524 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id e290a225.0.741563.00-408.2061441.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 06 Sep 2013 16:56:15 +0000 (UTC) X-MXL-Hash: 522a092f2bd78caa-018f8fa3e0682b0cf530b4d6e0be25c83d924e87 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 r86GuEKv013601; Fri, 6 Sep 2013 12:56:14 -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 r86Gu5rj013445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Sep 2013 12:56:10 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (MISOUT7MSGHUB9A.itservices.sbc.com [144.151.223.62]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 6 Sep 2013 16:56:00 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.03.0158.001; Fri, 6 Sep 2013 12:56:00 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , "Joachimpillai, Damascene M" , "Surendra Kumar (smkumar)" , Ron Parker , "Melinda Shore" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAGwQAIAADRKAgAABLgCAABHcAIAAAysAgAACOACAAAGvAIAAAUaAgAACnACAAAEsgIABIiWw Date: Fri, 6 Sep 2013 16:55:59 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E0123E805@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <689CE984BDBA8B4CAF3EA6E2CDC5CACB01233AF64A@FHDP1LUMXC7V31.us.one.verizon.com> <68B171751455884590F8E38E96416F363F677C06@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F677C06@xmb-rcd-x01.cisco.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="iso-8859-2" 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=FdKAMuC6 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=-s3I2kwCOWQA:10 a=u-E2M5yNkHcA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=-CRmgG0JhlAA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=qR7AGA33pQwA:10 a=48vgC7mUAAAA:8 a=ZsyXEVtvAAAA:8] X-AnalysisOut: [ a=AUd_NHdVAAAA:8 a=qN95wPeSAAAA:8 a=ZzeuTAqOfmxqhR7uL4UA:] X-AnalysisOut: [9 a=jiObf9B0YAUA:10 a=lZB815dzVvQA:10 a=TRFw3Wk1wdAA:10 a=] X-AnalysisOut: [JfD0Fch1gWkA:10 a=paC5pjApGzsA:10 a=P7vY44O81t3JXB6E:21 a=] X-AnalysisOut: [awIPsD1Pd7-R6vBx:21] Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 16:56:51 -0000 Service chain identifier is not absolutely necessary. Such information can = be implicit in the chain. Hence, carrying or not such an identifier should be made a matter of choice= . Maria > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Jim Guichard (jguichar) > Sent: Thursday, September 05, 2013 3:36 PM > To: Joachimpillai, Damascene M; Surendra Kumar (smkumar); Ron Parker; > Melinda Shore; nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal >=20 > That's something that we would debate within the WG and as Joel said it > is > perhaps premature to be discussing it now. However, to answer your > question, in the absence of metadata the minimum would be to carry a > service path identifier (that is used to identify a given service > chain) > and I would argue an index into the service chain (so that a receiving > network node is able to identify which of the service functions within > the > service chain it should apply). An example of what I am thinking is > given > in draft-quinn-nsh. >=20 > On 9/5/13 3:31 PM, "Joachimpillai, Damascene M" > wrote: >=20 > >So what is the encapsulation carrying? > > > >-- DJ > > > >-----Original Message----- > >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >Sent: Thursday, September 05, 2013 3:22 PM > >To: Joachimpillai, Damascene M; Surendra Kumar (smkumar); Ron Parker; > >Melinda Shore; nsc@ietf.org > >Subject: Re: [nsc] NSC Working Group Charter Proposal > > > >That is certainly one possibility (although not required for all > >services) and the data plane should enable that functionality yes. > > > >On 9/5/13 3:17 PM, "Joachimpillai, Damascene M" > > wrote: > > > >>Isnt all of these lead to carrying Metadata from application to > >>application? > >> > >>-- DJ > >> > >>-----Original Message----- > >>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > >>Jim Guichard (jguichar) > >>Sent: Thursday, September 05, 2013 3:12 PM > >>To: Surendra Kumar (smkumar); Ron Parker; Melinda Shore; nsc@ietf.org > >>Subject: Re: [nsc] NSC Working Group Charter Proposal > >> > >>Yes, this is what I have in mind exactly. Ron, let me know if this > does > >>not make sense. > >> > >>On 9/5/13 3:03 PM, "Surendra Kumar (smkumar)" > wrote: > >> > >>>Just to add, for clarity(hopefully). > >>> > >>>This is the intent: [Transport-Encapsulation/Header | > >>>Service-Encapsulaiton/Header | Original-payload] Where, > >>>Original-payload : an IP packet without the layer-2 header or > it > >>>could be a frame with the L2-header. This depends on the > interception > >>>layer. > >>>Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, > =A9 > >>>Service Encap : is where the service-path-identifier/... > Is > >>>carried in order to be able to identify the chain or the forwarding > >>>path. > >>> > >>>Surendra. > >>> > >>>On 9/5/13 11:52 AM, "Ron Parker" > >>>wrote: > >>> > >>>>Thanks for your patience, Jim! > >>>> > >>>>Does your description pre-suppose that there is always another IP > >>>>header > >>>>applied? For example, an original TCP segment could look like > this > >>>>(assuming UDP-based encap for this example): > >>>> > >>>> Outer-ip/udp/nsc/inner-ip/tcp/payload > >>>> > >>>>I can definitely get my head around that as it is a universal > >>>>solution that presumes an IP network, only. > >>>> > >>>>I may be misinterpreting but I suspect that some on this thread > >>>>aren't on the same page (at least yet) and may be thinking that in > >>>>certain network > >>>>topologies the outer IP can/should be avoided. If that is the > case, > >>>>I > >>>>can't see how the nsc information can be inserted after the > >>>>transport, which would create something that looks like this: > >>>> > >>>> Ip/tcp/nsc/payload > >>>> > >>>>Thanks. > >>>> > >>>> Ron > >>>> > >>>> > >>>>-----Original Message----- > >>>>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >>>>Sent: Thursday, September 05, 2013 1:49 PM > >>>>To: Ron Parker; Melinda Shore; nsc@ietf.org > >>>>Subject: Re: [nsc] NSC Working Group Charter Proposal > >>>> > >>>>Hi Ron, > >>>> > >>>>By encapsulation we mean something inserted between the transport > >>>>encapsulation and the original packet payload. There are two things > >>>>that need to happen; (1) identify that "service chaining" > information > >>>>follows the transport header, and (2) encapsulate the actual > service > >>>>chaining information. Now you could go down the path of trying to > >>>>force fit the service chaining information into the transport but > >>>>that imho is a mistake we should avoid. > >>>> > >>>>On 9/5/13 1:44 PM, "Ron Parker" > >>>>wrote: > >>>> > >>>>>I apologize if I'm being thick on this, but I'm still having > trouble > >>>>>with > >>>>>the meaning of "encapsulation" here. It has been pointed out > that it > >>>>>is > >>>>>the thing that carries information like chain id, hop index, and > >>>>>possibly metadata about the flow, but excludes the "overlay" > >>>>>encapsulation. > >>>>>So > >>>>>if I think about something that resembles GRE, when we say > >>>>>encapsulation, we are meaning the part of GRE that has the key but > >>>>>not the part of GRE > >>>>>that adds another IP header. Where I really get twisted around > the > >>>>>axle is if I think about this information being embedded in an > IPv4 > >>>>>option or IPv6 extension header. Not that we're necessarily > choosing > >>>>>those, but if we did, would we call that "encapsulation"? > >>>>> > >>>>>Thanks. > >>>>> > >>>>> Ron > >>>>> > >>>>> > >>>>>-----Original Message----- > >>>>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > >>>>>Of Melinda Shore > >>>>>Sent: Thursday, September 05, 2013 12:58 PM > >>>>>To: nsc@ietf.org > >>>>>Subject: Re: [nsc] NSC Working Group Charter Proposal > >>>>> > >>>>>On 9/5/13 6:45 AM, Linda Dunbar wrote: > >>>>>> This version hasn't addressed the comments on Bullet 3 of > >>>>>>requiring a single encapsulation being too limiting or may not > >>>>>>even be realistic. > >>>>> > >>>>>There's no agreement that that's the case. > >>>>> > >>>>>Melinda > >>>>> > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>nsc mailing list > >>>>>nsc@ietf.org > >>>>>https://www.ietf.org/mailman/listinfo/nsc > >>>>>_______________________________________________ > >>>>>nsc mailing list > >>>>>nsc@ietf.org > >>>>>https://www.ietf.org/mailman/listinfo/nsc > >>>> > >>>>_______________________________________________ > >>>>nsc mailing list > >>>>nsc@ietf.org > >>>>https://www.ietf.org/mailman/listinfo/nsc > >>> > >> > >>_______________________________________________ > >>nsc mailing list > >>nsc@ietf.org > >>https://www.ietf.org/mailman/listinfo/nsc > > >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Fri Sep 6 10:06: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 96F0A11E8199 for ; Fri, 6 Sep 2013 10:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.319 X-Spam-Level: X-Spam-Status: No, score=-6.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 jNwIsTMvvHSp for ; Fri, 6 Sep 2013 10:06:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C5B2921E80C3 for ; Fri, 6 Sep 2013 10:06:34 -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.5-GA FastPath queued) with ESMTP id AVC89764; Fri, 06 Sep 2013 17:06:34 +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, 6 Sep 2013 18:06:11 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 18:06:33 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.227]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Fri, 6 Sep 2013 10:06:28 -0700 From: Linda Dunbar To: "NAPIERALA, MARIA H" , "Jim Guichard (jguichar)" , "Joachimpillai, Damascene M" , "Surendra Kumar (smkumar)" , Ron Parker , "Melinda Shore" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAGwQAIAADRKAgAABLgCAABHcAIAAAysAgAACOACAAAGvAIAAAUaAgAACnACAAAEsgIABIiWwgAAChLA= Date: Fri, 6 Sep 2013 17:06:27 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B9EC92@dfweml509-mbx.china.huawei.com> References: <689CE984BDBA8B4CAF3EA6E2CDC5CACB01233AF64A@FHDP1LUMXC7V31.us.one.verizon.com> <68B171751455884590F8E38E96416F363F677C06@xmb-rcd-x01.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E0123E805@MISOUT7MSGUSR9I.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E0123E805@MISOUT7MSGUSR9I.ITServices.sbc.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.59] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 17:06:40 -0000 Agree strongly of Maria's statement.=20 The existing identifiers, like MPSL tag, etc., can also be used to identify= Service Chain for cases of service functions that don't need to pass infor= mation among them or to the forwarding nodes.=20 Linda > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > NAPIERALA, MARIA H > Sent: Friday, September 06, 2013 11:56 AM > To: Jim Guichard (jguichar); Joachimpillai, Damascene M; Surendra Kumar > (smkumar); Ron Parker; Melinda Shore; nsc@ietf.org > Subject: Re: [nsc] NSC Working Group Charter Proposal >=20 > Service chain identifier is not absolutely necessary. Such information > can be implicit in the chain. > Hence, carrying or not such an identifier should be made a matter of > choice. >=20 > Maria >=20 > > -----Original Message----- > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > > Jim Guichard (jguichar) > > Sent: Thursday, September 05, 2013 3:36 PM > > To: Joachimpillai, Damascene M; Surendra Kumar (smkumar); Ron Parker; > > Melinda Shore; nsc@ietf.org > > Subject: Re: [nsc] NSC Working Group Charter Proposal > > > > That's something that we would debate within the WG and as Joel said > it > > is > > perhaps premature to be discussing it now. However, to answer your > > question, in the absence of metadata the minimum would be to carry a > > service path identifier (that is used to identify a given service > > chain) > > and I would argue an index into the service chain (so that a > receiving > > network node is able to identify which of the service functions > within > > the > > service chain it should apply). An example of what I am thinking is > > given > > in draft-quinn-nsh. > > > > On 9/5/13 3:31 PM, "Joachimpillai, Damascene M" > > wrote: > > > > >So what is the encapsulation carrying? > > > > > >-- DJ > > > > > >-----Original Message----- > > >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > >Sent: Thursday, September 05, 2013 3:22 PM > > >To: Joachimpillai, Damascene M; Surendra Kumar (smkumar); Ron Parker; > > >Melinda Shore; nsc@ietf.org > > >Subject: Re: [nsc] NSC Working Group Charter Proposal > > > > > >That is certainly one possibility (although not required for all > > >services) and the data plane should enable that functionality yes. > > > > > >On 9/5/13 3:17 PM, "Joachimpillai, Damascene M" > > > wrote: > > > > > >>Isnt all of these lead to carrying Metadata from application to > > >>application? > > >> > > >>-- DJ > > >> > > >>-----Original Message----- > > >>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > > >>Jim Guichard (jguichar) > > >>Sent: Thursday, September 05, 2013 3:12 PM > > >>To: Surendra Kumar (smkumar); Ron Parker; Melinda Shore; > nsc@ietf.org > > >>Subject: Re: [nsc] NSC Working Group Charter Proposal > > >> > > >>Yes, this is what I have in mind exactly. Ron, let me know if this > > does > > >>not make sense. > > >> > > >>On 9/5/13 3:03 PM, "Surendra Kumar (smkumar)" > > wrote: > > >> > > >>>Just to add, for clarity(hopefully). > > >>> > > >>>This is the intent: [Transport-Encapsulation/Header | > > >>>Service-Encapsulaiton/Header | Original-payload] Where, > > >>>Original-payload : an IP packet without the layer-2 header > or > > it > > >>>could be a frame with the L2-header. This depends on the > > interception > > >>>layer. > > >>>Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, > > =A9 > > >>>Service Encap : is where the service-path-identifier/... > > Is > > >>>carried in order to be able to identify the chain or the > forwarding > > >>>path. > > >>> > > >>>Surendra. > > >>> > > >>>On 9/5/13 11:52 AM, "Ron Parker" > > >>>wrote: > > >>> > > >>>>Thanks for your patience, Jim! > > >>>> > > >>>>Does your description pre-suppose that there is always another IP > > >>>>header > > >>>>applied? For example, an original TCP segment could look like > > this > > >>>>(assuming UDP-based encap for this example): > > >>>> > > >>>> Outer-ip/udp/nsc/inner-ip/tcp/payload > > >>>> > > >>>>I can definitely get my head around that as it is a universal > > >>>>solution that presumes an IP network, only. > > >>>> > > >>>>I may be misinterpreting but I suspect that some on this thread > > >>>>aren't on the same page (at least yet) and may be thinking that > in > > >>>>certain network > > >>>>topologies the outer IP can/should be avoided. If that is the > > case, > > >>>>I > > >>>>can't see how the nsc information can be inserted after the > > >>>>transport, which would create something that looks like this: > > >>>> > > >>>> Ip/tcp/nsc/payload > > >>>> > > >>>>Thanks. > > >>>> > > >>>> Ron > > >>>> > > >>>> > > >>>>-----Original Message----- > > >>>>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > >>>>Sent: Thursday, September 05, 2013 1:49 PM > > >>>>To: Ron Parker; Melinda Shore; nsc@ietf.org > > >>>>Subject: Re: [nsc] NSC Working Group Charter Proposal > > >>>> > > >>>>Hi Ron, > > >>>> > > >>>>By encapsulation we mean something inserted between the transport > > >>>>encapsulation and the original packet payload. There are two > things > > >>>>that need to happen; (1) identify that "service chaining" > > information > > >>>>follows the transport header, and (2) encapsulate the actual > > service > > >>>>chaining information. Now you could go down the path of trying to > > >>>>force fit the service chaining information into the transport but > > >>>>that imho is a mistake we should avoid. > > >>>> > > >>>>On 9/5/13 1:44 PM, "Ron Parker" > > >>>>wrote: > > >>>> > > >>>>>I apologize if I'm being thick on this, but I'm still having > > trouble > > >>>>>with > > >>>>>the meaning of "encapsulation" here. It has been pointed out > > that it > > >>>>>is > > >>>>>the thing that carries information like chain id, hop index, and > > >>>>>possibly metadata about the flow, but excludes the "overlay" > > >>>>>encapsulation. > > >>>>>So > > >>>>>if I think about something that resembles GRE, when we say > > >>>>>encapsulation, we are meaning the part of GRE that has the key > but > > >>>>>not the part of GRE > > >>>>>that adds another IP header. Where I really get twisted > around > > the > > >>>>>axle is if I think about this information being embedded in an > > IPv4 > > >>>>>option or IPv6 extension header. Not that we're necessarily > > choosing > > >>>>>those, but if we did, would we call that "encapsulation"? > > >>>>> > > >>>>>Thanks. > > >>>>> > > >>>>> Ron > > >>>>> > > >>>>> > > >>>>>-----Original Message----- > > >>>>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > Behalf > > >>>>>Of Melinda Shore > > >>>>>Sent: Thursday, September 05, 2013 12:58 PM > > >>>>>To: nsc@ietf.org > > >>>>>Subject: Re: [nsc] NSC Working Group Charter Proposal > > >>>>> > > >>>>>On 9/5/13 6:45 AM, Linda Dunbar wrote: > > >>>>>> This version hasn't addressed the comments on Bullet 3 of > > >>>>>>requiring a single encapsulation being too limiting or may not > > >>>>>>even be realistic. > > >>>>> > > >>>>>There's no agreement that that's the case. > > >>>>> > > >>>>>Melinda > > >>>>> > > >>>>> > > >>>>> > > >>>>>_______________________________________________ > > >>>>>nsc mailing list > > >>>>>nsc@ietf.org > > >>>>>https://www.ietf.org/mailman/listinfo/nsc > > >>>>>_______________________________________________ > > >>>>>nsc mailing list > > >>>>>nsc@ietf.org > > >>>>>https://www.ietf.org/mailman/listinfo/nsc > > >>>> > > >>>>_______________________________________________ > > >>>>nsc mailing list > > >>>>nsc@ietf.org > > >>>>https://www.ietf.org/mailman/listinfo/nsc > > >>> > > >> > > >>_______________________________________________ > > >>nsc mailing list > > >>nsc@ietf.org > > >>https://www.ietf.org/mailman/listinfo/nsc > > > > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From melinda.shore@gmail.com Fri Sep 6 10:19: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 132BA11E82DE for ; Fri, 6 Sep 2013 10:19:54 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHfN-DTn-0iu for ; Fri, 6 Sep 2013 10:19:53 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1A64511E80E0 for ; Fri, 6 Sep 2013 10:18:56 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so3590477pad.5 for ; Fri, 06 Sep 2013 10:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Js87tjTFVIsB0/D37eR8SYVhUEMqbkYAkKqV0ZeA5lg=; b=pQTBZDAM0TWfT7VpvVStvTlBKPr/Z6qLc9NojS2YPNyWWNy7rlvyHyOnKtPR9pOcGK pSjSf7wRLYht6UVFJvsnmMOjlAysDFoa6F3ws6EGtNXNKdZ/b1qk7EG+pP9sEx70SVrM JwOWXiSZn2YhRrxEhCFhFfluW2dzStBVzxP8YnrTlACR7Fb3hYtQicnITZUiwDTQeFTn PENXmRxiCJ41Ysd+p3JkzPAdxlnIVnqOwhhIoWLHVphkELKTxLLlufe5eANWL/iMqzdz A2dM365rloiGyYC+K8TVxXIcjz7sXHGfhxlErMyrqFnfW1U4nf7AlqjniKohx1mLjL8k MMbA== X-Received: by 10.66.146.42 with SMTP id sz10mr5319990pab.100.1378487936693; Fri, 06 Sep 2013 10:18:56 -0700 (PDT) Received: from spandex.local (66-230-112-61-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.112.61]) by mx.google.com with ESMTPSA id gh9sm892289pbc.40.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Sep 2013 10:18:56 -0700 (PDT) Message-ID: <522A0E7D.1010609@gmail.com> Date: Fri, 06 Sep 2013 09:18:53 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Linda Dunbar References: <689CE984BDBA8B4CAF3EA6E2CDC5CACB01233AF64A@FHDP1LUMXC7V31.us.one.verizon.com> <68B171751455884590F8E38E96416F363F677C06@xmb-rcd-x01.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E0123E805@MISOUT7MSGUSR9I.ITServices.sbc.com> <4A95BA014132FF49AE685FAB4B9F17F645B9EC92@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9EC92@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Cc: "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , "Joachimpillai, Damascene M" , "Jim Guichard \(jguichar\)" , "NAPIERALA, MARIA H" , Ron Parker Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 17:19:54 -0000 On 9/6/13 9:06 AM, Linda Dunbar wrote: > The existing identifiers, like MPSL tag, etc., can also be used to > identify Service Chain for cases of service functions that don't need > to pass information among them or to the forwarding nodes. In the IETF we often talk about complexity being one of the primary sources of various kinds of protocol problems - interoperability problems, security problems, implementation difficulty, the need to profile, etc. Providing options that are not *required* to solve the problem at hand is one obvious source of complexity. Melinda From jguichar@cisco.com Fri Sep 6 10:20: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 CE19911E81A7 for ; Fri, 6 Sep 2013 10:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.635 X-Spam-Level: X-Spam-Status: No, score=-9.635 tagged_above=-999 required=5 tests=[AWL=-0.789, 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 4od8+JjiyHl8 for ; Fri, 6 Sep 2013 10:19:56 -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 53CBB11E81C5 for ; Fri, 6 Sep 2013 10:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15150; q=dns/txt; s=iport; t=1378487961; x=1379697561; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=uCaQDtlmw8PgEdNJ8rOLn9VsljN3STG3LLInrriVhJs=; b=Vk7+gngieP34xjjACYBq0dbRQgM2KwSZt3ETjCundJFU97QA2PhEC4hd hzDZUOxN1e5M5s4vBxXqZgUJjQ3UHG/EQ76QYrfMuayisYD7mNPbQK2HE 6EHWCUcxbLnZ1GwJXWLMYdV386HKCpkbbaScr56Ci9EZn/QGRnMfeOj9y k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgFAJ0NKlKtJV2Z/2dsb2JhbABbgwc1SwaDKr4rF4EPFnSCJAEBAQQBAQEkDTMHFwYBCBEEAQEBBAYdBQQlCxQJCAIEARIIARKHZwcFkQ6bRAaRL4EjjSCBBgIWIgaCXTqBAAOUG5AUhSyDIIFxOQ X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="scan'208";a="256534534" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 06 Sep 2013 17:19:19 +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 r86HJJpT021494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 17:19:19 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 12:19:18 -0500 From: "Jim Guichard (jguichar)" To: Linda Dunbar , "Carlos Pignataro (cpignata)" , Jerome Moisand , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAIAAKPeAgAAgwgCAAPvEAIAAEw+AgAADDoD//764AIAARk2A//+9noAACIVqAAAAtTMA//+/z4CAAEhqAP//xPQA Date: Fri, 6 Sep 2013 17:19:18 +0000 Message-ID: <68B171751455884590F8E38E96416F363F678D2C@xmb-rcd-x01.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9EC1A@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.246.115] Content-Type: text/plain; charset="euc-kr" Content-ID: <0998F85E75417E47AFEE7FBE67127760@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 17:20:02 -0000 VGhlIGN1cnJlbnQgd29yZGluZyBvZiB0aGUgZmlyc3Qgc2VudGVuY2Ugb2Ygd29yayBpdGVtIDMp IGlzIGltbyBhZGVxdWF0ZQ0KdG8gYWRkcmVzcyB0aGlzLiANCg0KT24gOS82LzEzIDEyOjUwIFBN LCAiTGluZGEgRHVuYmFyIiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+SWYg dGhlIHNlY29uZCBzZW50ZW5jZSBjYW4gYmUgbW9kaWZpZWQgYSBsaXR0bGUsIChzdWdnZXN0ZWQg YmVsb3cpLCB0aGVuDQo+aXQgd291bGQgYmUgZWFzaWVyIGZvciBuZXcgc29sdXRpb25zIHRvIGlu dGVyb3BlcmF0ZSB3aXRoIHRvZGF5J3Mgc2VydmljZQ0KPmNoYWluOg0KPg0KPg0KPkEgc2Vydmlj ZS1sZXZlbCBoZWFkZXIgb3IgYSBoZWFkZXIgZmllbGQgaW5zZXJ0ZWQgaW50byBleGlzdGluZyB0 cmFuc3BvcnQNCj5oZWFkZXIgd2lsbCBiZSBzcGVjaWZpZWQgaW4gb3JkZXIgdG8gZW5hYmxlIGlu dGVyb3BlcmFiaWxpdHkgb2YgZGF0YQ0KPnBsYW5lIGNvbXBvbmVudHMgb3ZlciBleGlzdGluZyBu ZXR3b3JrcyAoZS5nLiwgSVAsIE1QTFMsIG9yIG90aGVycykuDQo+DQo+DQo+TGluZGENCj4NCj4N Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+IENhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKQ0KPj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMDYsIDIw MTMgMTE6MzEgQU0NCj4+IFRvOiBMaW5kYSBEdW5iYXI7IEplcm9tZSBNb2lzYW5kOyBuc2NAaWV0 Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBOU0MgV29ya2luZyBHcm91cCBDaGFydGVyIFBy b3Bvc2FsDQo+PiANCj4+IExpbmRhLA0KPj4gDQo+PiBTZXZlcmFsIGRvemVuIGVtYWlscyBhZ28s IEppbSBzZW50IHRoZSBmb2xsb3dpbmcgLS0gd2hhdCBpcyB5b3VyIHRha2U/DQo+PiANCj4+IC0t LT44LS0tDQo+PiANCj4+IDMpIFNlcnZpY2UgQ2hhaW5pbmcgRGF0YSAmIENvbnRyb2wgUGxhbmU6 IEEgZGF0YSBwbGFuZSBkb2N1bWVudCB3aWxsDQo+PiBkZXNjcmliZSBvbiB0aGUgd2lyZSBkYXRh IHBsYW5lIGVuY2Fwc3VsYXRpb24gaW4gc3VwcG9ydCBvZiAoMikuIEENCj4+IHNpbmdsZQ0KPj4g c2VydmljZS1sZXZlbCBlbmNhcHN1bGF0aW9uIHdpbGwgYmUgc2VsZWN0ZWQgaW4gb3JkZXIgdG8g ZW5hYmxlDQo+PiBpbnRlcm9wZXJhYmlsaXR5IG9mIGRhdGEgcGxhbmUgY29tcG9uZW50cywgd2hp Y2ggY2FuIGluIHR1cm4gYmUgY2FycmllZA0KPj4gaW4NCj4+IHZhcmlvdXMgdHJhbnNwb3J0IGVu Y2Fwc3VsYXRpb25zIChlLmcuLCBJUCwgTVBMUywgb3Igb3RoZXIgb3ZlcmxheXMpLg0KPj4gU3Vw cG9ydGluZyBjb250cm9sIHBsYW5lIHByb3RvY29sIGVsZW1lbnRzIHdpbGwgYmUgYWRkZWQgYXMg bmVlZGVkIChhcw0KPj4gYQ0KPj4gc2VwYXJhdGUgZG9jdW1lbnQpLg0KPj4gLS0tPjgtLS0NCj4+ IA0KPj4gDQo+PiBUaGFua3MsDQo+PiANCj4+IC0tIENhcmxvcy4NCj4+IA0KPj4gT24gOS82LzEz IDEyOjIxIFBNLCAiTGluZGEgRHVuYmFyIiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3Rl Og0KPj4gDQo+PiA+VGhlIGRpc2N1c3Npb24gaXMgYWJvdXQgdXNpbmcgIkEgU2luZ2xlIEVuY2Fw c3VsYXRpb24uLiIgaW4gdGhlDQo+PiBDaGFydGVyLg0KPj4gPg0KPj4gPkV2ZW4gdGhvdWdoIGl0 IGlzIGlkZWFsIGFuZCBldmVyeW9uZSAobXlzZWxmIGluY2x1ZGVkKSBsb3ZlcyBpdCwgYnV0IEkN Cj4+IGFtDQo+PiA+YWZyYWlkIHRoYXQgbm90IGV2ZXJ5IFNlcnZpY2UgQ2hhaW4gY2FzZSB3aWxs IG5lZWQgb3V0ZXIgZW5jYXBzdWxhdGlvbi4NCj4+ID4NCj4+ID4NCj4+ID5MaW5kYQ0KPj4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4gT2YNCj4+ID4+ IEplcm9tZSBNb2lzYW5kDQo+PiA+PiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAwNiwgMjAxMyAx MTowMSBBTQ0KPj4gPj4gVG86IG5zY0BpZXRmLm9yZw0KPj4gPj4gU3ViamVjdDogUmU6IFtuc2Nd IE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCj4+ID4+DQo+PiA+PiBHdXlzLCBj b3VsZCB3ZSBwbGVhc2Uga2VlcCB0aGlzIGRpc2N1c3Npb24gZm9yIGxhdGVyPyBXZSdyZSBzdXBw b3NlZA0KPj4gdG8NCj4+ID4+IGRpc2N1c3MgYSBjaGFydGVyIGhlcmUuIE5vdCBhIHNwZWNpZmlj IHNvbHV0aW9uLg0KPj4gPj4NCj4+ID4+IEZhaXIgZW5vdWdoPw0KPj4gPj4NCj4+ID4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+IE9mDQo+PiA+PiBKaW0g R3VpY2hhcmQgKGpndWljaGFyKQ0KPj4gPj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMDYsIDIw MTMgMTE6NTcgQU0NCj4+ID4+IFRvOiBMaW5kYSBEdW5iYXI7IENhcmxvcyBQaWduYXRhcm8gKGNw aWduYXRhKQ0KPj4gPj4gQ2M6IG5zY0BpZXRmLm9yZzsgTWVsaW5kYSBTaG9yZTsgUm9uIFBhcmtl cg0KPj4gPj4gU3ViamVjdDogUmU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJv cG9zYWwNCj4+ID4+DQo+PiA+PiBUaGVuIHVzZSByb3V0aW5nLg0KPj4gPj4NCj4+ID4+IE9uIDkv Ni8xMyAxMTo1NCBBTSwgIkxpbmRhIER1bmJhciIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPiB3 cm90ZToNCj4+ID4+DQo+PiA+PiA+SmltLA0KPj4gPj4gPg0KPj4gPj4gPldoYXQgaWYgIkEiIGFu ZCAiQiIgaW4geW91ciBleGFtcGxlIGFyZSB0b2RheSdzIGV4aXN0aW5nIG5vZGVzLA0KPj4gKHRo ZXkNCj4+ID4+ID5hcmUgbm90IGF3YXJlIG9mIE5TQyBoZWFkZXIpIGFuZCB0aGUgdHJhZmZpYyBi ZXR3ZWVuICJBIiBhbmQgIkIiDQo+PiBuZWVkcw0KPj4gPj4gPmEgc2VxdWVuY2Ugb2Ygc2Vydmlj ZSBmdW5jdGlvbnM/DQo+PiA+PiA+DQo+PiA+PiA+U29tZSBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUg b25lIGxpbmsgYXdheSBmcm9tIGZvcndhcmRpbmcgbm9kZXMgKG9yDQo+PiA+PiA+Y28tbG9jYXRl ZCksIHdoaWNoIG1heSBub3QgcmVxdWlyZSBhbm90aGVyIGxheWVyIG9mIGVuY2Fwc3VsYXRpb24u DQo+PiBCdXQNCj4+ID4+ID5zb21lIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBhY2Nlc3NpYmxlIHZp YSBtdWx0aXBsZSBub2RlcywgdGhlbg0KPj4gdGhlcmUNCj4+ID4+IGlzDQo+PiA+PiA+bmVlZCBm b3IgYW5vdGhlciBsYXllciBlbmNhcHN1bGF0aW9uLg0KPj4gPj4gPg0KPj4gPj4gPkxpbmRhDQo+ PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g Pj4gPj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRm Lm9yZ10gT24NCj4+IEJlaGFsZg0KPj4gPj4gT2YNCj4+ID4+ID4+IEppbSBHdWljaGFyZCAoamd1 aWNoYXIpDQo+PiA+PiA+PiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAwNiwgMjAxMyAxMDo0MyBB TQ0KPj4gPj4gPj4gVG86IExpbmRhIER1bmJhcjsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEp DQo+PiA+PiA+PiBDYzogbnNjQGlldGYub3JnOyBNZWxpbmRhIFNob3JlOyBSb24gUGFya2VyDQo+ PiA+PiA+PiBTdWJqZWN0OiBSZTogW25zY10gTlNDIFdvcmtpbmcgR3JvdXAgQ2hhcnRlciBQcm9w b3NhbA0KPj4gPj4gPj4NCj4+ID4+ID4+IExpbmRhLA0KPj4gPj4gPj4NCj4+ID4+ID4+IEkgZG9u qfZ0IHRoaW5rIGFueW9uZSBpcyBzYXlpbmcgdGhhdCB5b3UgdXNlIG91dGVyIHRyYW5zcG9ydCBs YXllcg0KPj4gPj4gZm9yDQo+PiA+PiA+PiBwYXNzaW5nIGluZm9ybWF0aW9uIGFtb25nIHNlcnZp Y2Ugbm9kZXM7IHRvIHRoZSBjb250cmFyeSwgdGhlDQo+PiBvdXRlcg0KPj4gPj4gPj4gdHJhbnNw b3J0IGxheWVyIGlzIHNpbXBseSB1c2VkIHRvIGdldCBwYWNrZXRzIGZyb20gcG9pbnQgQSB0bw0K Pj4gcG9pbnQNCj4+ID4+IEINCj4+ID4+ID4+IGFuZA0KPj4gPj4gPj4gKm5vdGhpbmcqIG1vcmUu IElmIHBvaW50IEIgaGFwcGVucyB0byBiZSBhIHNlcnZpY2Ugbm9kZSB0aGF0IGlzDQo+PiA+PiA+ PiBhY3Rpbmcgb24gYmVoYWxmIG9mIGFuIGF0dGFjaGVkIHNlcnZpY2UgZnVuY3Rpb24gdGhlbiBw b2ludCBCIG1heQ0KPj4gPj4gdXNlDQo+PiA+PiA+PiB0aGUgc2VydmljZS1lbmNhcHN1bGF0aW9u IHRvIGZpZ3VyZSBvdXQgaG93IHRvIGZvcndhcmQgdGhlIHBhY2tldA0KPj4gdG8NCj4+ID4+ID4+ IHRoZSByaWdodCBzZXJ2aWNlIGZ1bmN0aW9uLg0KPj4gPj4gPj4NCj4+ID4+ID4+IE9uIDkvNi8x MyAxMTozNiBBTSwgIkxpbmRhIER1bmJhciIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPg0KPj4g d3JvdGU6DQo+PiA+PiA+Pg0KPj4gPj4gPj4gPkNhcmxvcywNCj4+ID4+ID4+ID4NCj4+ID4+ID4+ ID5JIGFncmVlIHRoYXQgeW91IGhhdmUgdG8gdXNlIE91dGVyIFRyYW5zcG9ydCBMYXllciB0byBw YXNzDQo+PiA+PiA+PiA+aW5mb3JtYXRpb24gYW1vbmcgU2VydmljZSBOb2Rlcy4NCj4+ID4+ID4+ ID4NCj4+ID4+ID4+ID5Ib3dldmVyLCBJIHRoaW5rIHRoYXQgd2UgbmVlZCB0byBhY2tub3dsZWRn ZSB0aGF0IG1hbnkgb2YNCj4+IHRvZGF5J3MNCj4+ID4+ID4+IFNlcnZpY2UNCj4+ID4+ID4+ID5O b2RlcywgZS5nLiBGVywgTEIsIGV0YywgZXNwZWNpYWxseSB0aGUgb25lcyB0aGF0IGFyZSBvbmUg bGluaw0KPj4gYXdheQ0KPj4gPj4gPj4gZnJvbQ0KPj4gPj4gPj4gPkZvcndhcmRpbmcgbm9kZXMs IGRvbid0IGV2ZW4gdXNlIGFueSBhZGRyZXNzZXMuIElmIHRoZQ0KPj4gRm9yd2FyZGluZw0KPj4g Pj4gPj4gbm9kZXMNCj4+ID4+ID4+ID5oYXZlIHRoZSBuZWVkZWQgdHJhZmZpYyBjbGFyaWZpY2F0 aW9uIG1lYW5zLCB0aGV5IGNhbiBkaXJlY3QgdGhlDQo+PiA+PiA+PiA+c2VsZWN0aXZlIHRyYWZm aWMgdGhhdCBuZWVkIHRoZSAiU2VydmljZSIgdG8gdGhlIHNlcnZpY2Ugbm9kZXMuDQo+PiA+PiA+ PiA+DQo+PiA+PiA+PiA+SXQgaXMgbm90ICJvbmUgc2l6ZSIgZml0cyBhbGwgZm9yIGFsbCBTZXJ2 aWNlIG5vZGVzLg0KPj4gPj4gPj4gPg0KPj4gPj4gPj4gPkxpbmRhDQo+PiA+PiA+PiA+DQo+PiA+ PiA+PiA+DQo+PiA+PiA+PiA+DQo+PiA+PiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4gPj4gPj4gPj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91 bmNlc0BpZXRmLm9yZ10gT24NCj4+ID4+IEJlaGFsZg0KPj4gPj4gPj4gT2YNCj4+ID4+ID4+ID4+ IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0KPj4gPj4gPj4gPj4gU2VudDogRnJpZGF5LCBT ZXB0ZW1iZXIgMDYsIDIwMTMgMTA6MjYgQU0NCj4+ID4+ID4+ID4+IFRvOiBMaW5kYSBEdW5iYXIN Cj4+ID4+ID4+ID4+IENjOiBuc2NAaWV0Zi5vcmc7IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBN ZWxpbmRhIFNob3JlOyBSb24NCj4+ID4+ID4+ID4+IFBhcmtlcg0KPj4gPj4gPj4gPj4gU3ViamVj dDogUmU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwNCj4+ID4+ID4+ ID4+DQo+PiA+PiA+PiA+PiBIaSwgTGluZGEsDQo+PiA+PiA+PiA+Pg0KPj4gPj4gPj4gPj4gSSBo YXZlIHRvIGFkbWl0IHRoYXQgSSBhbSBhIGJpdCBsb3N0IHdpdGggdGhpcyBjb21tZW50IG9yIGEN Cj4+ID4+IGNvdXBsZQ0KPj4gPj4gPj4gb2YNCj4+ID4+ID4+ID4+IHByZXZpb3VzIG9uZXMuIENv bnNlcXVlbnRseSwgSSB3YW50ZWQgdG8gc2VuZCBhIChob3BlZnVsbHkpDQo+PiA+PiA+PiBjbGFy aWZ5aW5nDQo+PiA+PiA+PiA+PiBzdW1tYXJ5Lg0KPj4gPj4gPj4gPj4NCj4+ID4+ID4+ID4+IFRo ZSBnb2FsIGlzIHRvIHNlbmQgYSBwYWNrZXQgKG9yaWdpbmFsLXBheWxvYWQgZnJvbSBhIHNlcnZp Y2UNCj4+ID4+ID4+ID4+IHBlcnNwZWN0aXZlKSB3aXRoIGFkZGVkIHNlcnZpY2UgY29udGV4dCB0 byBhIHNlcnZpY2Ugbm9kZS4NCj4+IFRoaXMNCj4+ID4+IGlzDQo+PiA+PiA+PiA+PiBhIHR3by1z dGVwIGFwcHJvYWNoOiB3ZSBjYW4gY2FsbCB0aGUgc3RlcHMgMS4gc2VydmljZSAoaW5uZXIpLA0K Pj4gMi4NCj4+ID4+ID4+ID4+IHRyYW5zcG9ydC4NCj4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiBB IHNlcnZpY2UgY2hhaW4gZGVmaW5lcyBhIHNldCBvZiBzZXJ2aWNlcyBhcHBsaWVkIHRvIGFuDQo+ PiBvcmlnaW5hbA0KPj4gPj4gPj4gPj4gcGF5bG9hZC4gVG8gcHJvdmlkZSBjaGFpbiBjb250ZXh0 LCBzZXJ2aWNlIHBhdGggaWQsDQo+PiA+PiBjbGFzc2lmaWNhdGlvbg0KPj4gPj4gPj4gaW5mbywN Cj4+ID4+ID4+ID4+IGV0Yy4sIGEgc2VydmljZS1sZXZlbCBlbmNhcHN1bGF0aW9uL2hlYWRlciBp cyBhZGRlZC4gVGhpcw0KPj4gc2hvdWxkDQo+PiA+PiA+PiA+PiBiZSBlbmNhcHN1bGF0aW5nLWxh eWVyICh0cmFuc3BvcnQtbGF5ZXIpIGFnbm9zdGljLiBTZWNvbmQsIGluDQo+PiA+PiA+PiA+PiBv cmRlciBnZXQgdGhhdCB0byBhIHNlcnZpY2Ugbm9kZSwgaXQgZ2V0cyBmdXJ0aGVyIGVuY2Fwc3Vs YXRlZA0KPj4gPj4gKGluDQo+PiA+PiA+PiA+PiBJUCwgSVAvR1JFLCBJUC9VRFAsIFZYTEFOLCBN UExTLCBldGMpIGZvciBkZWxpdmVyeS4NCj4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiBCZWluZyBh IGdyYXBoaWNhbCBwZXJzb24sIEkgYWxzbyByZWFsbHkgbGlrZSB3aGF0IFN1cmVuZHJhDQo+PiBz aGFyZWQNCj4+ID4+ID4+ID4+IGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0NCj4+IGFyY2hp dmUvd2ViL25zYy9jdXJyZW50L21zZzAwMzEyLmh0bWwNCj4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+ PiBIVEgsDQo+PiA+PiA+PiA+Pg0KPj4gPj4gPj4gPj4gLS0gQ2FybG9zLg0KPj4gPj4gPj4gPj4N Cj4+ID4+ID4+ID4+IE9uIFNlcCA2LCAyMDEzLCBhdCAxMDoxNyBBTSwgTGluZGEgRHVuYmFyDQo+ PiA+PiA+PiA+PiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+DQo+PiA+PiA+PiA+PiAgd3JvdGU6 DQo+PiA+PiA+PiA+Pg0KPj4gPj4gPj4gPj4gPiBSb24sDQo+PiA+PiA+PiA+PiA+DQo+PiA+PiA+ PiA+PiA+IEdyZWF0ISAgSSBhbSBnbGFkIHRvIHNlZSB0aGF0IHdlIGdvIGRvd24gdGhpcyBwYXRo Lg0KPj4gPj4gPj4gPj4gPiBXZSBzaG91bGQgYWxzbyBhbGxvdzogL2VuZXQvaXAvdWRwIG9yIHRj cC9uc2MvLi4uDQo+PiA+PiA+PiA+PiA+IGkuZS4gbm90IG5lY2Vzc2FyaWx5IGhhdmluZyBhbiBp bm5lciBJUC4NCj4+ID4+ID4+ID4+ID4NCj4+ID4+ID4+ID4+ID4gTGluZGENCj4+ID4+ID4+ID4+ ID4NCj4+ID4+ID4+ID4+ID4NCj4+ID4+ID4+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiA+PiA+PiA+PiA+PiBGcm9tOiBSb24gUGFya2VyIFttYWlsdG86Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbV0NCj4+ID4+ID4+ID4+ID4+IFNlbnQ6IFRodXJzZGF5LCBTZXB0 ZW1iZXIgMDUsIDIwMTMgNjoxNiBQTQ0KPj4gPj4gPj4gPj4gPj4gVG86IExpbmRhIER1bmJhcjsg SmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IE1lbGluZGEgU2hvcmU7DQo+PiA+PiA+PiA+PiA+PiBu c2NAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+ID4+IFN1YmplY3Q6IFJFOiBbbnNjXSBOU0MgV29ya2lu ZyBHcm91cCBDaGFydGVyIFByb3Bvc2FsDQo+PiA+PiA+PiA+PiA+Pg0KPj4gPj4gPj4gPj4gPj4g SGksIExpbmRhLg0KPj4gPj4gPj4gPj4gPj4NCj4+ID4+ID4+ID4+ID4+IEFzIGl0IHdhcyByZWNl bnRseSBleHBsYWluZWQgb24gdGhpcyB0aHJlYWQsIEkgZG9uJ3QgdGhpbmsNCj4+IGl0DQo+PiA+ PiA+PiBuZWVkcw0KPj4gPj4gPj4gPj4gPj4gdG8gYmUgbmVjZXNzYXJ5IHRvIGFsd2F5cyBoYXZl IGl0IGlmIHdlIGFyZSB3aWxsaW5nIHRvDQo+PiBhbGxvdw0KPj4gPj4gPj4gPj4gbXVsdGlwbGUN Cj4+ID4+ID4+ID4+ID4+IG92ZXJhbGwgInRyYW5zcG9ydCIrc2VydmljZSBlbmNhcHN1bGF0aW9u cy4gICBGb3IgZXhhbXBsZToNCj4+ID4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiA+PiAvZW5ldC9p cC91ZHAvbnNjL2lwL3RjcC8uLi4NCj4+ID4+ID4+ID4+ID4+IC9lbmV0L2lwL2dyZS9uc2MvaXAv dGNwLy4uLg0KPj4gPj4gPj4gPj4gPj4gL2VuZXQvbGxjLXNuYXAvbnNjL2lwL3RjcC8uLi4NCj4+ ID4+ID4+ID4+ID4+IC9lbmV0L21wbHMvbnNjL2lwL3RjcC8uLi4NCj4+ID4+ID4+ID4+ID4+DQo+ PiA+PiA+PiA+PiA+PiBBcyBtdWNoIGFzIEkgZG9uJ3QgdGhpbmsgd2UnbGwgZW5kIHVwIHRoZXJl LCBJIGRvIGZpbmQgYQ0KPj4gPj4gc2luZ2xlDQo+PiA+PiA+PiA+PiA+PiBvdmVyYWxsIHVuaXZl cnNhbCB0cmFuc2Zvcm1hdGlvbiB2ZXJ5IGF0dHJhY3RpdmUgYW5kIGFueQ0KPj4gPj4gZmxhdm9y DQo+PiA+PiA+PiB0aGF0DQo+PiA+PiA+PiA+PiA+PiBpcyAve2wyfS9pcC94eHgvaXAvdGNwIHdv dWxkIGJlIHVuaXZlcnNhbGx5IGFwcGxpY2FibGUgLS0NCj4+IHNhbWUNCj4+ID4+ID4+ID4+IHN1 Ym5ldA0KPj4gPj4gPj4gPj4gPj4gb3IgZGlmZmVyZW50IHN1Ym5ldCwgbDIgc3dpdGNoZXMgYW5k L29yIGwzIHJvdXRlcnMgaW4NCj4+IGJldHdlZW4gLA0KPj4gPj4gPj4gPj4gT3BlbkZsb3cNCj4+ ID4+ID4+ID4+ID4+IG9yIG5vdCBPcGVuRmxvdywgTVBMUyBvciBub3QgTVBMUywgLi4uICAgICBU aGUgYXJndW1lbnQNCj4+ID4+IGFnYWluc3QNCj4+ID4+ID4+IHRoaXMNCj4+ID4+ID4+ID4+ID4+ IHdpbGwgYmUgdGhhdCB0aGUgcGFja2V0cyBhcmUgYmlnZ2VyIHRoYW4gdGhleSBuZWVkIHRvIGJl DQo+PiBmb3INCj4+ID4+IHNvbWUNCj4+ID4+ID4+ID4+ID4+IG5ldHdvcmsgdG9wb2xvZ2llcy9w cm90b2NvbHMuICAgU2ltcGxpY2l0eSBvciBlZmZpY2llbmN5Pw0KPj4gPj4gPj4gPj4gPj4NCj4+ ID4+ID4+ID4+ID4+ICAgUm9uDQo+PiA+PiA+PiA+PiA+Pg0KPj4gPj4gPj4gPj4gPj4NCj4+ID4+ ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g Pj4gPj4gPj4gPj4gRnJvbTogTGluZGEgRHVuYmFyIFttYWlsdG86bGluZGEuZHVuYmFyQGh1YXdl aS5jb21dDQo+PiA+PiA+PiA+PiA+PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDA1LCAyMDEz IDU6MTkgUE0NCj4+ID4+ID4+ID4+ID4+IFRvOiBSb24gUGFya2VyOyBKaW0gR3VpY2hhcmQgKGpn dWljaGFyKTsgTWVsaW5kYSBTaG9yZTsNCj4+ID4+ID4+IG5zY0BpZXRmLm9yZw0KPj4gPj4gPj4g Pj4gPj4gU3ViamVjdDogUkU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9z YWwNCj4+ID4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiA+PiBJIGNhbiBzZWUgdGhlIG5lZWQgZm9y IHRoaXMgIk5TQyIgaGVhZGVyIGluc2VydGVkIHRvIHRoZQ0KPj4gPj4gPj4gPj4gPj4gcGFja2V0 cywNCj4+ID4+ID4+ID4+IGFuZA0KPj4gPj4gPj4gPj4gPj4gb2NjYXNpb25hbGx5IG5lZWRpbmcg YW4gIm91dGVyLWlwIiBlbmNhcHN1bGF0aW9uIHRvIGJ5LXBhc3MNCj4+ID4+ID4+ID4+ID4+IG5v ZGVzIHRoYXQgY2FuJ3QgcGFyc2UgdGhlICJOU0MiIGhlYWRlci4NCj4+ID4+ID4+ID4+ID4+DQo+ PiA+PiA+PiA+PiA+PiBDYW4gc29tZW9uZSBleHBsYWluIHdoeSBpdCBpcyBuZWNlc3NhcnkgdG8g YWx3YXlzIGhhdmUgdGhlDQo+PiA+PiA+PiAib3V0ZXItDQo+PiA+PiA+PiA+PiBpcCINCj4+ID4+ ID4+ID4+ID4+IGhlYWRlcj8NCj4+ID4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiA+Pg0KPj4gPj4g Pj4gPj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+PiA+PiA+Pj4NCj4+ ID4+ID4+ID4+ID4+PiAJT3V0ZXItaXAvdWRwL25zYy9pbm5lci1pcC90Y3AvcGF5bG9hZA0KPj4g Pj4gPj4gPj4gPj4NCj4+ID4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiA+Pg0KPj4gPj4gPj4gPj4g Pj4gTGluZGENCj4+ID4+ID4+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+ID4+ID4+ID4+ID4gbnNjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4g Pj4gPiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uc2MNCj4+ID4+ID4+ID4NCj4+ID4+ID4+DQo+PiA+PiA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4gbnNjIG1h aWxpbmcgbGlzdA0KPj4gPj4gPj4gbnNjQGlldGYub3JnDQo+PiA+PiA+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4gPj4NCj4+ID4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBuc2MgbWFpbGluZyBsaXN0 DQo+PiA+PiBuc2NAaWV0Zi5vcmcNCj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbnNjDQo+PiA+Pg0KPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+ID4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+ID4+IG5zY0BpZXRm Lm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+ ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPm5z YyBtYWlsaW5nIGxpc3QNCj4+ID5uc2NAaWV0Zi5vcmcNCj4+ID5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gbnNjIG1haWxpbmcgbGlzdA0KPj4gbnNjQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bnNjIG1haWxpbmcg bGlzdA0KPm5zY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbnNjDQoNCg== From jguichar@cisco.com Fri Sep 6 10:21: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 6FEEB21E80D4 for ; Fri, 6 Sep 2013 10:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.130, 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 o+GokytFF6cF for ; Fri, 6 Sep 2013 10:21: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 1A65921E80BE for ; Fri, 6 Sep 2013 10:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43601; q=dns/txt; s=iport; t=1378488081; x=1379697681; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=QJfRwB6Patfqufnjl00L6iSGjRQ6cU1iq19Ko73dwcE=; b=K8xkmPD2UI+YArW6varbRvWE4nV2Gl3c0Ts69TEkdtgSTLcNf7Ta6MbV B6qIDmrNBpAf8/Qj0EXoTfFB520nU+/Y/mZ/pWH5BXGgnL0DetKsKbk2j vvNtV1hqsCTFmY19GHOiwPlHKkL7OEOwfV1dIKSdZMXKWoV8PhnLLYerV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAFEOKlKtJV2c/2dsb2JhbABbgkNENVHBVYEmFnSCJAEBAQQtQQQCFwEIEQECAQEBCwsLAQY5FAMGCAIEARIIE4dnvhOOSXwGDQwHFwECCIMTgQADlBuVQIMggWlB X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="scan'208,217";a="256371920" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 06 Sep 2013 17:21:20 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r86HLKnt027839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 17:21:20 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 12:21:19 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1Ee0QgADYD4CAAVD8UIABr9gQgAAfcYA= Date: Fri, 6 Sep 2013 17:21:19 +0000 Message-ID: <68B171751455884590F8E38E96416F363F678D58@xmb-rcd-x01.cisco.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E0123E6CE@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.2.3.120616 x-originating-ip: [10.86.246.115] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F678D58xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 17:21:30 -0000 --_000_68B171751455884590F8E38E96416F363F678D58xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Maria, That's fine and as far as I can tell nothing in the charter prevents this. From: , MARIA H > Date: Friday, September 6, 2013 12:30 PM To: "mohamed.boucadair@orange.com" >, Microsoft= Office User >, "nsc@ietf.org= " > Subject: RE: NSC Working Group Charter Proposal Jim, et al., Service chaining solutions are currently being deployed without carrying, s= o called, metadata. I believe the proposal for carrying the metadata should cover the interoper= ability with the existing service chaining infrastructures. Maria From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Thursday, September 05, 2013 10:51 AM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Hi Jim, I have nothing against the word =93metadata=94 itself. You can maintain it if you prefer, but it seems odd to call only that techn= ical aspect for that milestone. Cheers, Med De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mercredi 4 septembre 2013 19:37 =C0 : BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org Objet : Re: NSC Working Group Charter Proposal Hi Med, Comment inline .. From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Wednesday, September 4, 2013 10:05 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: NSC Working Group Charter Proposal Hi Jim, Thank you for preparing the text. I fully agree that, for the sake of interoperability, one standard track so= lution must be specified by the working group. I=92m fully supportive to me= ntion this in the charter and avoid that during the lifetime of the working= group multiple solutions are envisaged. I have some comments about the proposed deliverables and the proposed timin= g: (1) I don=92t think it is a good idea to split the requirements into multip= le documents. For the sake of consistency and also to have the big picture,= I suggest only one single document be chartered to record the requirements= . The requirements document should include functional requirements, managea= bility requirements (as per RFC5706) and security requirements. The full se= t of requirements should be taken into account during the design phase. (2) The specification effort should start once the requirements are almost = stable, not before. (3) I would remove the word =93metadata=94 from the milestones. Jim> this wording is directly associated to REQ#24 of draft-boucadair-chain= ing-requirements so would a replacement of "metadata" with "context data" w= ork for you? If not please suggest an alternative, other than removal ;-). (4) I personally don=92t see a value to add dedicated items for detailed us= e cases. There is already an undergoing effort in other fora; no need to ha= ve redundant effort in this space. Having an abstract description level in = the Problem Statement is sufficient IMHO. (5) I suggest to add a =93Analysis and Design Choices=94 document: Details = rated to design motivations and justifications will be recorded in the anal= ysis document while the specification document(s) focuses exclusively on th= e specification part. Past experience has shown that some questions are rai= sed multiple times during the lifetime of the wg and it is not sometimes ob= vious to find where the decision was made and for what reason. This kind of= details are hard (sometime) to find: either you need to check mailing list= archives, or contact the authors. I see the design analysis document as a = formal tool to record the consensus on controversial design issues. The doc= ument can also answer to =93why not my favourite solution=94 solve the prob= lem(s). (6) We don=92t know at this stage how many specification documents will be = needed. Perhaps only one Standard Track document will be required. I sugges= t we leave the decision on the exact number of Standard Track documents ope= n. To sum up: my suggestion is to go for this set of deliverables: (a) Problem Statement document (b) Framework document (terminology, functional elements, architecture, and= overall procedure) (c) Requirements document (d) Design Analysis document (e) Specification document(s) I wouldn=92t object if the first charter of the future WG covers only items= (a) to (d). An updated charter can be envisaged once the future WG has mor= e visibility on the detailed set of specification documents. Cheers, Med De :nsc-bounces@ietf.org [mailto:nsc-bounces@i= etf.org] De la part de Jim Guichard (jguichar) Envoy=E9 : mardi 3 septembre 2013 18:01 =C0 : nsc@ietf.org Objet : [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_68B171751455884590F8E38E96416F363F678D58xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Maria,

That's fine and as far as I can tell nothing in the charter prevents t= his.

From: <NAPIERALA>, MARIA H &l= t;mn1921@att.com>
Date: Friday, September 6, 2013 12:= 30 PM
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com&g= t;, Microsoft Office User <jguicha= r@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: NSC Working Group Char= ter Proposal

Jim, et al.,

 

Service chaining solutions are cur= rently being deployed without carrying, so called, metadata.

I believe the proposal for carryin= g the metadata should cover the interoperability with the existing service = chaining infrastructures.

 

Maria

 

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Thursday, September 05, 2013 10:51 AM
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 

Hi Jim,

 

I have nothing against the word =93meta= data=94 itself.

You can maintain it if you prefer, but = it seems odd to call only that technical aspect for that milestone.

 

Cheers,

Med

 

De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Envoy=E9 : mercredi 4 septembre 2013 19:37
=C0 : BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org
Objet : Re: NSC Working Group Charter Proposal

 

Hi Med,

 

Comment inline ..

 

From: "moh= amed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Date: Wednesday, September 4, 2013 10:05 AM
To: Microsoft Office User <= jguichar@cisco.com>, "nsc@ietf.= org" <nsc@ietf.org>
Subject: RE: NSC Working Group Charter Proposal

 

Hi Jim,

 

Thank you for preparing the text.

 

I fully agree that, for the sake of inte= roperability, one standard track solution must be specified by the working = group. I=92m fully supportive to mention this in the charter and avoid that during the lifetime of the working grou= p multiple solutions are envisaged.

 

I have some comments about the proposed = deliverables and the proposed timing:

 

(1) I don=92t think it is a good idea to= split the requirements into multiple documents. For the sake of consistenc= y and also to have the big picture, I suggest only one single document be chartered to record the requirements. = The requirements document should include functional requirements, manageabi= lity requirements (as per RFC5706) and security requirements. The full set = of requirements should be taken into account during the design phase.

 

(2) The specification effort should star= t once the requirements are almost stable, not before.

 

(3) I would remove the word =93metadata= =94 from the milestones.

 

Jim> this wording is directly associated t= o REQ#24 of draft-boucadair-chaining-requirements so would a replacement of= "metadata" with "context data" work for you? If not please suggest an alternative, other than removal ;-).<= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif; "><= /o:p>

 

(4) I personally don=92t see a value to = add dedicated items for detailed use cases. There is already an undergoing = effort in other fora; no need to have redundant effort in this space. Having an abstract description level in th= e Problem Statement is sufficient IMHO.<= o:p>

 

(5) I suggest to add a =93Analysis and D= esign Choices=94 document: Details rated to design motivations and justific= ations will be recorded in the analysis document while the specification document(s) focuses exclusively on the sp= ecification part. Past experience has shown that some questions are raised = multiple times during the lifetime of the wg and it is not sometimes obviou= s to find where the decision was made and for what reason. This kind of details are hard (sometime) to find= : either you need to check mailing list archives, or contact the authors. I= see the design analysis document as a formal tool to record the consensus = on controversial design issues. The document can also answer to =93why not my favourite solution=94 solve = the problem(s).

 

(6) We don=92t know at this stage how ma= ny specification documents will be needed. Perhaps only one Standard Track = document will be required. I suggest we leave the decision on the exact number of Standard Track documents open. <= /span>

 

To sum up: my suggestion is to go for th= is set of deliverables:

 

(a) Problem Statement document

(b) Framework document (terminology, fun= ctional elements, architecture, and overall procedure)

(c) Requirements document

(d) Design Analysis document=

(e) Specification document(s= )

 

I wouldn=92t object if the first charter= of the future WG covers only items (a) to (d). An updated charter can be e= nvisaged once the future WG has more visibility on the detailed set of specification documents.

 

Cheers,

Med

 

 

De :nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = De la part de Jim Guichard (jguichar)
Envoy=E9 : mardi 3 septembre 2013 18:0= 1
=C0 : nsc@ietf.org
Objet : [nsc] NSC Working Group Charter Proposal

 =

Greetings,

 

As we look forward to the formation of a wo= rking group that will focus on network service chaining, I would like to pr= opose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing = area AD's. The following is a first draft of the charter and I invite you t= o actively participate and provide inputs into this process.

 

Proposed NSC WG Charter

 

Existing service insertion and deployment t= echniques have not evolved to meet modern network architectures and do not = reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks,= servers, storage, and applications, have all undergone significant change = in recent years: virtualization, network overlays, and orchestration are in= creasingly the norm. All of these have profound effects on network and services design.

 

Today, deploying new services, or making ch= anges to existing services, often requires network topology changes. Adding= and removing service functions is a complex, risky task, that is tied to operationalizing topological changes = leading to mostly-static service definitions. New service insertion and dep= loyment techniques must enable the concept of service functions as shared r= esources, and enable the linkage of these resources using service chains that represent the abstracted view= of the required service functions, and define the order in which they shou= ld be applied. When a service chain is instantiated in a network, specific = instances of service functions are selected, and a service topology is created and used for forwarding packet= s through the service chain.<= /span>

 

A basic service chain might simply utilize = an existing overlay technology to force traffic through the necessary servi= ce functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chaining (NSC) working = group focuses on new approaches to service insertion and deployment, provid= ing a framework for the construction of services built using service chains. The WG focuses on the necessary pr= otocols for the creation of service chains, and the passing of metadata fro= m the network to service functions, and between service functions. When pos= sible, the WG will extend existing protocols to provide service chaining functionality, and any protocol exte= nsions will be reviewed by both the Network Service Chaining WG and by the = WG responsible for the protocol being extended.  

 

Specifically, the Network Service Chaining = WG is chartered to deliver the following work items: 

 

1) Problem Statement: this document will pr= ovide a summary of the problem space to be addressed by the Network Service= Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclatur= e and definitions for Network Service Chaining.

 

2) System Architecture: this set of documen= ts will provide a description of the architecture building blocks and their= relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Plane: this docume= nt will describe on the wire data plane encapsulation in support of (2). &n= bsp;A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this document will addres= s service chaining operation, monitoring and troubleshooting including rele= vant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they ar= e realized.

 

Proposed Milestones:

 

Dec 2013 Request publication of an Informat= ional document defining the Network Service Chaining problem statement to t= he IESG

 

Mar 2014 Request publication of information= al documents defining the system architecture including protocol requiremen= ts and framework to the IESG<= /span>

 

May 2014 Request publication of a Standards= Track document specifying the data-plane (including metadata) for Service = Chaining to IESG

 

May 2014 Request publication of an informat= ional document specifying Service Chaining Control Plane requirements to IE= SG

 

Dec 2014 Request publication of information= al documents defining Service Chaining manageability requirements including= MIBs, OAM, and information models to IESG 

 

 

 --_000_68B171751455884590F8E38E96416F363F678D58xmbrcdx01ciscoc_-- From jguichar@cisco.com Fri Sep 6 10:26: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 50D8821E80BE for ; Fri, 6 Sep 2013 10:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.422 X-Spam-Level: X-Spam-Status: No, score=-10.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 UkvA+tgBrpZ5 for ; Fri, 6 Sep 2013 10:26: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 2D20E21E80C7 for ; Fri, 6 Sep 2013 10:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9331; q=dns/txt; s=iport; t=1378488376; x=1379697976; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=nrN+YrQPI++ZLaQpOhPR5s9J/HRJODAA4NK976NUpOQ=; b=ZKlR1JYjp/efuVuFJvzDzSWMA95v0AbNDdVSXU9lSpuaK2G++0JtXf8A Sp6lCHV/TUpSMenEy9XTIUEVOGxKorMFD7nSIWavu+RMDyfqlSkImMRT1 wpgG2DaKqyp9xnzy2qvk2wBA9BZdiT7nKgGW3wtVgyUzUi0jLV0MDvuG9 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFALoPKlKtJXG//2dsb2JhbABRCoMHNVHBVYEmFnSCJAEBAQQBAQFkBxcGAQgRBAEBAQodLgsUCQgCBAESCBOHVQMPDL4DBI0OgSuBEgYyAgSDF4EAA5QblUCDIIIq X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="scan'208";a="256566530" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 06 Sep 2013 17:26:13 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r86HQDBQ025590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 17:26:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 12:26:12 -0500 From: "Jim Guichard (jguichar)" To: Linda Dunbar , "NAPIERALA, MARIA H" , "Joachimpillai, Damascene M" , "Surendra Kumar (smkumar)" , Ron Parker , "Melinda Shore" , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAAHzTAIAADROA//++G4CAAFTvAP//jdAAgAA0foD///DU0AACRKGAAAHHymD///WJgIABqL2AgAAC7YD//8J0AA== Date: Fri, 6 Sep 2013 17:26:11 +0000 Message-ID: <68B171751455884590F8E38E96416F363F678DA7@xmb-rcd-x01.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B9EC92@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.246.115] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 17:26:21 -0000 Everyone, As requested by several other folks, may I respectfully ask that this discussion be shelved for a later time so that we can focus simply on the charter. Debating the pros and cons of encapsulations, while interesting, is not helpful to moving our discussion of the charter forward. From a charter perspective I believe the current wording does not prevent anyone's favorite encapsulation solution and therefore once our WG is up and running they are free and welcome to write and submit I-D's to the WG for consideration.=20 On 9/6/13 1:06 PM, "Linda Dunbar" wrote: >Agree strongly of Maria's statement. > >The existing identifiers, like MPSL tag, etc., can also be used to >identify Service Chain for cases of service functions that don't need to >pass information among them or to the forwarding nodes. > >Linda > >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> NAPIERALA, MARIA H >> Sent: Friday, September 06, 2013 11:56 AM >> To: Jim Guichard (jguichar); Joachimpillai, Damascene M; Surendra Kumar >> (smkumar); Ron Parker; Melinda Shore; nsc@ietf.org >> Subject: Re: [nsc] NSC Working Group Charter Proposal >>=20 >> Service chain identifier is not absolutely necessary. Such information >> can be implicit in the chain. >> Hence, carrying or not such an identifier should be made a matter of >> choice. >>=20 >> Maria >>=20 >> > -----Original Message----- >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> > Jim Guichard (jguichar) >> > Sent: Thursday, September 05, 2013 3:36 PM >> > To: Joachimpillai, Damascene M; Surendra Kumar (smkumar); Ron Parker; >> > Melinda Shore; nsc@ietf.org >> > Subject: Re: [nsc] NSC Working Group Charter Proposal >> > >> > That's something that we would debate within the WG and as Joel said >> it >> > is >> > perhaps premature to be discussing it now. However, to answer your >> > question, in the absence of metadata the minimum would be to carry a >> > service path identifier (that is used to identify a given service >> > chain) >> > and I would argue an index into the service chain (so that a >> receiving >> > network node is able to identify which of the service functions >> within >> > the >> > service chain it should apply). An example of what I am thinking is >> > given >> > in draft-quinn-nsh. >> > >> > On 9/5/13 3:31 PM, "Joachimpillai, Damascene M" >> > wrote: >> > >> > >So what is the encapsulation carrying? >> > > >> > >-- DJ >> > > >> > >-----Original Message----- >> > >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> > >Sent: Thursday, September 05, 2013 3:22 PM >> > >To: Joachimpillai, Damascene M; Surendra Kumar (smkumar); Ron Parker; >> > >Melinda Shore; nsc@ietf.org >> > >Subject: Re: [nsc] NSC Working Group Charter Proposal >> > > >> > >That is certainly one possibility (although not required for all >> > >services) and the data plane should enable that functionality yes. >> > > >> > >On 9/5/13 3:17 PM, "Joachimpillai, Damascene M" >> > > wrote: >> > > >> > >>Isnt all of these lead to carrying Metadata from application to >> > >>application? >> > >> >> > >>-- DJ >> > >> >> > >>-----Original Message----- >> > >>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >> > >>Jim Guichard (jguichar) >> > >>Sent: Thursday, September 05, 2013 3:12 PM >> > >>To: Surendra Kumar (smkumar); Ron Parker; Melinda Shore; >> nsc@ietf.org >> > >>Subject: Re: [nsc] NSC Working Group Charter Proposal >> > >> >> > >>Yes, this is what I have in mind exactly. Ron, let me know if this >> > does >> > >>not make sense. >> > >> >> > >>On 9/5/13 3:03 PM, "Surendra Kumar (smkumar)" >> > wrote: >> > >> >> > >>>Just to add, for clarity(hopefully). >> > >>> >> > >>>This is the intent: [Transport-Encapsulation/Header | >> > >>>Service-Encapsulaiton/Header | Original-payload] Where, >> > >>>Original-payload : an IP packet without the layer-2 header >> or >> > it >> > >>>could be a frame with the L2-header. This depends on the >> > interception >> > >>>layer. >> > >>>Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, >> > =A9 >> > >>>Service Encap : is where the service-path-identifier/... >> > Is >> > >>>carried in order to be able to identify the chain or the >> forwarding >> > >>>path. >> > >>> >> > >>>Surendra. >> > >>> >> > >>>On 9/5/13 11:52 AM, "Ron Parker" >> > >>>wrote: >> > >>> >> > >>>>Thanks for your patience, Jim! >> > >>>> >> > >>>>Does your description pre-suppose that there is always another IP >> > >>>>header >> > >>>>applied? For example, an original TCP segment could look like >> > this >> > >>>>(assuming UDP-based encap for this example): >> > >>>> >> > >>>> Outer-ip/udp/nsc/inner-ip/tcp/payload >> > >>>> >> > >>>>I can definitely get my head around that as it is a universal >> > >>>>solution that presumes an IP network, only. >> > >>>> >> > >>>>I may be misinterpreting but I suspect that some on this thread >> > >>>>aren't on the same page (at least yet) and may be thinking that >> in >> > >>>>certain network >> > >>>>topologies the outer IP can/should be avoided. If that is the >> > case, >> > >>>>I >> > >>>>can't see how the nsc information can be inserted after the >> > >>>>transport, which would create something that looks like this: >> > >>>> >> > >>>> Ip/tcp/nsc/payload >> > >>>> >> > >>>>Thanks. >> > >>>> >> > >>>> Ron >> > >>>> >> > >>>> >> > >>>>-----Original Message----- >> > >>>>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> > >>>>Sent: Thursday, September 05, 2013 1:49 PM >> > >>>>To: Ron Parker; Melinda Shore; nsc@ietf.org >> > >>>>Subject: Re: [nsc] NSC Working Group Charter Proposal >> > >>>> >> > >>>>Hi Ron, >> > >>>> >> > >>>>By encapsulation we mean something inserted between the transport >> > >>>>encapsulation and the original packet payload. There are two >> things >> > >>>>that need to happen; (1) identify that "service chaining" >> > information >> > >>>>follows the transport header, and (2) encapsulate the actual >> > service >> > >>>>chaining information. Now you could go down the path of trying to >> > >>>>force fit the service chaining information into the transport but >> > >>>>that imho is a mistake we should avoid. >> > >>>> >> > >>>>On 9/5/13 1:44 PM, "Ron Parker" >> > >>>>wrote: >> > >>>> >> > >>>>>I apologize if I'm being thick on this, but I'm still having >> > trouble >> > >>>>>with >> > >>>>>the meaning of "encapsulation" here. It has been pointed out >> > that it >> > >>>>>is >> > >>>>>the thing that carries information like chain id, hop index, and >> > >>>>>possibly metadata about the flow, but excludes the "overlay" >> > >>>>>encapsulation. >> > >>>>>So >> > >>>>>if I think about something that resembles GRE, when we say >> > >>>>>encapsulation, we are meaning the part of GRE that has the key >> but >> > >>>>>not the part of GRE >> > >>>>>that adds another IP header. Where I really get twisted >> around >> > the >> > >>>>>axle is if I think about this information being embedded in an >> > IPv4 >> > >>>>>option or IPv6 extension header. Not that we're necessarily >> > choosing >> > >>>>>those, but if we did, would we call that "encapsulation"? >> > >>>>> >> > >>>>>Thanks. >> > >>>>> >> > >>>>> Ron >> > >>>>> >> > >>>>> >> > >>>>>-----Original Message----- >> > >>>>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> Behalf >> > >>>>>Of Melinda Shore >> > >>>>>Sent: Thursday, September 05, 2013 12:58 PM >> > >>>>>To: nsc@ietf.org >> > >>>>>Subject: Re: [nsc] NSC Working Group Charter Proposal >> > >>>>> >> > >>>>>On 9/5/13 6:45 AM, Linda Dunbar wrote: >> > >>>>>> This version hasn't addressed the comments on Bullet 3 of >> > >>>>>>requiring a single encapsulation being too limiting or may not >> > >>>>>>even be realistic. >> > >>>>> >> > >>>>>There's no agreement that that's the case. >> > >>>>> >> > >>>>>Melinda >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>>_______________________________________________ >> > >>>>>nsc mailing list >> > >>>>>nsc@ietf.org >> > >>>>>https://www.ietf.org/mailman/listinfo/nsc >> > >>>>>_______________________________________________ >> > >>>>>nsc mailing list >> > >>>>>nsc@ietf.org >> > >>>>>https://www.ietf.org/mailman/listinfo/nsc >> > >>>> >> > >>>>_______________________________________________ >> > >>>>nsc mailing list >> > >>>>nsc@ietf.org >> > >>>>https://www.ietf.org/mailman/listinfo/nsc >> > >>> >> > >> >> > >>_______________________________________________ >> > >>nsc mailing list >> > >>nsc@ietf.org >> > >>https://www.ietf.org/mailman/listinfo/nsc >> > > >> > >> > _______________________________________________ >> > nsc mailing 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 mn1921@att.com Fri Sep 6 10:28: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 5F48721F99A4 for ; Fri, 6 Sep 2013 10:28:26 -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.000, 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 SU4g-Iksig+1 for ; Fri, 6 Sep 2013 10:28:19 -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 D349A21F8F3C for ; Fri, 6 Sep 2013 10:28:18 -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 2b01a225.6b21c940.2966508.00-573.8202749.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 06 Sep 2013 17:28:18 +0000 (UTC) X-MXL-Hash: 522a10b265172fa8-78969c50be43971844255cbf19558ecd2bdd4ac5 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 1b01a225.0.2966494.00-400.8202699.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 06 Sep 2013 17:28:18 +0000 (UTC) X-MXL-Hash: 522a10b20bc20b8f-be483dd845fb97e1f899e01f5e566b821bf9ddcc 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 r86HSGQB020585; Fri, 6 Sep 2013 13:28:17 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r86HS2Br020293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Sep 2013 13:28:14 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 6 Sep 2013 17:27:53 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, 6 Sep 2013 13:27:53 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , "mohamed.boucadair@orange.com" , "nsc@ietf.org" Thread-Topic: NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m1Ee0QgADYD4CAAVD8UIABr9gQgAAfcYD//+924A== Date: Fri, 6 Sep 2013 17:27:53 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E0123E8AC@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <1D70D757A2C9D54D83B4CBD7625FA80E0123E6CE@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F678D58@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F678D58@xmb-rcd-x01.cisco.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: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E0123E8ACMISOUT7MSGUSR9I_" 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=Ft+yCRXq c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=-s3I2kwCOWQA:10 a=nkr3x_9TwrAA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=vO7vSaQi-] X-AnalysisOut: [zEA:10 a=AUd_NHdVAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=uuddGWrLhCwmaJoLZV8A:9 a=wPNLvfGTeEIA:10 a=JfD0Fch1gWkA:] X-AnalysisOut: [10 a=oAXR_kdF8uMA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a] X-AnalysisOut: [=dct9zPI2OGNa45gj:21 a=0CmfL2hWpymkKqIf:21 a=yMhMjlubAAAA:] X-AnalysisOut: [8 a=SSmOFEACAAAA:8 a=wrzB1q8Dgvpk1Vf3AVkA:9 a=gKO2Hq4RSVkA] X-AnalysisOut: [:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 ] X-AnalysisOut: [a=B1pYAwS0uf3XUxSf:21 a=kM9gmKnlsxuxaWvN:21 a=UIp4MV1vdXd3] X-AnalysisOut: [aXe5:21] Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 17:28:26 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E0123E8ACMISOUT7MSGUSR9I_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good. Let me make it a little more precise, namely, that adding the metadata shou= ld not necessarily require changing a deployed service chain infrastructure= . Thanks. Maria From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Friday, September 06, 2013 1:21 PM To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; nsc@ietf.org Subject: Re: NSC Working Group Charter Proposal Maria, That's fine and as far as I can tell nothing in the charter prevents this. From: , MARIA H > Date: Friday, September 6, 2013 12:30 PM To: "mohamed.boucadair@orange.com" >, Microsoft= Office User >, "nsc@ietf.org= " > Subject: RE: NSC Working Group Charter Proposal Jim, et al., Service chaining solutions are currently being deployed without carrying, s= o called, metadata. I believe the proposal for carrying the metadata should cover the interoper= ability with the existing service chaining infrastructures. Maria From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Thursday, September 05, 2013 10:51 AM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] NSC Working Group Charter Proposal Hi Jim, I have nothing against the word "metadata" itself. You can maintain it if you prefer, but it seems odd to call only that techn= ical aspect for that milestone. Cheers, Med De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mercredi 4 septembre 2013 19:37 =C0 : BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org Objet : Re: NSC Working Group Charter Proposal Hi Med, Comment inline .. From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Wednesday, September 4, 2013 10:05 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: NSC Working Group Charter Proposal Hi Jim, Thank you for preparing the text. I fully agree that, for the sake of interoperability, one standard track so= lution must be specified by the working group. I'm fully supportive to ment= ion this in the charter and avoid that during the lifetime of the working g= roup multiple solutions are envisaged. I have some comments about the proposed deliverables and the proposed timin= g: (1) I don't think it is a good idea to split the requirements into multiple= documents. For the sake of consistency and also to have the big picture, I= suggest only one single document be chartered to record the requirements. = The requirements document should include functional requirements, manageabi= lity requirements (as per RFC5706) and security requirements. The full set = of requirements should be taken into account during the design phase. (2) The specification effort should start once the requirements are almost = stable, not before. (3) I would remove the word "metadata" from the milestones. Jim> this wording is directly associated to REQ#24 of draft-boucadair-chain= ing-requirements so would a replacement of "metadata" with "context data" w= ork for you? If not please suggest an alternative, other than removal ;-). (4) I personally don't see a value to add dedicated items for detailed use = cases. There is already an undergoing effort in other fora; no need to have= redundant effort in this space. Having an abstract description level in th= e Problem Statement is sufficient IMHO. (5) I suggest to add a "Analysis and Design Choices" document: Details rate= d to design motivations and justifications will be recorded in the analysis= document while the specification document(s) focuses exclusively on the sp= ecification part. Past experience has shown that some questions are raised = multiple times during the lifetime of the wg and it is not sometimes obviou= s to find where the decision was made and for what reason. This kind of det= ails are hard (sometime) to find: either you need to check mailing list arc= hives, or contact the authors. I see the design analysis document as a form= al tool to record the consensus on controversial design issues. The documen= t can also answer to "why not my favourite solution" solve the problem(s). (6) We don't know at this stage how many specification documents will be ne= eded. Perhaps only one Standard Track document will be required. I suggest = we leave the decision on the exact number of Standard Track documents open. To sum up: my suggestion is to go for this set of deliverables: (a) Problem Statement document (b) Framework document (terminology, functional elements, architecture, and= overall procedure) (c) Requirements document (d) Design Analysis document (e) Specification document(s) I wouldn't object if the first charter of the future WG covers only items (= a) to (d). An updated charter can be envisaged once the future WG has more = visibility on the detailed set of specification documents. Cheers, Med De :nsc-bounces@ietf.org [mailto:nsc-bounces@i= etf.org] De la part de Jim Guichard (jguichar) Envoy=E9 : mardi 3 septembre 2013 18:01 =C0 : nsc@ietf.org Objet : [nsc] NSC Working Group Charter Proposal Greetings, As we look forward to the formation of a working group that will focus on n= etwork service chaining, I would like to propose a discussion on this alias= to try and reach consensus on an initial charter as requested by the routi= ng area AD's. The following is a first draft of the charter and I invite yo= u to actively participate and provide inputs into this process. Proposed NSC WG Charter Existing service insertion and deployment techniques have not evolved to me= et modern network architectures and do not reflect multi-tenancy, virtualiz= ation, elasticity, rich classification, and other network requirements. Net= works, servers, storage, and applications, have all undergone significant c= hange in recent years: virtualization, network overlays, and orchestration = are increasingly the norm. All of these have profound effects on network an= d services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to mostly-static service definitions. New service insertion and= deployment techniques must enable the concept of service functions as shar= ed resources, and enable the linkage of these resources using service chain= s that represent the abstracted view of the required service functions, and= define the order in which they should be applied. When a service chain is = instantiated in a network, specific instances of service functions are sele= cted, and a service topology is created and used for forwarding packets thr= ough the service chain. A basic service chain might simply utilize an existing overlay technology t= o force traffic through the necessary service functions. However, additiona= l information enables a richer service chain for more advanced composite se= rvices. For example, shared information (e.g., the result of classification= ) can be used to offload service function processing or inform other servic= e functions about information that would otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new approaches = to service insertion and deployment, providing a framework for the construc= tion of services built using service chains. The WG focuses on the necessar= y protocols for the creation of service chains, and the passing of metadata= from the network to service functions, and between service functions. When= possible, the WG will extend existing protocols to provide service chainin= g functionality, and any protocol extensions will be reviewed by both the N= etwork Service Chaining WG and by the WG responsible for the protocol being= extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including terminolo= gy and sample use cases. Additionally, the WG will normalize on nomenclatu= re and definitions for Network Service Chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Chaining Data Plane: this document will describe on the wire dat= a plane encapsulation in support of (2). A single encapsulation will be se= lected in order to enable interoperability of data plane components. 4) Manageability: this document will address service chaining operation, mo= nitoring and troubleshooting including relevant service chaining models suc= h as MIBs or YANG modules, along with relevant OAM capabilities and how the= y are realized. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane (including metadata) for Service Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Chaining Control Plane requirements to IESG Dec 2014 Request publication of informational documents defining Service Ch= aining manageability requirements including MIBs, OAM, and information mode= ls to IESG --_000_1D70D757A2C9D54D83B4CBD7625FA80E0123E8ACMISOUT7MSGUSR9I_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Good.

Let me make it a little m= ore precise, namely, that adding the metadata should not necessarily requir= e changing a deployed service chain infrastructure.

 <= /p>

Thanks.=

 <= /p>

Maria

 <= /p>

From: Jim Guic= hard (jguichar) [mailto:jguichar@cisco.com]
Sent: Friday, September 06, 2013 1:21 PM
To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; nsc@ietf.org Subject: Re: NSC Working Group Charter Proposal

 

Maria,

 

That's fine and as far as I = can tell nothing in the charter prevents this.

 

From: <NAPIERALA>, MARIA H <mn1921@att.com>
Date: Friday, September 6, 2013 12:30 PM
To: "mohamed.bo= ucadair@orange.com" <mohamed.boucadair@orange.com>, Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: NSC Working Group Charter Proposal

 

Jim, et al.,

 

Service chaining solution= s are currently being deployed without carrying, so called, metadata.

I believe the proposal fo= r carrying the metadata should cover the interoperability with the existing= service chaining infrastructures.

 

Maria

 

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Thursday, September 05, 2013 10:51 AM
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] NSC Working Group Charter Proposal

 =

Hi Jim,

 

I have nothing against the word “metad= ata” itself.

You can maintain it if you prefer, but it se= ems odd to call only that technical aspect for that milestone.

 

Cheers,

Med<= /o:p>

 

De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Envoy=E9 : mercredi 4 septembre 2013 19:37
=C0 : BOUCADAIR Moha= med IMT/OLN; nsc@ietf.org
Objet : Re: NSC Working Group Charter Proposal

 =

Hi Med,

 

Comment inline ..

 

From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Date: Wednesday, September 4, 2013 10:05 AM
To: Microsoft Office User <= jguichar@cisco.com>, "nsc@ietf.= org" <nsc@ietf.org>
Subject: RE: NSC Working Group Charter Proposal

 

Hi Jim,

 

Thank you for preparing the text.

 

I fully agree that, for the sake of interope= rability, one standard track solution must be specified by the working grou= p. I’m fully supportive to mention this in the charter and avoid that during the lifetime of the working group multiple s= olutions are envisaged.

 

I have some comments about the proposed deli= verables and the proposed timing:

 

(1) I don’t think it is a good idea to= split the requirements into multiple documents. For the sake of consistenc= y and also to have the big picture, I suggest only one single document be chartered to record the requirements. The requirements = document should include functional requirements, manageability requirements= (as per RFC5706) and security requirements. The full set of requirements s= hould be taken into account during the design phase.

 

(2) The specification effort should start on= ce the requirements are almost stable, not before.

 

(3) I would remove the word “metadata&= #8221; from the milestones.

 

Jim> this wording is direc= tly associated to REQ#24 of draft-boucadair-chaining-requirements so would = a replacement of "metadata" with "context data" work fo= r you? If not please suggest an alternative, other than removal ;-).

 

(4) I personally don’t see a value to = add dedicated items for detailed use cases. There is already an undergoing = effort in other fora; no need to have redundant effort in this space. Having an abstract description level in the Problem Stateme= nt is sufficient IMHO.=

 

(5) I suggest to add a “Analysis and D= esign Choices” document: Details rated to design motivations and just= ifications will be recorded in the analysis document while the specification document(s) focuses exclusively on the specification par= t. Past experience has shown that some questions are raised multiple times = during the lifetime of the wg and it is not sometimes obvious to find where= the decision was made and for what reason. This kind of details are hard (sometime) to find: either you need = to check mailing list archives, or contact the authors. I see the design an= alysis document as a formal tool to record the consensus on controversial d= esign issues. The document can also answer to “why not my favourite solution” solve the problem(s)= .

 

(6) We don’t know at this stage how ma= ny specification documents will be needed. Perhaps only one Standard Track = document will be required. I suggest we leave the decision on the exact number of Standard Track documents open.

 

To sum up: my suggestion is to go for this s= et of deliverables:

 

(a) Problem Statement document

(b) Framework document (terminology, functio= nal elements, architecture, and overall procedure)

(c) Requirements document=

(d) Design Analysis document

(e) Specification document(s)

 

I wouldn’t object if the first charter= of the future WG covers only items (a) to (d). An updated charter can be e= nvisaged once the future WG has more visibility on the detailed set of specification documents.

 

Cheers,

Med

 

 

De :nsc-bounces@ietf= .org [mailto:nsc-bounces@ietf.o= rg] De la part de Jim Guichard (jguichar)
Envoy=E9 : mardi 3 septembre 2013 18:01
=C0 : nsc@ietf.org
Objet : [nsc] NSC Working Group Charter Proposal

 =

Greetings,

 

As we look forward to the f= ormation of a working group that will focus on network service chaining, I = would like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area= AD's. The following is a first draft of the charter and I invite you to ac= tively participate and provide inputs into this process.

 

Proposed NSC WG Charter<= /span>

 

Existing service insertion = and deployment techniques have not evolved to meet modern network architect= ures and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, st= orage, and applications, have all undergone significant change in recent ye= ars: virtualization, network overlays, and orchestration are increasingly t= he norm. All of these have profound effects on network and services design.=

 

Today, deploying new servic= es, or making changes to existing services, often requires network topology= changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading t= o mostly-static service definitions. New service insertion and deployment t= echniques must enable the concept of service functions as shared resources,= and enable the linkage of these resources using service chains that represent the abstracted view of the r= equired service functions, and define the order in which they should be app= lied. When a service chain is instantiated in a network, specific instances= of service functions are selected, and a service topology is created and used for forwarding packets through = the service chain.

 

A basic service chain might= simply utilize an existing overlay technology to force traffic through the= necessary service functions. However, additional information enables a richer service chain for more advanced composite services. For e= xample, shared information (e.g., the result of classification) can be used= to offload service function processing or inform other service functions a= bout information that would otherwise be hard to glean. 

 

The Network Service Chainin= g (NSC) working group focuses on new approaches to service insertion and de= ployment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary proto= cols for the creation of service chains, and the passing of metadata from t= he network to service functions, and between service functions. When possib= le, the WG will extend existing protocols to provide service chaining functionality, and any protocol exte= nsions will be reviewed by both the Network Service Chaining WG and by the = WG responsible for the protocol being extended.  

 

Specifically, the Network S= ervice Chaining WG is chartered to deliver the following work items: <= /span>

 

1) Problem Statement: this = document will provide a summary of the problem space to be addressed by the= Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and d= efinitions for Network Service Chaining.=

 

2) System Architecture: thi= s set of documents will provide a description of the architecture building = blocks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on= the control mechanisms and data plane encapsulation.

 

3) Service Chaining Data Pl= ane: this document will describe on the wire data plane encapsulation in su= pport of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

 

4) Manageability: this docu= ment will address service chaining operation, monitoring and troubleshootin= g including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are rea= lized.

 

Proposed Milestones:=

 

Dec 2013 Request publicatio= n of an Informational document defining the Network Service Chaining proble= m statement to the IESG

 

Mar 2014 Request publicatio= n of informational documents defining the system architecture including pro= tocol requirements and framework to the IESG

 

May 2014 Request publicatio= n of a Standards Track document specifying the data-plane (including metada= ta) for Service Chaining to IESG

 

May 2014 Request publicatio= n of an informational document specifying Service Chaining Control Plane re= quirements to IESG

 

Dec 2014 Request publicatio= n of informational documents defining Service Chaining manageability requir= ements including MIBs, OAM, and information models to IESG 

 

 

--_000_1D70D757A2C9D54D83B4CBD7625FA80E0123E8ACMISOUT7MSGUSR9I_-- From kgray@juniper.net Fri Sep 6 10:34: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 B9E7211E80DE for ; Fri, 6 Sep 2013 10:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.784 X-Spam-Level: X-Spam-Status: No, score=-3.784 tagged_above=-999 required=5 tests=[AWL=-0.185, 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 vvmQ-N6Jw4uh for ; Fri, 6 Sep 2013 10:34:29 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id B1EE911E8199 for ; Fri, 6 Sep 2013 10:34:28 -0700 (PDT) Received: from mail166-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Fri, 6 Sep 2013 17:34:27 +0000 Received: from mail166-va3 (localhost [127.0.0.1]) by mail166-va3-R.bigfish.com (Postfix) with ESMTP id 748AE200BC; Fri, 6 Sep 2013 17:34:27 +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: -22 X-BigFish: VPS-22(zzbb2dI98dI9371I542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz70kz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail166-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(189002)(51704005)(199002)(13464003)(377454003)(479174003)(56816003)(77096001)(83506001)(53806001)(54356001)(76482001)(54316002)(56776001)(74706001)(15975445006)(31966008)(74662001)(77982001)(59766001)(83072001)(74502001)(47446002)(80022001)(65816001)(561944002)(74876001)(51856001)(76176001)(81816001)(69226001)(79102001)(80976001)(63696002)(81342001)(81686001)(50986001)(4396001)(74366001)(19580405001)(83322001)(47976001)(46102001)(76796001)(76786001)(81542001)(19580395003)(49866001)(47736001)(36756003)(921001)(1121002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB083; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail166-va3 (localhost.localdomain [127.0.0.1]) by mail166-va3 (MessageSwitch) id 1378488864525362_20640; Fri, 6 Sep 2013 17:34:24 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.245]) by mail166-va3.bigfish.com (Postfix) with ESMTP id 6F0A31A0041; Fri, 6 Sep 2013 17:34:24 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 6 Sep 2013 17:34:20 +0000 Received: from BL2PR05MB083.namprd05.prod.outlook.com (10.255.232.26) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.353.4; Fri, 6 Sep 2013 17:34:15 +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.745.25; Fri, 6 Sep 2013 17:34:14 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.191]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.191]) with mapi id 15.00.0745.000; Fri, 6 Sep 2013 17:34:14 +0000 From: Ken Gray To: "Jim Guichard (jguichar)" , Linda Dunbar , "NAPIERALA, MARIA H" , "Joachimpillai, Damascene M" , "Surendra Kumar (smkumar)" , Ron Parker , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAACkCAIAADRKAgAABLQCAABHdAIAAAysAgAACNwCAAAGwAIAAAUWAgAACnQCAAAErgIABZa2AgAAC7YCAAAWDgP//vysA Date: Fri, 6 Sep 2013 17:34:13 +0000 Message-ID: In-Reply-To: <68B171751455884590F8E38E96416F363F678DA7@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.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 0961DF5286 Content-Type: text/plain; charset="iso-8859-2" Content-ID: <5BF388E2E81CD04C8CD31D087FEF97CC@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% Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 17:34:33 -0000 +1 On 9/6/13 1:26 PM, "Jim Guichard (jguichar)" wrote: >Everyone, > >As requested by several other folks, may I respectfully ask that this >discussion be shelved for a later time so that we can focus simply on the >charter. Debating the pros and cons of encapsulations, while interesting, >is not helpful to moving our discussion of the charter forward. From a >charter perspective I believe the current wording does not prevent >anyone's favorite encapsulation solution and therefore once our WG is up >and running they are free and welcome to write and submit I-D's to the WG >for consideration. > >On 9/6/13 1:06 PM, "Linda Dunbar" wrote: > >>Agree strongly of Maria's statement. >> >>The existing identifiers, like MPSL tag, etc., can also be used to >>identify Service Chain for cases of service functions that don't need to >>pass information among them or to the forwarding nodes. >> >>Linda >> >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>> NAPIERALA, MARIA H >>> Sent: Friday, September 06, 2013 11:56 AM >>> To: Jim Guichard (jguichar); Joachimpillai, Damascene M; Surendra Kumar >>> (smkumar); Ron Parker; Melinda Shore; nsc@ietf.org >>> Subject: Re: [nsc] NSC Working Group Charter Proposal >>>=20 >>> Service chain identifier is not absolutely necessary. Such information >>> can be implicit in the chain. >>> Hence, carrying or not such an identifier should be made a matter of >>> choice. >>>=20 >>> Maria >>>=20 >>> > -----Original Message----- >>> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>> > Jim Guichard (jguichar) >>> > Sent: Thursday, September 05, 2013 3:36 PM >>> > To: Joachimpillai, Damascene M; Surendra Kumar (smkumar); Ron Parker; >>> > Melinda Shore; nsc@ietf.org >>> > Subject: Re: [nsc] NSC Working Group Charter Proposal >>> > >>> > That's something that we would debate within the WG and as Joel said >>> it >>> > is >>> > perhaps premature to be discussing it now. However, to answer your >>> > question, in the absence of metadata the minimum would be to carry a >>> > service path identifier (that is used to identify a given service >>> > chain) >>> > and I would argue an index into the service chain (so that a >>> receiving >>> > network node is able to identify which of the service functions >>> within >>> > the >>> > service chain it should apply). An example of what I am thinking is >>> > given >>> > in draft-quinn-nsh. >>> > >>> > On 9/5/13 3:31 PM, "Joachimpillai, Damascene M" >>> > wrote: >>> > >>> > >So what is the encapsulation carrying? >>> > > >>> > >-- DJ >>> > > >>> > >-----Original Message----- >>> > >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> > >Sent: Thursday, September 05, 2013 3:22 PM >>> > >To: Joachimpillai, Damascene M; Surendra Kumar (smkumar); Ron >>>Parker; >>> > >Melinda Shore; nsc@ietf.org >>> > >Subject: Re: [nsc] NSC Working Group Charter Proposal >>> > > >>> > >That is certainly one possibility (although not required for all >>> > >services) and the data plane should enable that functionality yes. >>> > > >>> > >On 9/5/13 3:17 PM, "Joachimpillai, Damascene M" >>> > > wrote: >>> > > >>> > >>Isnt all of these lead to carrying Metadata from application to >>> > >>application? >>> > >> >>> > >>-- DJ >>> > >> >>> > >>-----Original Message----- >>> > >>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>> Of >>> > >>Jim Guichard (jguichar) >>> > >>Sent: Thursday, September 05, 2013 3:12 PM >>> > >>To: Surendra Kumar (smkumar); Ron Parker; Melinda Shore; >>> nsc@ietf.org >>> > >>Subject: Re: [nsc] NSC Working Group Charter Proposal >>> > >> >>> > >>Yes, this is what I have in mind exactly. Ron, let me know if this >>> > does >>> > >>not make sense. >>> > >> >>> > >>On 9/5/13 3:03 PM, "Surendra Kumar (smkumar)" >>> > wrote: >>> > >> >>> > >>>Just to add, for clarity(hopefully). >>> > >>> >>> > >>>This is the intent: [Transport-Encapsulation/Header | >>> > >>>Service-Encapsulaiton/Header | Original-payload] Where, >>> > >>>Original-payload : an IP packet without the layer-2 header >>> or >>> > it >>> > >>>could be a frame with the L2-header. This depends on the >>> > interception >>> > >>>layer. >>> > >>>Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, >>>UDP/UDP-lite, >>> > =A9 >>> > >>>Service Encap : is where the service-path-identifier/... >>> > Is >>> > >>>carried in order to be able to identify the chain or the >>> forwarding >>> > >>>path. >>> > >>> >>> > >>>Surendra. >>> > >>> >>> > >>>On 9/5/13 11:52 AM, "Ron Parker" >>> > >>>wrote: >>> > >>> >>> > >>>>Thanks for your patience, Jim! >>> > >>>> >>> > >>>>Does your description pre-suppose that there is always another IP >>> > >>>>header >>> > >>>>applied? For example, an original TCP segment could look like >>> > this >>> > >>>>(assuming UDP-based encap for this example): >>> > >>>> >>> > >>>> Outer-ip/udp/nsc/inner-ip/tcp/payload >>> > >>>> >>> > >>>>I can definitely get my head around that as it is a universal >>> > >>>>solution that presumes an IP network, only. >>> > >>>> >>> > >>>>I may be misinterpreting but I suspect that some on this thread >>> > >>>>aren't on the same page (at least yet) and may be thinking that >>> in >>> > >>>>certain network >>> > >>>>topologies the outer IP can/should be avoided. If that is the >>> > case, >>> > >>>>I >>> > >>>>can't see how the nsc information can be inserted after the >>> > >>>>transport, which would create something that looks like this: >>> > >>>> >>> > >>>> Ip/tcp/nsc/payload >>> > >>>> >>> > >>>>Thanks. >>> > >>>> >>> > >>>> Ron >>> > >>>> >>> > >>>> >>> > >>>>-----Original Message----- >>> > >>>>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> > >>>>Sent: Thursday, September 05, 2013 1:49 PM >>> > >>>>To: Ron Parker; Melinda Shore; nsc@ietf.org >>> > >>>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>> > >>>> >>> > >>>>Hi Ron, >>> > >>>> >>> > >>>>By encapsulation we mean something inserted between the transport >>> > >>>>encapsulation and the original packet payload. There are two >>> things >>> > >>>>that need to happen; (1) identify that "service chaining" >>> > information >>> > >>>>follows the transport header, and (2) encapsulate the actual >>> > service >>> > >>>>chaining information. Now you could go down the path of trying to >>> > >>>>force fit the service chaining information into the transport but >>> > >>>>that imho is a mistake we should avoid. >>> > >>>> >>> > >>>>On 9/5/13 1:44 PM, "Ron Parker" >>> > >>>>wrote: >>> > >>>> >>> > >>>>>I apologize if I'm being thick on this, but I'm still having >>> > trouble >>> > >>>>>with >>> > >>>>>the meaning of "encapsulation" here. It has been pointed out >>> > that it >>> > >>>>>is >>> > >>>>>the thing that carries information like chain id, hop index, and >>> > >>>>>possibly metadata about the flow, but excludes the "overlay" >>> > >>>>>encapsulation. >>> > >>>>>So >>> > >>>>>if I think about something that resembles GRE, when we say >>> > >>>>>encapsulation, we are meaning the part of GRE that has the key >>> but >>> > >>>>>not the part of GRE >>> > >>>>>that adds another IP header. Where I really get twisted >>> around >>> > the >>> > >>>>>axle is if I think about this information being embedded in an >>> > IPv4 >>> > >>>>>option or IPv6 extension header. Not that we're necessarily >>> > choosing >>> > >>>>>those, but if we did, would we call that "encapsulation"? >>> > >>>>> >>> > >>>>>Thanks. >>> > >>>>> >>> > >>>>> Ron >>> > >>>>> >>> > >>>>> >>> > >>>>>-----Original Message----- >>> > >>>>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> Behalf >>> > >>>>>Of Melinda Shore >>> > >>>>>Sent: Thursday, September 05, 2013 12:58 PM >>> > >>>>>To: nsc@ietf.org >>> > >>>>>Subject: Re: [nsc] NSC Working Group Charter Proposal >>> > >>>>> >>> > >>>>>On 9/5/13 6:45 AM, Linda Dunbar wrote: >>> > >>>>>> This version hasn't addressed the comments on Bullet 3 of >>> > >>>>>>requiring a single encapsulation being too limiting or may not >>> > >>>>>>even be realistic. >>> > >>>>> >>> > >>>>>There's no agreement that that's the case. >>> > >>>>> >>> > >>>>>Melinda >>> > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>>_______________________________________________ >>> > >>>>>nsc mailing list >>> > >>>>>nsc@ietf.org >>> > >>>>>https://www.ietf.org/mailman/listinfo/nsc >>> > >>>>>_______________________________________________ >>> > >>>>>nsc mailing list >>> > >>>>>nsc@ietf.org >>> > >>>>>https://www.ietf.org/mailman/listinfo/nsc >>> > >>>> >>> > >>>>_______________________________________________ >>> > >>>>nsc mailing list >>> > >>>>nsc@ietf.org >>> > >>>>https://www.ietf.org/mailman/listinfo/nsc >>> > >>> >>> > >> >>> > >>_______________________________________________ >>> > >>nsc mailing list >>> > >>nsc@ietf.org >>> > >>https://www.ietf.org/mailman/listinfo/nsc >>> > > >>> > >>> > _______________________________________________ >>> > nsc mailing list >>> > nsc@ietf.org >>> > https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ >>> nsc mailing 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 Sep 6 10:36: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 C375121E80CE for ; Fri, 6 Sep 2013 10:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.433 X-Spam-Level: X-Spam-Status: No, score=-10.433 tagged_above=-999 required=5 tests=[AWL=0.165, 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 hjR6P2pwy0uc for ; Fri, 6 Sep 2013 10:36:24 -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 D026511E819C for ; Fri, 6 Sep 2013 10:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12696; q=dns/txt; s=iport; t=1378488984; x=1379698584; h=from:to:subject:date:message-id:mime-version; bh=ioEvH38MVxYA96sm5qfiL/FZP00AOnCbGZFzCS7W4ok=; b=KWOR+0y3y8+jeN5XFeN6yj1tS2r+E66Kj8pmOOM4EqVuQjmoquE8Vlwq teZBtxpWTWfxOriysIamgy6nSO8GKyMEsuelMwa3ldWAS6yrpXH1FAGNA PXujN+TGxd+d09eN6pUSx+rDmzyFfRIiDY7tMdSZdpQ5fwZWADcGqNc0U Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMGABISKlKtJXG//2dsb2JhbABbgkNEgQbBVYEmFm0HgiYBBGcLGQEaEFYXEAQbh3qdZaAxjkmBAoNVgQADlBuVQIMggWlB X-IronPort-AV: E=Sophos;i="4.90,855,1371081600"; d="scan'208,217";a="256569937" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 06 Sep 2013 17:36:22 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r86HaMrQ002699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Sep 2013 17:36:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 12:36:22 -0500 From: "Jim Guichard (jguichar)" To: "nsc@ietf.org" Thread-Topic: Back to the charter ... Thread-Index: AQHOqyeZwMPgp+Js6UOHmDI/e3mhOw== Date: Fri, 6 Sep 2013 17:36:21 +0000 Message-ID: <68B171751455884590F8E38E96416F363F678E4B@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.86.246.115] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F678E4Bxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: [nsc] Back to the 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, 06 Sep 2013 17:36:44 -0000 --_000_68B171751455884590F8E38E96416F363F678E4Bxmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, Here is the current version of the charter. Please be encouraged to review = further and add comments. I would especially welcome those subscribers on t= he list that have yet to comment =96 we have at current count 299 subscribe= rs so I know you are out there ;-) : Proposed NSC WG Charter Existing service insertion and deployment techniques fail to address new ch= allenging requirements raised by the introduction of emerging technologies = such as multi-tenancy, virtualization, elasticity, and rich classification.= Networks, servers, and other storage technologies, let alone applications,= have all undergone significant change in recent years: virtualization, net= work overlays, and orchestration have increasingly become techniques that c= ount and sometimes prevail. All of these have profound effects on network a= nd services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to massively static configuration procedures for network servic= e delivery or update purposes. The structuring and the delivery of new netw= ork services assume the (smart) combination of various service functions as= shared resources, and enable the linkage of these resources using service = function chains that represent the abstracted view of the required service = functions, and define the order in which they should be invoked. Such (smar= t) combinations could be made of heterogeneous service functions which may = act at various layers of a protocol stack (network layer, application layer= , etc). When a service function chain is instantiated in a network, specifi= c instances of service functions are selected, and a service topology is cr= eated and used for forwarding packets according to the service function cha= in. A basic service function chain might simply utilize an existing overlay tec= hnology to force traffic through the necessary service functions. However, = additional information that is shared across a subset of service functions = may enable a richer service function chain for more advanced composite serv= ices. For example, shared information, such as the results of a classificat= ion function, may be passed to downstream service functions to enable the o= ffloading of service function processing or to share information that would= otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new and simpler= approaches to network service structuring, insertion, and deployment, prov= iding a framework for the construction of services built using service func= tion chains. The WG focuses on the necessary protocols for management (e.g.= create, delete, monitor) of service function chains, and the transmission = of network and service-specific information from the network to service fun= ctions, and between service functions. When possible, the WG will extend ex= isting protocols to provide service chaining functionality, and any protoco= l extensions will be reviewed by both the Network Service Chaining WG and b= y the WG responsible for the protocol being extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the problem s= pace to be addressed by the Network Service Chaining WG including example h= igh-level use cases. Additionally, the WG will normalize on nomenclature a= nd definitions for service function chaining. 2) System Architecture: this set of documents will provide a description of= the architecture building blocks and their relationships including interco= nnection, placement of capabilities, and security models, as well as requir= ements on the control mechanisms and data plane encapsulation. 3) Service Function Chaining Data & Control Plane: A data plane document wi= ll describe on the wire data plane encapsulation in support of (2). A singl= e service-level encapsulation will be selected in order to enable interoper= ability of data plane components, which can in turn be carried in various t= ransport encapsulations (e.g., IP, MPLS, or other overlays). Supporting con= trol plane protocol elements will be added as needed (as a separate documen= t). 4) Manageability: this document will address service function chaining mana= gement in support of (2) including relevant MIBs and YANG information model= s, and service function chaining OAM. Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Function Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane service-level encapsulation (including context data) for Service = Function Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Function Chaining Control Plane requirements to IESG Dec 2014 Request publication of Informational document(s) defining Network = Service Function Chaining use cases to IESG Dec 2014 Request publication of informational documents defining Service Fu= nction Chaining manageability including MIBs, OAM, and YANG information mod= els to IESG --_000_68B171751455884590F8E38E96416F363F678E4Bxmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <665CEFE86A45214DBF43581470D7D80A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Folks,

Here is the current version of the charter. Please be encouraged to re= view further and add comments. I would especially welcome those subscribers= on the list that have yet to comment =96 we have at current count 299 subs= cribers so I know you are out there ;-) :

Proposed NSC WG Charter

Existing service insertion and deployment techniques fail to address n= ew challenging requirements raised by the introduction of emerging technolo= gies such as multi-tenancy, virtualization, elasticity, and rich classifica= tion. Networks, servers, and other storage technologies, let alone applications, have all undergone significa= nt change in recent years: virtualization, network overlays, and orchestrat= ion have increasingly become techniques that count and sometimes prevail. A= ll of these have profound effects on network and services design.

Today, deploying new services, or making changes to existing services,= often requires network topology changes. Adding and removing service funct= ions is a complex, risky task, that is tied to operationalizing topological= changes leading to massively static configuration procedures for network service delivery or update purposes. = The structuring and the delivery of new network services assume the (smart)= combination of various service functions as shared resources, and enable t= he linkage of these resources using service function chains that represent the abstracted view of the required= service functions, and define the order in which they should be invoked. S= uch (smart) combinations could be made of heterogeneous service functions w= hich may act at various layers of a protocol stack (network layer, application layer, etc). When a service f= unction chain is instantiated in a network, specific instances of service f= unctions are selected, and a service topology is created and used for forwa= rding packets according to the service function chain.

A basic service function chain might simply utilize an existing overla= y technology to force traffic through the necessary service functions. Howe= ver, additional information that is shared across a subset of service funct= ions may enable a richer service function chain for more advanced composite services. For example, shared i= nformation, such as the results of a classification function, may be passed= to downstream service functions to enable the offloading of service functi= on processing or to share information that would otherwise be hard to glean. 

The Network Service Chaining (NSC) working group focuses on new and si= mpler approaches to network service structuring, insertion, and deployment,= providing a framework for the construction of services built using service= function chains. The WG focuses on the necessary protocols for management (e.g. create, delete, monitor) o= f service function chains, and the transmission of network and service-spec= ific information from the network to service functions, and between service= functions. When possible, the WG will extend existing protocols to provide service chaining functionality, = and any protocol extensions will be reviewed by both the Network Service Ch= aining WG and by the WG responsible for the protocol being extended.  =

Specifically, the Network Service Chaining WG is chartered to deliver = the following work items: 

1) Problem Statement: this document will provide a summary of the prob= lem space to be addressed by the Network Service Chaining WG including exam= ple high-level use cases.  Additionally, the WG will normalize on nome= nclature and definitions for service function chaining.

2) System Architecture: this set of documents will provide a descripti= on of the architecture building blocks and their relationships including in= terconnection, placement of capabilities, and security models, as well as r= equirements on the control mechanisms and data plane encapsulation.

3) Service Function Chaining Data & Control Plane: A data plane do= cument will describe on the wire data plane encapsulation in support of (2)= . A single service-level encapsulation will be selected in order to enable = interoperability of data plane components, which can in turn be carried in various transport encapsulations (e.g., IP= , MPLS, or other overlays). Supporting control plane protocol elements will= be added as needed (as a separate document).

4) Manageability: this document will address service function chaining= management in support of (2) including relevant MIBs and YANG information = models, and service function chaining OAM.

Proposed Milestones:

Dec 2013 Request publication of an Informational document defining the= Network Service Function Chaining problem statement to the IESG

Mar 2014 Request publication of informational documents defining the s= ystem architecture including protocol requirements and framework to the IES= G

May 2014 Request publication of a Standards Track document specifying = the data-plane service-level encapsulation (including context data) for Ser= vice Function Chaining to IESG

May 2014 Request publication of an informational document specifying S= ervice Function Chaining Control Plane requirements to IESG

Dec 2014 Request publication of Informational document(s) defining Net= work Service Function Chaining use cases to IESG

Dec 2014 Request publication of informational documents defining Servi= ce Function Chaining manageability including MIBs, OAM, and YANG informatio= n models to IESG 


--_000_68B171751455884590F8E38E96416F363F678E4Bxmbrcdx01ciscoc_-- From tnadeau@lucidvision.com Fri Sep 6 13:36: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 B803511E80F9 for ; Fri, 6 Sep 2013 13:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.172, 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 DLwxI8L+aqxn for ; Fri, 6 Sep 2013 13:36:11 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id C08F411E80F3 for ; Fri, 6 Sep 2013 13:36:10 -0700 (PDT) Received: from mamato-sslvpn-nc.jnpr.net (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 47593255EE0D; Fri, 6 Sep 2013 16:36:08 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EC4B843E-9268-4D14-9B83-9C272DA44214"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: <68B171751455884590F8E38E96416F363F6788C8@xmb-rcd-x01.cisco.com> Date: Fri, 6 Sep 2013 16:35:55 -0400 Message-Id: <1B32E32A-B9BA-4617-BB90-F11DA537398C@lucidvision.com> References: <68B171751455884590F8E38E96416F363F6788C8@xmb-rcd-x01.cisco.com> To: "Jim Guichard (jguichar)" X-Mailer: Apple Mail (2.1508) Cc: "nsc@ietf.org" , "Carlos Pignataro \(cpignata\)" , Melinda Shore , Ron Parker , Linda Dunbar Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 20:36:15 -0000 --Apple-Mail=_EC4B843E-9268-4D14-9B83-9C272DA44214 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I agree. This is the same model that was chosen for PWs. In = fact, there is ample evidence around NOT meddling with the packets as = they are inside the "NFV tunnel" that can be gathered from other = "tunneling" efforts past and present at the IETF. --Tom On Sep 6, 2013:11:42 AM, at 11:42 AM, "Jim Guichard (jguichar)" = wrote: > Linda, >=20 > I don=B9t think anyone is saying that you use outer transport layer = for > passing information among service nodes; to the contrary, the outer > transport layer is simply used to get packets from point A to point B = and > *nothing* more. If point B happens to be a service node that is acting = on > behalf of an attached service function then point B may use the > service-encapsulation to figure out how to forward the packet to the = right > service function. =20 >=20 > On 9/6/13 11:36 AM, "Linda Dunbar" wrote: >=20 >> Carlos,=20 >>=20 >> I agree that you have to use Outer Transport Layer to pass = information >> among Service Nodes. >>=20 >> However, I think that we need to acknowledge that many of today's = Service >> Nodes, e.g. FW, LB, etc, especially the ones that are one link away = from >> Forwarding nodes, don't even use any addresses. If the Forwarding = nodes >> have the needed traffic clarification means, they can direct the >> selective traffic that need the "Service" to the service nodes. >>=20 >> It is not "one size" fits all for all Service nodes. >>=20 >> Linda =20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf = Of >>> Carlos Pignataro (cpignata) >>> Sent: Friday, September 06, 2013 10:26 AM >>> To: Linda Dunbar >>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore; Ron Parker >>> Subject: Re: [nsc] NSC Working Group Charter Proposal >>>=20 >>> Hi, Linda, >>>=20 >>> I have to admit that I am a bit lost with this comment or a couple = of >>> previous ones. Consequently, I wanted to send a (hopefully) = clarifying >>> summary. >>>=20 >>> The goal is to send a packet (original-payload from a service >>> perspective) with added service context to a service node. This is a >>> two-step approach: we can call the steps 1. service (inner), 2. >>> transport. >>>=20 >>> A service chain defines a set of services applied to an original >>> payload. To provide chain context, service path id, classification = info, >>> etc., a service-level encapsulation/header is added. This should be >>> encapsulating-layer (transport-layer) agnostic. Second, in order get >>> that to a service node, it gets further encapsulated (in IP, IP/GRE, >>> IP/UDP, VXLAN, MPLS, etc) for delivery. >>>=20 >>> Being a graphical person, I also really like what Surendra shared at >>> http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html >>>=20 >>> HTH, >>>=20 >>> -- Carlos. >>>=20 >>> On Sep 6, 2013, at 10:17 AM, Linda Dunbar >>> wrote: >>>=20 >>>> Ron, >>>>=20 >>>> Great! I am glad to see that we go down this path. >>>> We should also allow: /enet/ip/udp or tcp/nsc/... >>>> i.e. not necessarily having an inner IP. >>>>=20 >>>> Linda >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>> Sent: Thursday, September 05, 2013 6:16 PM >>>>> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; >>>>> nsc@ietf.org >>>>> Subject: RE: [nsc] NSC Working Group Charter Proposal >>>>>=20 >>>>> Hi, Linda. >>>>>=20 >>>>> As it was recently explained on this thread, I don't think it = needs >>>>> to be necessary to always have it if we are willing to allow >>> multiple >>>>> overall "transport"+service encapsulations. For example: >>>>>=20 >>>>> /enet/ip/udp/nsc/ip/tcp/... >>>>> /enet/ip/gre/nsc/ip/tcp/... >>>>> /enet/llc-snap/nsc/ip/tcp/... >>>>> /enet/mpls/nsc/ip/tcp/... >>>>>=20 >>>>> As much as I don't think we'll end up there, I do find a single >>>>> overall universal transformation very attractive and any flavor = that >>>>> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same >>> subnet >>>>> or different subnet, l2 switches and/or l3 routers in between , >>> OpenFlow >>>>> or not OpenFlow, MPLS or not MPLS, ... The argument against = this >>>>> will be that the packets are bigger than they need to be for some >>>>> network topologies/protocols. Simplicity or efficiency? >>>>>=20 >>>>> Ron >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>>> Sent: Thursday, September 05, 2013 5:19 PM >>>>> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; = nsc@ietf.org >>>>> Subject: RE: [nsc] NSC Working Group Charter Proposal >>>>>=20 >>>>> I can see the need for this "NSC" header inserted to the packets, >>> and >>>>> occasionally needing an "outer-ip" encapsulation to by-pass nodes >>>>> that can't parse the "NSC" header. >>>>>=20 >>>>> Can someone explain why it is necessary to always have the "outer- >>> ip" >>>>> header? >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>>=20 >>>>>> Outer-ip/udp/nsc/inner-ip/tcp/payload >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Linda >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 --Apple-Mail=_EC4B843E-9268-4D14-9B83-9C272DA44214 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 iQIcBAEBCgAGBQJSKjyrAAoJEPcO+I7eiUJZj30P/1SRwOE90/VN51MQgc8YAYD4 PW0GxKH0X/zfeUpoL6z4SQWEDbejOVAb8K1vuslC2etKA2TIwZGBlGFzF2QuRt33 JbgCNxGQDt6G6N+PtuDA5T9MDnCx4Ni8/GEGaqUh4cQnbyV4jKO5OWj6ryUdSK0U 5FveE1BiPD4BrCGEM9AakbzZqRAxmALGnhnWfHAnmOlMNfpp2qSbIPk0sT4oh5ip G6A50D/PZnYChvnBtyP/Tt/pQUUYwaesCTB4L0RQJLMsdJ6WyLSvi1rOBrMc7991 crui6PqmO9lv/j2iirA2LOhQb1r3IiCYdN7pV/K+PmwCA4PeJK8kZlehWi8MHKsx +GesRqfLzDVVW1ov/irwWqdI+DBbX9bYtuAptrLQiITVGNgtOQ5b0EmOZ0lxzw7n pHhnI9O8CZNM/dF46pL+cz5QeOKnRyJ5zLzdBiCNpIIgSG+vMxbWfrSSM/V8Avbk Kz2vHxKJu/J+mF4qjXiuRNY3GclzyXtoxjVCQnNzDWO4LbYyr2qV17ZzK9yLYlb6 8IETRnE7Pc56ajc+8GezcwrAWoKnF2s3BYo7Earnw2KVmC441iXPdLyh/Zgp/ulx 6inZNLbJCJm8BxX0YgpyKotVT5oZ6+aga036CYHdfGeH5hY/+k5MInNirX+S/g8Q /IZfEomfM99ZR/5c/JuX =Hntj -----END PGP SIGNATURE----- --Apple-Mail=_EC4B843E-9268-4D14-9B83-9C272DA44214-- From tnadeau@lucidvision.com Fri Sep 6 13:36: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 5AF1621E80D8 for ; Fri, 6 Sep 2013 13:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 bV0-K7LLG3GL for ; Fri, 6 Sep 2013 13:36:32 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 29B5221E8054 for ; Fri, 6 Sep 2013 13:36:32 -0700 (PDT) Received: from mamato-sslvpn-nc.jnpr.net (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 25A7C255EE1E; Fri, 6 Sep 2013 16:36:31 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A8130BF6-B5F2-4A91-96A4-C94B107F7A42"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: <6c93fdea00d64a949b31ff6feb647cd7@BN1PR05MB251.namprd05.prod.outlook.com> Date: Fri, 6 Sep 2013 16:36:30 -0400 Message-Id: <01F38705-325B-42E3-8BE3-B2F5097511F7@lucidvision.com> References: <4A95BA014132FF49AE685FAB4B9F17F645B9EAE4@dfweml509-mbx.china.huawei.com> <68B171751455884590F8E38E96416F363F67897A@xmb-rcd-x01.cisco.com> <6c93fdea00d64a949b31ff6feb647cd7@BN1PR05MB251.namprd05.prod.outlook.com> To: Jerome Moisand X-Mailer: Apple Mail (2.1508) Cc: "nsc@ietf.org" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 06 Sep 2013 20:36:37 -0000 --Apple-Mail=_A8130BF6-B5F2-4A91-96A4-C94B107F7A42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Oui! On Sep 6, 2013:12:00 PM, at 12:00 PM, Jerome Moisand = wrote: > Guys, could we please keep this discussion for later? We're supposed = to discuss a charter here. Not a specific solution.=20 >=20 > Fair enough? >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of = Jim Guichard (jguichar) > Sent: Friday, September 06, 2013 11:57 AM > To: Linda Dunbar; Carlos Pignataro (cpignata) > Cc: nsc@ietf.org; Melinda Shore; Ron Parker > Subject: Re: [nsc] NSC Working Group Charter Proposal >=20 > Then use routing. >=20 > On 9/6/13 11:54 AM, "Linda Dunbar" wrote: >=20 >> Jim, >>=20 >> What if "A" and "B" in your example are today's existing nodes, (they=20= >> are not aware of NSC header) and the traffic between "A" and "B" = needs=20 >> a sequence of service functions? >>=20 >> Some service functions are one link away from forwarding nodes (or=20 >> co-located), which may not require another layer of encapsulation. = But=20 >> some service functions are accessible via multiple nodes, then there = is=20 >> need for another layer encapsulation. >>=20 >> Linda >>=20 >>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf = Of=20 >>> Jim Guichard (jguichar) >>> Sent: Friday, September 06, 2013 10:43 AM >>> To: Linda Dunbar; Carlos Pignataro (cpignata) >>> Cc: nsc@ietf.org; Melinda Shore; Ron Parker >>> Subject: Re: [nsc] NSC Working Group Charter Proposal >>>=20 >>> Linda, >>>=20 >>> I don=B9t think anyone is saying that you use outer transport layer = for=20 >>> passing information among service nodes; to the contrary, the outer=20= >>> transport layer is simply used to get packets from point A to point = B=20 >>> and >>> *nothing* more. If point B happens to be a service node that is=20 >>> acting on behalf of an attached service function then point B may = use=20 >>> the service-encapsulation to figure out how to forward the packet to=20= >>> the right service function. >>>=20 >>> On 9/6/13 11:36 AM, "Linda Dunbar" wrote: >>>=20 >>>> Carlos, >>>>=20 >>>> I agree that you have to use Outer Transport Layer to pass=20 >>>> information among Service Nodes. >>>>=20 >>>> However, I think that we need to acknowledge that many of today's >>> Service >>>> Nodes, e.g. FW, LB, etc, especially the ones that are one link away >>> from >>>> Forwarding nodes, don't even use any addresses. If the Forwarding >>> nodes >>>> have the needed traffic clarification means, they can direct the=20 >>>> selective traffic that need the "Service" to the service nodes. >>>>=20 >>>> It is not "one size" fits all for all Service nodes. >>>>=20 >>>> Linda >>>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>> Of >>>>> Carlos Pignataro (cpignata) >>>>> Sent: Friday, September 06, 2013 10:26 AM >>>>> To: Linda Dunbar >>>>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore; Ron=20 >>>>> Parker >>>>> Subject: Re: [nsc] NSC Working Group Charter Proposal >>>>>=20 >>>>> Hi, Linda, >>>>>=20 >>>>> I have to admit that I am a bit lost with this comment or a couple >>> of >>>>> previous ones. Consequently, I wanted to send a (hopefully) >>> clarifying >>>>> summary. >>>>>=20 >>>>> The goal is to send a packet (original-payload from a service >>>>> perspective) with added service context to a service node. This is=20= >>>>> a two-step approach: we can call the steps 1. service (inner), 2. >>>>> transport. >>>>>=20 >>>>> A service chain defines a set of services applied to an original=20= >>>>> payload. To provide chain context, service path id, classification >>> info, >>>>> etc., a service-level encapsulation/header is added. This should=20= >>>>> be encapsulating-layer (transport-layer) agnostic. Second, in=20 >>>>> order get that to a service node, it gets further encapsulated (in=20= >>>>> IP, IP/GRE, IP/UDP, VXLAN, MPLS, etc) for delivery. >>>>>=20 >>>>> Being a graphical person, I also really like what Surendra shared=20= >>>>> at http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html >>>>>=20 >>>>> HTH, >>>>>=20 >>>>> -- Carlos. >>>>>=20 >>>>> On Sep 6, 2013, at 10:17 AM, Linda Dunbar=20 >>>>> >>>>> wrote: >>>>>=20 >>>>>> Ron, >>>>>>=20 >>>>>> Great! I am glad to see that we go down this path. >>>>>> We should also allow: /enet/ip/udp or tcp/nsc/... >>>>>> i.e. not necessarily having an inner IP. >>>>>>=20 >>>>>> Linda >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>> Sent: Thursday, September 05, 2013 6:16 PM >>>>>>> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore;=20 >>>>>>> nsc@ietf.org >>>>>>> Subject: RE: [nsc] NSC Working Group Charter Proposal >>>>>>>=20 >>>>>>> Hi, Linda. >>>>>>>=20 >>>>>>> As it was recently explained on this thread, I don't think it >>> needs >>>>>>> to be necessary to always have it if we are willing to allow >>>>> multiple >>>>>>> overall "transport"+service encapsulations. For example: >>>>>>>=20 >>>>>>> /enet/ip/udp/nsc/ip/tcp/... >>>>>>> /enet/ip/gre/nsc/ip/tcp/... >>>>>>> /enet/llc-snap/nsc/ip/tcp/... >>>>>>> /enet/mpls/nsc/ip/tcp/... >>>>>>>=20 >>>>>>> As much as I don't think we'll end up there, I do find a single=20= >>>>>>> overall universal transformation very attractive and any flavor >>> that >>>>>>> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same >>>>> subnet >>>>>>> or different subnet, l2 switches and/or l3 routers in between , >>>>> OpenFlow >>>>>>> or not OpenFlow, MPLS or not MPLS, ... The argument against >>> this >>>>>>> will be that the packets are bigger than they need to be for = some >>>>>>> network topologies/protocols. Simplicity or efficiency? >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>>>>> Sent: Thursday, September 05, 2013 5:19 PM >>>>>>> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; >>> nsc@ietf.org >>>>>>> Subject: RE: [nsc] NSC Working Group Charter Proposal >>>>>>>=20 >>>>>>> I can see the need for this "NSC" header inserted to the=20 >>>>>>> packets, >>>>> and >>>>>>> occasionally needing an "outer-ip" encapsulation to by-pass=20 >>>>>>> nodes that can't parse the "NSC" header. >>>>>>>=20 >>>>>>> Can someone explain why it is necessary to always have the >>> "outer- >>>>> ip" >>>>>>> header? >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>>=20 >>>>>>>> Outer-ip/udp/nsc/inner-ip/tcp/payload >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Linda >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>=20 >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 --Apple-Mail=_A8130BF6-B5F2-4A91-96A4-C94B107F7A42 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 iQIcBAEBCgAGBQJSKjzOAAoJEPcO+I7eiUJZ4McQAJLT505lmcsva9pqYpSOucQE d8+x9CUnim/YSGFRVU4g4aJ3ZfvXLRqKSWmHdvrXFMTclFlIZTo2Ln4bjOlTGBYW TCyambypzQjNX/lqrQYsFSTn4639oC58ehwCz1Y6DhAuO8dmTMiwFJb2jJ+fw4Re ap3qcbM9VXoER9MeTix53YT24xnKXV0JvtRFBMCNJdWKMDN7txS1kirIp5RNDpwD rETDmLD0GuAT/XD0W2/DWeAnDW4Qh88FXn8w5ZVssOW1TGlSi0svfXbHY06cdaeo BRS0Lrflw30ExHNZzHZ2olBl5cNUp/7pwHLWItd9Qm0jhB2viCqNlceD4wwiOcuy Xp1mTv8/TndM9hDVAA8p7yeWmsqhRlmWhwJfXsOhZeORwhSeJSx3RMBGBWRd7vZZ fmwcV5aDzcbIyrAQVdCw9D0WKKHt6lrK29gw4/K1rj1j0x/P521W9AjuU40sk2uU YSuHeE58KLPE7RbOjVN9wktqp8ClWc4DSJtZPYkRtCwhPbCM9kVEkJMMxcM8Ia2n JJrbU1mlxIvqhQFxmn978UlK3FS7ASGfdvYTkHUGxqCzLZFebx9els6WP2WQnG4h pa+cohk+kJop+bvbHMhVmGcxmoHRlY6Ntxqk8zLOQdk8GegSOKP3Wz5vAhAFUL5D /DgPZeKFbt9WasEen2iK =APYp -----END PGP SIGNATURE----- --Apple-Mail=_A8130BF6-B5F2-4A91-96A4-C94B107F7A42-- From mohamed.boucadair@orange.com Mon Sep 9 01:33: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 46CC611E8189 for ; Mon, 9 Sep 2013 01:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=1.600, 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 pCaDWKFjebEh for ; Mon, 9 Sep 2013 01:33:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 06B3321E80B4 for ; Mon, 9 Sep 2013 01:33:00 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A069D3240A3; Mon, 9 Sep 2013 10:32:59 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8529C27C054; Mon, 9 Sep 2013 10:32:59 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 9 Sep 2013 10:32:59 +0200 From: To: Ken Gray , Ron Parker , "nsc@ietf.org" Date: Mon, 9 Sep 2013 10:32:56 +0200 Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAACkCAIAADRKAgAABLQCAABHdAIAAKPeAgAAgwwCAAPvDAP//wsQAgAAPHYCABHuzcA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EF06D097B@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.9.9.70622 Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 09 Sep 2013 08:33:15 -0000 Hi Ken, I still think there is a value to include an explicit charter item for the = design choice analysis document, at least for the following reasons: * The mailing list archives can be used to retrieve some of the justificati= ons for some design choices, but the result is not guaranteed, the data is = not structured, etc.=20 * There are even some WGs that do not publish the meeting minutes...and for= those WGs it is hard to find when and why a design choice was made.=20 * IESG review may sometimes conflict with the WG consensus. Authors are inv= ited to engage in discussions to explain the motivations and provide justif= ication for the choices recorded in the draft. For the context of the nsc e= ffort, I do think that energy (time to resolve concerns) can be optimized i= f a formal tool was provided by the working group: (1) simple specification= document + (2) a companion document that motivates the design choices and = the candidates solutions that were considered.=20 * Given the aggressive proposed milestones for nsc, we need the work to be = focused so as to be able to produce the expected deliverables while being o= pen to any proposal that can put on the table.=20 Cheers, Med >-----Message d'origine----- >De=A0: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Ke= n >Gray >Envoy=E9=A0: vendredi 6 septembre 2013 17:32 >=C0=A0: Ron Parker; Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; >nsc@ietf.org >Objet=A0: Re: [nsc] NSC Working Group Charter Proposal > >Hey, Ron. > >I tend to agree with the charter proposal as is. Those four documents >should be more than adequate. > >The design/analysis document could be used as a strawman for the >discussion of the decisions imbedded in the ultimate architecture >document, but doesn't have to have a life of it's own ...those discussions >can/would typically be archived in the WG mailer (THIS mailer) for anyone >who would want to catch up on the discussion, IMO. > >(I had to capitalize the THIS because I also don't believe we need more >than THIS list to discuss WG business. This has nothing to do with Ron, >btw, I'm editorializing.) > > >On 9/6/13 10:38 AM, "Ron Parker" wrote: > >>Hi, Linda, >> >>When I referenced an inner IP, I more properly should have referenced >>"original packet", which I think you are pointing out, correctly, is not >>necessarily IP. Even in this case, I think it is important to state >>whether a new "transport" is always required in front of the "original >>packet" or not. >> >>So if we exemplify this with a layer 2 "transport" and a layer 2 original >>packet, we might have something like: >> >> /encaps-enet/llc-snap/nsc-header/original-enet/payload >> >>If we take another example of a layer 2/3/4 "transport" and a layer 2 >>original packet, we might have something like: >> >> /encaps-enet/ip/udp/nsc-header/original-enet/payload >> >>The reason I am being pedantic here is that these approaches contrast to >>other possible solutions where an outer "transport" is not added. For >>example, if we were entertaining mapping the nsc-header to a new IPv4 >>option and new IPv6 extension header for use only when the "original >>packet" is an IPv4 or IPv6 packet, then an encapsulating "transport" >>would not necessarily be required. Again, we come to >>simplicity/universality vs. efficiency (at least in terms of packet size >>if not necessarily processing requirements). >> >>This is obviously an important area to cover in the WG. Some of this >>analysis is presented in draft-boucadair-chaining-design-analysis and we >>intend to add more of this pros/cons analysis wrt the overall >>encapsulation issue in an upcoming revision. >> >>I would like to take the opportunity to back previous suggestions that a >>design choices analysis document become a part of the WG chartered >>deliverables as it encourages a more open and transparent process and >>ultimately provides a better record of how the eventual recommendations >>are arrived at. >> >> Ron >> >> >> >>-----Original Message----- >>From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>Sent: Friday, September 06, 2013 10:17 AM >>To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org >>Subject: RE: [nsc] NSC Working Group Charter Proposal >> >>Ron, >> >>Great! I am glad to see that we go down this path. >>We should also allow: /enet/ip/udp or tcp/nsc/... >>i.e. not necessarily having an inner IP. >> >>Linda >> >> >>> -----Original Message----- >>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> Sent: Thursday, September 05, 2013 6:16 PM >>> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org >>> Subject: RE: [nsc] NSC Working Group Charter Proposal >>> >>> Hi, Linda. >>> >>> As it was recently explained on this thread, I don't think it needs to >>> be necessary to always have it if we are willing to allow multiple >>> overall "transport"+service encapsulations. For example: >>> >>> /enet/ip/udp/nsc/ip/tcp/... >>> /enet/ip/gre/nsc/ip/tcp/... >>> /enet/llc-snap/nsc/ip/tcp/... >>> /enet/mpls/nsc/ip/tcp/... >>> >>> As much as I don't think we'll end up there, I do find a single >>> overall universal transformation very attractive and any flavor that >>> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same subnet >>> or different subnet, l2 switches and/or l3 routers in between , OpenFlo= w >>> or not OpenFlow, MPLS or not MPLS, ... The argument against this >>> will be that the packets are bigger than they need to be for some >>> network topologies/protocols. Simplicity or efficiency? >>> >>> Ron >>> >>> >>> >>> -----Original Message----- >>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>> Sent: Thursday, September 05, 2013 5:19 PM >>> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org >>> Subject: RE: [nsc] NSC Working Group Charter Proposal >>> >>> I can see the need for this "NSC" header inserted to the packets, and >>> occasionally needing an "outer-ip" encapsulation to by-pass nodes that >>> can't parse the "NSC" header. >>> >>> Can someone explain why it is necessary to always have the "outer-ip" >>> header? >>> >>> >>> > -----Original Message----- >>> > >>> > Outer-ip/udp/nsc/inner-ip/tcp/payload >>> >>> >>> >>> 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 jmh@joelhalpern.com Mon Sep 9 02:14:06 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEA311E81A9 for ; Mon, 9 Sep 2013 02:14:06 -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 JMA2+-QXiKMp for ; Mon, 9 Sep 2013 02:13:54 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 75F4011E81A5 for ; Mon, 9 Sep 2013 02:13:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7059A1C06EF; Mon, 9 Sep 2013 02:13:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 45B0A1C06AA; Mon, 9 Sep 2013 02:13:53 -0700 (PDT) Message-ID: <522D9151.2060701@joelhalpern.com> Date: Mon, 09 Sep 2013 05:13:53 -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: <94C682931C08B048B7A8645303FDC9F36EF06D097B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF06D097B@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "nsc@ietf.org" , Ken Gray , Ron Parker Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 09 Sep 2013 09:14:06 -0000 I agree that capturing architecture / design rationale is very useful. I don't want it in a separate from the architecture / design that it is supporting. Also, we should be careful not to get to wrapped up in getting the perfect explanation of the decisions. We need good explanations, not perfect ones with all the nuances. Yours, Joel On 9/9/13 4:32 AM, mohamed.boucadair@orange.com wrote: > Hi Ken, > > I still think there is a value to include an explicit charter item > for the design choice analysis document, at least for the following > reasons: > > * The mailing list archives can be used to retrieve some of the > justifications for some design choices, but the result is not > guaranteed, the data is not structured, etc. > > * There are even some WGs that do not publish the meeting > minutes...and for those WGs it is hard to find when and why a design > choice was made. > > * IESG review may sometimes conflict with the WG consensus. Authors > are invited to engage in discussions to explain the motivations and > provide justification for the choices recorded in the draft. For the > context of the nsc effort, I do think that energy (time to resolve > concerns) can be optimized if a formal tool was provided by the > working group: (1) simple specification document + (2) a companion > document that motivates the design choices and the candidates > solutions that were considered. > > * Given the aggressive proposed milestones for nsc, we need the work > to be focused so as to be able to produce the expected deliverables > while being open to any proposal that can put on the table. > > Cheers, Med > >> -----Message d'origine----- De : nsc-bounces@ietf.org >> [mailto:nsc-bounces@ietf.org] De la part de Ken Gray Envoyé : >> vendredi 6 septembre 2013 17:32 À : Ron Parker; Linda Dunbar; Jim >> Guichard (jguichar); Melinda Shore; nsc@ietf.org Objet : Re: [nsc] >> NSC Working Group Charter Proposal >> >> Hey, Ron. >> >> I tend to agree with the charter proposal as is. Those four >> documents should be more than adequate. >> >> The design/analysis document could be used as a strawman for the >> discussion of the decisions imbedded in the ultimate architecture >> document, but doesn't have to have a life of it's own ...those >> discussions can/would typically be archived in the WG mailer (THIS >> mailer) for anyone who would want to catch up on the discussion, >> IMO. >> >> (I had to capitalize the THIS because I also don't believe we need >> more than THIS list to discuss WG business. This has nothing to do >> with Ron, btw, I'm editorializing.) >> >> >> On 9/6/13 10:38 AM, "Ron Parker" >> wrote: >> >>> Hi, Linda, >>> >>> When I referenced an inner IP, I more properly should have >>> referenced "original packet", which I think you are pointing out, >>> correctly, is not necessarily IP. Even in this case, I think >>> it is important to state whether a new "transport" is always >>> required in front of the "original packet" or not. >>> >>> So if we exemplify this with a layer 2 "transport" and a layer 2 >>> original packet, we might have something like: >>> >>> /encaps-enet/llc-snap/nsc-header/original-enet/payload >>> >>> If we take another example of a layer 2/3/4 "transport" and a >>> layer 2 original packet, we might have something like: >>> >>> /encaps-enet/ip/udp/nsc-header/original-enet/payload >>> >>> The reason I am being pedantic here is that these approaches >>> contrast to other possible solutions where an outer "transport" >>> is not added. For example, if we were entertaining mapping the >>> nsc-header to a new IPv4 option and new IPv6 extension header for >>> use only when the "original packet" is an IPv4 or IPv6 packet, >>> then an encapsulating "transport" would not necessarily be >>> required. Again, we come to simplicity/universality vs. >>> efficiency (at least in terms of packet size if not necessarily >>> processing requirements). >>> >>> This is obviously an important area to cover in the WG. Some of >>> this analysis is presented in >>> draft-boucadair-chaining-design-analysis and we intend to add >>> more of this pros/cons analysis wrt the overall encapsulation >>> issue in an upcoming revision. >>> >>> I would like to take the opportunity to back previous suggestions >>> that a design choices analysis document become a part of the WG >>> chartered deliverables as it encourages a more open and >>> transparent process and ultimately provides a better record of >>> how the eventual recommendations are arrived at. >>> >>> Ron >>> >>> >>> >>> -----Original Message----- From: Linda Dunbar >>> [mailto:linda.dunbar@huawei.com] Sent: Friday, September 06, 2013 >>> 10:17 AM To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; >>> nsc@ietf.org Subject: RE: [nsc] NSC Working Group Charter >>> Proposal >>> >>> Ron, >>> >>> Great! I am glad to see that we go down this path. We should >>> also allow: /enet/ip/udp or tcp/nsc/... i.e. not necessarily >>> having an inner IP. >>> >>> Linda >>> >>> >>>> -----Original Message----- From: Ron Parker >>>> [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, >>>> September 05, 2013 6:16 PM To: Linda Dunbar; Jim Guichard >>>> (jguichar); Melinda Shore; nsc@ietf.org Subject: RE: [nsc] NSC >>>> Working Group Charter Proposal >>>> >>>> Hi, Linda. >>>> >>>> As it was recently explained on this thread, I don't think it >>>> needs to be necessary to always have it if we are willing to >>>> allow multiple overall "transport"+service encapsulations. >>>> For example: >>>> >>>> /enet/ip/udp/nsc/ip/tcp/... /enet/ip/gre/nsc/ip/tcp/... >>>> /enet/llc-snap/nsc/ip/tcp/... /enet/mpls/nsc/ip/tcp/... >>>> >>>> As much as I don't think we'll end up there, I do find a >>>> single overall universal transformation very attractive and any >>>> flavor that is /{l2}/ip/xxx/ip/tcp would be universally >>>> applicable -- same subnet or different subnet, l2 switches >>>> and/or l3 routers in between , OpenFlow or not OpenFlow, MPLS >>>> or not MPLS, ... The argument against this will be that the >>>> packets are bigger than they need to be for some network >>>> topologies/protocols. Simplicity or efficiency? >>>> >>>> Ron >>>> >>>> >>>> >>>> -----Original Message----- From: Linda Dunbar >>>> [mailto:linda.dunbar@huawei.com] Sent: Thursday, September 05, >>>> 2013 5:19 PM To: Ron Parker; Jim Guichard (jguichar); Melinda >>>> Shore; nsc@ietf.org Subject: RE: [nsc] NSC Working Group >>>> Charter Proposal >>>> >>>> I can see the need for this "NSC" header inserted to the >>>> packets, and occasionally needing an "outer-ip" encapsulation >>>> to by-pass nodes that can't parse the "NSC" header. >>>> >>>> Can someone explain why it is necessary to always have the >>>> "outer-ip" header? >>>> >>>> >>>>> -----Original Message----- >>>>> >>>>> Outer-ip/udp/nsc/inner-ip/tcp/payload >>>> >>>> >>>> >>>> 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 > _______________________________________________ nsc mailing list > nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc > From christian.jacquenet@orange.com Mon Sep 9 02:34: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 65BEA21E8151 for ; Mon, 9 Sep 2013 02:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[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 to9+gr4des15 for ; Mon, 9 Sep 2013 02:33:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0166321E8130 for ; Mon, 9 Sep 2013 02:33:47 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 238251B82C9; Mon, 9 Sep 2013 11:33:46 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id C843BC8058; Mon, 9 Sep 2013 11:33:45 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 9 Sep 2013 11:33:45 +0200 From: To: "Joel M. Halpern" , BOUCADAIR Mohamed IMT/OLN Date: Mon, 9 Sep 2013 11:33:44 +0200 Thread-Topic: Explicitly identifying design analysis activities in the charter Thread-Index: Ac6tPvgKt/rWZcFNTlm9NDAtkUmduA== Message-ID: <13701_1378719226_522D95FA_13701_2718_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F653EA@PUEXCB1C.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.9.9.70622 Cc: "nsc@ietf.org" , Ken Gray , Ron Parker Subject: [nsc] Explicitly identifying design analysis activities in the 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, 09 Sep 2013 09:34:00 -0000 Dear all, I share both Joel's and Med's positions. I think the design analysis should= be (1) explicitly mentioned as one of the activities conducted by the nsc = WG in its charter and (2) documented in a chartered nsc WG document (be it = the architecture document, as mentioned by Joel). Cheers, Christian. -----Message d'origine----- De=A0: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Joe= l M. Halpern Envoy=E9=A0: lundi 9 septembre 2013 11:14 =C0=A0: BOUCADAIR Mohamed IMT/OLN Cc=A0: nsc@ietf.org; Ken Gray; Ron Parker Objet=A0: Re: [nsc] NSC Working Group Charter Proposal I agree that capturing architecture / design rationale is very useful. I don't want it in a separate from the architecture / design that it is sup= porting. Also, we should be careful not to get to wrapped up in getting the perfect = explanation of the decisions. We need good explanations, not perfect ones = with all the nuances. Yours, Joel On 9/9/13 4:32 AM, mohamed.boucadair@orange.com wrote: > Hi Ken, > > I still think there is a value to include an explicit charter item for=20 > the design choice analysis document, at least for the following > reasons: > > * The mailing list archives can be used to retrieve some of the=20 > justifications for some design choices, but the result is not=20 > guaranteed, the data is not structured, etc. > > * There are even some WGs that do not publish the meeting=20 > minutes...and for those WGs it is hard to find when and why a design=20 > choice was made. > > * IESG review may sometimes conflict with the WG consensus. Authors=20 > are invited to engage in discussions to explain the motivations and=20 > provide justification for the choices recorded in the draft. For the=20 > context of the nsc effort, I do think that energy (time to resolve > concerns) can be optimized if a formal tool was provided by the=20 > working group: (1) simple specification document + (2) a companion=20 > document that motivates the design choices and the candidates=20 > solutions that were considered. > > * Given the aggressive proposed milestones for nsc, we need the work=20 > to be focused so as to be able to produce the expected deliverables=20 > while being open to any proposal that can put on the table. > > Cheers, Med > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From cpignata@cisco.com Mon Sep 9 05:33: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 8878911E81CF for ; Mon, 9 Sep 2013 05:33:42 -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 gUubPPJEbXC1 for ; Mon, 9 Sep 2013 05:33:28 -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 2C7C511E81C8 for ; Mon, 9 Sep 2013 05:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4773; q=dns/txt; s=iport; t=1378729878; x=1379939478; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=j4Pr143+SYeZcIMOrYeH98SvwQw2k2imOWCcw8GInNQ=; b=Mxb3eHgSZrSmgEnmYonpgwojjn4yMmrROm2CAglqsJVRWyjy5uT1lbYq Op5ltSIqHwp/TN0eXloxcd99Q7KhHo/BVYj/NiFfkaQzGX7W+okq5I2+8 F+gQBtqHG74SuhasYIVLiG8D/jqCf8hUYNNCaipw6YjUhPcJHu3+G9qeq Q=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwFAFa/LVKtJXG+/2dsb2JhbABbgwc4UcIUgSIWbQeCJQEBAQMBAQEBGlELBQsCAQgSBgodBycLFAMOAQEEDgUIBg2HYQYMxCkEjjeBGDEHgx2BAAOQI4EumAqDIIFxOQ X-IronPort-AV: E=Sophos;i="4.90,866,1371081600"; d="asc'?scan'208";a="257275715" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 09 Sep 2013 12:31:10 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r89CVAcY016377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 12:31:10 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 07:31:10 -0500 From: "Carlos Pignataro (cpignata)" To: "christian.jacquenet@orange.com" Thread-Topic: [nsc] Explicitly identifying design analysis activities in the charter Thread-Index: Ac6tPvgKt/rWZcFNTlm9NDAtkUmduAAQ2beA Date: Mon, 9 Sep 2013 12:31:09 +0000 Message-ID: <95067C434CE250468B77282634C96ED325F154CD@xmb-aln-x02.cisco.com> References: <13701_1378719226_522D95FA_13701_2718_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F653EA@PUEXCB1C.nanterre.francetelecom.fr> In-Reply-To: <13701_1378719226_522D95FA_13701_2718_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F653EA@PUEXCB1C.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.209.124] Content-Type: multipart/signed; boundary="Apple-Mail=_67A18AB3-5A83-4C94-ADB4-1973DAD6390A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Joel M. Halpern" , BOUCADAIR Mohamed IMT/OLN , Ken Gray , Ron Parker Subject: Re: [nsc] Explicitly identifying design analysis activities in the 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, 09 Sep 2013 12:33:42 -0000 --Apple-Mail=_67A18AB3-5A83-4C94-ADB4-1973DAD6390A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The risk, and a very real one, is that design analysis turns into design = paralysis. I support Joel's call for simplifying the doc set and not letting = perfect be the enemy of good. In this, a focused small design analysis = complementing key architectural decisions is useful, as adding color to = the main docs. Thanks, -- Carlos. On Sep 9, 2013, at 5:33 AM, christian.jacquenet@orange.com wrote: > Dear all, >=20 > I share both Joel's and Med's positions. I think the design analysis = should be (1) explicitly mentioned as one of the activities conducted by = the nsc WG in its charter and (2) documented in a chartered nsc WG = document (be it the architecture document, as mentioned by Joel). >=20 > Cheers, >=20 > Christian. >=20 > -----Message d'origine----- > De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de = Joel M. Halpern > Envoy=E9 : lundi 9 septembre 2013 11:14 > =C0 : BOUCADAIR Mohamed IMT/OLN > Cc : nsc@ietf.org; Ken Gray; Ron Parker > Objet : Re: [nsc] NSC Working Group Charter Proposal >=20 > I agree that capturing architecture / design rationale is very useful. > I don't want it in a separate from the architecture / design that it = is supporting. >=20 > Also, we should be careful not to get to wrapped up in getting the = perfect explanation of the decisions. We need good explanations, not = perfect ones with all the nuances. >=20 > Yours, > Joel >=20 > On 9/9/13 4:32 AM, mohamed.boucadair@orange.com wrote: >> Hi Ken, >>=20 >> I still think there is a value to include an explicit charter item = for=20 >> the design choice analysis document, at least for the following >> reasons: >>=20 >> * The mailing list archives can be used to retrieve some of the=20 >> justifications for some design choices, but the result is not=20 >> guaranteed, the data is not structured, etc. >>=20 >> * There are even some WGs that do not publish the meeting=20 >> minutes...and for those WGs it is hard to find when and why a design=20= >> choice was made. >>=20 >> * IESG review may sometimes conflict with the WG consensus. Authors=20= >> are invited to engage in discussions to explain the motivations and=20= >> provide justification for the choices recorded in the draft. For the=20= >> context of the nsc effort, I do think that energy (time to resolve >> concerns) can be optimized if a formal tool was provided by the=20 >> working group: (1) simple specification document + (2) a companion=20 >> document that motivates the design choices and the candidates=20 >> solutions that were considered. >>=20 >> * Given the aggressive proposed milestones for nsc, we need the work=20= >> to be focused so as to be able to produce the expected deliverables=20= >> while being open to any proposal that can put on the table. >>=20 >> Cheers, Med >>=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc --Apple-Mail=_67A18AB3-5A83-4C94-ADB4-1973DAD6390A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlItv40ACgkQtfDPGTp3USwtfACgtFK+PVt/I20NiAg7cu25i0b+ GQ0An0CR08y4sP47F9Oex+teOn7FyCkQ =3Gm2 -----END PGP SIGNATURE----- --Apple-Mail=_67A18AB3-5A83-4C94-ADB4-1973DAD6390A-- From jguichar@cisco.com Mon Sep 9 05:37: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 1B97411E81B2 for ; Mon, 9 Sep 2013 05:37:00 -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 0d197Z6hKxoS for ; Mon, 9 Sep 2013 05:36:48 -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 75C6A21F893B for ; Mon, 9 Sep 2013 05:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4411; q=dns/txt; s=iport; t=1378730076; x=1379939676; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=d5B/JQKnWUpl9QiNK+xlCgFE7RLb/X70NCwGAUU3z5I=; b=SkNuiHgFxvVTzLak8IZUBXmJ55h3sSrm7MfLUso4imNlYSTF/tfaQdlq RS+iC1CIGPek0fsvFCSuEGWB7GA+eP9BcyUm1YowvPJcAF6EdAH7cHq+S QEuE9V6cJFcqzc4XgeXkzZibC+6VG2LBIlPMTUCg6hxjGu8Mba5WTq425 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAFa/LVKtJV2a/2dsb2JhbABbgwc4RcIggSIWdIIlAQEBAwEBAQEaUQsFCwIBCBIGJwcnCxQDDgIEDgUbh2EGDMQpBI43gRYzB4MdgQADiH2OeJFmgyCBcQ X-IronPort-AV: E=Sophos;i="4.90,866,1371081600"; d="scan'208";a="257293737" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 09 Sep 2013 12:34:35 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r89CYZhj030377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 12:34:35 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 07:34:35 -0500 From: "Jim Guichard (jguichar)" To: "Carlos Pignataro (cpignata)" Thread-Topic: [nsc] Explicitly identifying design analysis activities in the charter Thread-Index: AQHOrVjV4bgNHegcwEKz80/FO72r4pm9Vy/C Date: Mon, 9 Sep 2013 12:34:34 +0000 Message-ID: <6FA90B5B-A5FC-4FB8-A706-D9C107478AD0@cisco.com> References: <13701_1378719226_522D95FA_13701_2718_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F653EA@PUEXCB1C.nanterre.francetelecom.fr>, <95067C434CE250468B77282634C96ED325F154CD@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED325F154CD@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "christian.jacquenet@orange.com" , Ken Gray , Ron Parker , "Joel M. Halpern" , BOUCADAIR Mohamed IMT/OLN Subject: Re: [nsc] Explicitly identifying design analysis activities in the 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, 09 Sep 2013 12:37:00 -0000 +1 Sent from my iPhone On Sep 9, 2013, at 8:33 AM, "Carlos Pignataro (cpignata)" wrote: > The risk, and a very real one, is that design analysis turns into design = paralysis. >=20 > I support Joel's call for simplifying the doc set and not letting perfect= be the enemy of good. In this, a focused small design analysis complementi= ng key architectural decisions is useful, as adding color to the main docs. >=20 > Thanks, >=20 > -- Carlos. >=20 > On Sep 9, 2013, at 5:33 AM, christian.jacquenet@orange.com wrote: >=20 >> Dear all, >>=20 >> I share both Joel's and Med's positions. I think the design analysis sho= uld be (1) explicitly mentioned as one of the activities conducted by the n= sc WG in its charter and (2) documented in a chartered nsc WG document (be = it the architecture document, as mentioned by Joel). >>=20 >> Cheers, >>=20 >> Christian. >>=20 >> -----Message d'origine----- >> De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Jo= el M. Halpern >> Envoy=E9 : lundi 9 septembre 2013 11:14 >> =C0 : BOUCADAIR Mohamed IMT/OLN >> Cc : nsc@ietf.org; Ken Gray; Ron Parker >> Objet : Re: [nsc] NSC Working Group Charter Proposal >>=20 >> I agree that capturing architecture / design rationale is very useful. >> I don't want it in a separate from the architecture / design that it is = supporting. >>=20 >> Also, we should be careful not to get to wrapped up in getting the perfe= ct explanation of the decisions. We need good explanations, not perfect on= es with all the nuances. >>=20 >> Yours, >> Joel >>=20 >> On 9/9/13 4:32 AM, mohamed.boucadair@orange.com wrote: >>> Hi Ken, >>>=20 >>> I still think there is a value to include an explicit charter item for= =20 >>> the design choice analysis document, at least for the following >>> reasons: >>>=20 >>> * The mailing list archives can be used to retrieve some of the=20 >>> justifications for some design choices, but the result is not=20 >>> guaranteed, the data is not structured, etc. >>>=20 >>> * There are even some WGs that do not publish the meeting=20 >>> minutes...and for those WGs it is hard to find when and why a design=20 >>> choice was made. >>>=20 >>> * IESG review may sometimes conflict with the WG consensus. Authors=20 >>> are invited to engage in discussions to explain the motivations and=20 >>> provide justification for the choices recorded in the draft. For the=20 >>> context of the nsc effort, I do think that energy (time to resolve >>> concerns) can be optimized if a formal tool was provided by the=20 >>> working group: (1) simple specification document + (2) a companion=20 >>> document that motivates the design choices and the candidates=20 >>> solutions that were considered. >>>=20 >>> * Given the aggressive proposed milestones for nsc, we need the work=20 >>> to be focused so as to be able to produce the expected deliverables=20 >>> while being open to any proposal that can put on the table. >>>=20 >>> Cheers, Med >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=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 mohamed.boucadair@orange.com Mon Sep 9 06:04:36 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82F821E81D1 for ; Mon, 9 Sep 2013 06:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.400, 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 JkvSUztpgSBi for ; Mon, 9 Sep 2013 06:04:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E9C2C21E81AE for ; Mon, 9 Sep 2013 06:01:20 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 126BB324252; Mon, 9 Sep 2013 15:01:18 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id E3E3C35C061; Mon, 9 Sep 2013 15:01:17 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 9 Sep 2013 15:01:14 +0200 From: To: "Carlos Pignataro (cpignata)" , JACQUENET Christian IMT/OLN Date: Mon, 9 Sep 2013 15:01:10 +0200 Thread-Topic: [nsc] Explicitly identifying design analysis activities in the charter Thread-Index: Ac6tPvgKt/rWZcFNTlm9NDAtkUmduAAQ2beAAAnYU3A= Message-ID: <94C682931C08B048B7A8645303FDC9F36EF06D0B4A@PUEXCB1B.nanterre.francetelecom.fr> References: <13701_1378719226_522D95FA_13701_2718_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F653EA@PUEXCB1C.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED325F154CD@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED325F154CD@xmb-aln-x02.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.9.84816 Cc: "nsc@ietf.org" , "Joel M. Halpern" , Ken Gray , Ron Parker Subject: Re: [nsc] Explicitly identifying design analysis activities in the 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, 09 Sep 2013 13:04:36 -0000 Hi Carlos, If there is a risk for paralysis then the root causes are elsewhere ... not= in the analysis itself.=20 We all agree there is no perfect solution. That's not the point. The main p= oint of the analysis is to explain the design choices and make sure we are = not over specifying as per: "A protocol design is complete not when you can't think of any more things to add, but when you have removed everything you can and you can't see how to remove any more", Cheers, Med >-----Message d'origine----- >De=A0: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >Envoy=E9=A0: lundi 9 septembre 2013 14:31 >=C0=A0: JACQUENET Christian IMT/OLN >Cc=A0: Joel M. Halpern; BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org; Ken Gray; >Ron Parker >Objet=A0: Re: [nsc] Explicitly identifying design analysis activities in t= he >charter > >The risk, and a very real one, is that design analysis turns into design >paralysis. > >I support Joel's call for simplifying the doc set and not letting perfect >be the enemy of good. In this, a focused small design analysis >complementing key architectural decisions is useful, as adding color to th= e >main docs. > >Thanks, > >-- Carlos. > >On Sep 9, 2013, at 5:33 AM, christian.jacquenet@orange.com wrote: > >> Dear all, >> >> I share both Joel's and Med's positions. I think the design analysis >should be (1) explicitly mentioned as one of the activities conducted by >the nsc WG in its charter and (2) documented in a chartered nsc WG documen= t >(be it the architecture document, as mentioned by Joel). >> >> Cheers, >> >> Christian. >> >> -----Message d'origine----- >> De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de >Joel M. Halpern >> Envoy=E9 : lundi 9 septembre 2013 11:14 >> =C0 : BOUCADAIR Mohamed IMT/OLN >> Cc : nsc@ietf.org; Ken Gray; Ron Parker >> Objet : Re: [nsc] NSC Working Group Charter Proposal >> >> I agree that capturing architecture / design rationale is very useful. >> I don't want it in a separate from the architecture / design that it is >supporting. >> >> Also, we should be careful not to get to wrapped up in getting the >perfect explanation of the decisions. We need good explanations, not >perfect ones with all the nuances. >> >> Yours, >> Joel >> >> On 9/9/13 4:32 AM, mohamed.boucadair@orange.com wrote: >>> Hi Ken, >>> >>> I still think there is a value to include an explicit charter item for >>> the design choice analysis document, at least for the following >>> reasons: >>> >>> * The mailing list archives can be used to retrieve some of the >>> justifications for some design choices, but the result is not >>> guaranteed, the data is not structured, etc. >>> >>> * There are even some WGs that do not publish the meeting >>> minutes...and for those WGs it is hard to find when and why a design >>> choice was made. >>> >>> * IESG review may sometimes conflict with the WG consensus. Authors >>> are invited to engage in discussions to explain the motivations and >>> provide justification for the choices recorded in the draft. For the >>> context of the nsc effort, I do think that energy (time to resolve >>> concerns) can be optimized if a formal tool was provided by the >>> working group: (1) simple specification document + (2) a companion >>> document that motivates the design choices and the candidates >>> solutions that were considered. >>> >>> * Given the aggressive proposed milestones for nsc, we need the work >>> to be focused so as to be able to produce the expected deliverables >>> while being open to any proposal that can put on the table. >>> >>> Cheers, Med >>> >> >> >__________________________________________________________________________= _ >______________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc From cpignata@cisco.com Mon Sep 9 06:15: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 46C6321E81AD for ; Mon, 9 Sep 2013 06:15:00 -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 iQg+cOtHDsSK for ; Mon, 9 Sep 2013 06:14:48 -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 1938D21E81A9 for ; Mon, 9 Sep 2013 06:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6727; q=dns/txt; s=iport; t=1378732467; x=1379942067; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+W7J+L+JOW0Pd/61PXFUS6lTrm4D8iHuZEgATinaTQc=; b=aqB38LxYZwfEcAWCcxnX3B9bJGgPlLlvsw0uJQxMCVNrz1AJZWW8ZlkF vxBom2xIIsirX/Y6Yz8eAXvkPmUafvM+MvgpH9K/Xbcd0/GjA/RLbQFUH uDs+JlSLgO7sXF2m4laShn2o2AZHK09SE1IDPq3HNv9XI32WJhyHGZPnK A=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAPPILVKtJV2b/2dsb2JhbABbgwc4UcIUgSIWdIIlAQEBAwEBAQEaUQsFCwIBCBIGCh0HJwsUAw4BAQQOBQgGDYdhBgzEOQSONwqBDjEHgx2BAAOQI4EumAqDIIFoCRci X-IronPort-AV: E=Sophos;i="4.90,866,1371081600"; d="asc'?scan'208";a="257342387" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 09 Sep 2013 13:14:26 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r89DEQjY025071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 13:14:26 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 08:14:26 -0500 From: "Carlos Pignataro (cpignata)" To: " " Thread-Topic: [nsc] Explicitly identifying design analysis activities in the charter Thread-Index: Ac6tPvgKt/rWZcFNTlm9NDAtkUmduAAQ2beAAAnYU3D//71UgA== Date: Mon, 9 Sep 2013 13:14:25 +0000 Message-ID: <95067C434CE250468B77282634C96ED325F1584E@xmb-aln-x02.cisco.com> References: <13701_1378719226_522D95FA_13701_2718_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F653EA@PUEXCB1C.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED325F154CD@xmb-aln-x02.cisco.com> <94C682931C08B048B7A8645303FDC9F36EF06D0B4A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF06D0B4A@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.209.124] Content-Type: multipart/signed; boundary="Apple-Mail=_0120F8D9-7463-4D51-B989-3A3AEE4FD2CE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Joel M. Halpern" , Ron Parker , Ken Gray , JACQUENET Christian IMT/OLN Subject: Re: [nsc] Explicitly identifying design analysis activities in the 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, 09 Sep 2013 13:15:00 -0000 --Apple-Mail=_0120F8D9-7463-4D51-B989-3A3AEE4FD2CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Med, Thanks for the follow-up, please see inline. On Sep 9, 2013, at 9:01 AM, wrote: > Hi Carlos, >=20 > If there is a risk for paralysis then the root causes are elsewhere = ... not in the analysis itself.=20 >=20 > We all agree there is no perfect solution. I think that the best approach is to sparringly sprinkle analysis = details when needed for a particularly important or contentious = decision, inside another doc as per charter, and not peanut-butter = (meaning adding unconditionally everywhere) design decision rationale or = create a new doc. > That's not the point. The main point of the analysis is to explain the = design choices and make sure we are not over specifying as per: I would not feel the need to explain every design choice. Only very = small number of limited ones. >=20 > "A protocol design is complete not when you can't think of any > more things to add, but when you have removed everything you can > and you can't see how to remove any more", >=20 "Il semble que la perfection soit atteinte non quand il n'y a plus rien = =E0 ajouter, mais quand il n'y a plus rien =E0 retrancher.", Antoine de = Saint Exup=E9ry. And RFC 1925.=20 Indeed, that should be a guiding principle here. Thanks, -- Carlos. > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >> Envoy=E9 : lundi 9 septembre 2013 14:31 >> =C0 : JACQUENET Christian IMT/OLN >> Cc : Joel M. Halpern; BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org; Ken = Gray; >> Ron Parker >> Objet : Re: [nsc] Explicitly identifying design analysis activities = in the >> charter >>=20 >> The risk, and a very real one, is that design analysis turns into = design >> paralysis. >>=20 >> I support Joel's call for simplifying the doc set and not letting = perfect >> be the enemy of good. In this, a focused small design analysis >> complementing key architectural decisions is useful, as adding color = to the >> main docs. >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >> On Sep 9, 2013, at 5:33 AM, christian.jacquenet@orange.com wrote: >>=20 >>> Dear all, >>>=20 >>> I share both Joel's and Med's positions. I think the design analysis >> should be (1) explicitly mentioned as one of the activities conducted = by >> the nsc WG in its charter and (2) documented in a chartered nsc WG = document >> (be it the architecture document, as mentioned by Joel). >>>=20 >>> Cheers, >>>=20 >>> Christian. >>>=20 >>> -----Message d'origine----- >>> De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part = de >> Joel M. Halpern >>> Envoy=E9 : lundi 9 septembre 2013 11:14 >>> =C0 : BOUCADAIR Mohamed IMT/OLN >>> Cc : nsc@ietf.org; Ken Gray; Ron Parker >>> Objet : Re: [nsc] NSC Working Group Charter Proposal >>>=20 >>> I agree that capturing architecture / design rationale is very = useful. >>> I don't want it in a separate from the architecture / design that it = is >> supporting. >>>=20 >>> Also, we should be careful not to get to wrapped up in getting the >> perfect explanation of the decisions. We need good explanations, not >> perfect ones with all the nuances. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 9/9/13 4:32 AM, mohamed.boucadair@orange.com wrote: >>>> Hi Ken, >>>>=20 >>>> I still think there is a value to include an explicit charter item = for >>>> the design choice analysis document, at least for the following >>>> reasons: >>>>=20 >>>> * The mailing list archives can be used to retrieve some of the >>>> justifications for some design choices, but the result is not >>>> guaranteed, the data is not structured, etc. >>>>=20 >>>> * There are even some WGs that do not publish the meeting >>>> minutes...and for those WGs it is hard to find when and why a = design >>>> choice was made. >>>>=20 >>>> * IESG review may sometimes conflict with the WG consensus. Authors >>>> are invited to engage in discussions to explain the motivations and >>>> provide justification for the choices recorded in the draft. For = the >>>> context of the nsc effort, I do think that energy (time to resolve >>>> concerns) can be optimized if a formal tool was provided by the >>>> working group: (1) simple specification document + (2) a companion >>>> document that motivates the design choices and the candidates >>>> solutions that were considered. >>>>=20 >>>> * Given the aggressive proposed milestones for nsc, we need the = work >>>> to be focused so as to be able to produce the expected deliverables >>>> while being open to any proposal that can put on the table. >>>>=20 >>>> Cheers, Med >>>>=20 >>>=20 >>>=20 >> = __________________________________________________________________________= _ >> ______________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez >> recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages >> electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, = deforme >> ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or = privileged >> information that may be protected by law; >>> they should not be distributed, used or copied without = authorisation. >>> If you have received this email in error, please notify the sender = and >> delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have >> been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >=20 --Apple-Mail=_0120F8D9-7463-4D51-B989-3A3AEE4FD2CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlItybEACgkQtfDPGTp3USy/nQCeI4XOWieRYC9/X8PouuQ23jzW nKUAoM/eWfoGpS7E8dF4T2i1OHTgI9M7 =tw/i -----END PGP SIGNATURE----- --Apple-Mail=_0120F8D9-7463-4D51-B989-3A3AEE4FD2CE-- From jguichar@cisco.com Mon Sep 9 06:36: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 8D6D811E81D4 for ; Mon, 9 Sep 2013 06:36:09 -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 otG49MChcAR3 for ; Mon, 9 Sep 2013 06:35:57 -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 692F111E81B6 for ; Mon, 9 Sep 2013 06:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6678; q=dns/txt; s=iport; t=1378733757; x=1379943357; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/dkWFP0BZBMHfLBYgySPyyQUukkxnuw2UscA9DykVwo=; b=TFiVd/+ssbmVdoM2ZpClfr/jcn4wWS852wxX+V65q7iIfnfGbncLmhZg svLcgL++chUyXI6E+X1xAf0pwkJojSaw2WCH48Zx+CXl5bdDm2nDHM8HE BWMW3281txPOBoVwwtEsAztdur5ZsUsJkdY3cuNoAiczXXim6KabB55qc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAF7OLVKtJXG8/2dsb2JhbABbgwc4UcIUgSIWdIIlAQEBBAEBARpKBwsSAQgSBgodLgsUAw4CBAENBQgTh2cMxBEEjjcKgQwCMQeDHYEAA4h9oF6DIIFoCRci X-IronPort-AV: E=Sophos;i="4.90,866,1371081600"; d="scan'208";a="257331910" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 09 Sep 2013 13:35:55 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r89DZtUk007037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 13:35:55 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 08:35:55 -0500 From: "Jim Guichard (jguichar)" To: "Carlos Pignataro (cpignata)" , " " Thread-Topic: [nsc] Explicitly identifying design analysis activities in the charter Thread-Index: AQHOrWGCLOiQ00c0Lkqv1k8ckwe4/Q== Date: Mon, 9 Sep 2013 13:35:54 +0000 Message-ID: <68B171751455884590F8E38E96416F363F67A751@xmb-rcd-x01.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED325F1584E@xmb-aln-x02.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.131.36.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1EE33671FD1DCE45974334ADBC59C48F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Joel M. Halpern" , Ken Gray , Ron Parker , JACQUENET Christian IMT/OLN Subject: Re: [nsc] Explicitly identifying design analysis activities in the 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, 09 Sep 2013 13:36:09 -0000 I agree wholeheartedly with Carlos that the best approach is to include design analysis within individual documents where appropriate; it seems unnecessary and overly complex to try and write a single analysis document that details all valid and non-valid design choices as many will be obvious such as the rejection of the notion of placing post-it's on the backs of carrier pigeons to enable service chaining! On 9/9/13 9:14 AM, "Carlos Pignataro (cpignata)" wrote: >Hi, Med, > >Thanks for the follow-up, please see inline. > >On Sep 9, 2013, at 9:01 AM, > wrote: > >> Hi Carlos, >>=20 >> If there is a risk for paralysis then the root causes are elsewhere ... >>not in the analysis itself. >>=20 >> We all agree there is no perfect solution. > >I think that the best approach is to sparringly sprinkle analysis details >when needed for a particularly important or contentious decision, inside >another doc as per charter, and not peanut-butter (meaning adding >unconditionally everywhere) design decision rationale or create a new doc. > >> That's not the point. The main point of the analysis is to explain the >>design choices and make sure we are not over specifying as per: > >I would not feel the need to explain every design choice. Only very small >number of limited ones. > >>=20 >> "A protocol design is complete not when you can't think of any >> more things to add, but when you have removed everything you can >> and you can't see how to remove any more", >>=20 > >"Il semble que la perfection soit atteinte non quand il n'y a plus rien = =E0 >ajouter, mais quand il n'y a plus rien =E0 retrancher.", Antoine de Saint >Exup=E9ry. > >And RFC 1925.=20 > >Indeed, that should be a guiding principle here. > >Thanks, > >-- Carlos. > >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>> Envoy=E9 : lundi 9 septembre 2013 14:31 >>> =C0 : JACQUENET Christian IMT/OLN >>> Cc : Joel M. Halpern; BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org; Ken >>>Gray; >>> Ron Parker >>> Objet : Re: [nsc] Explicitly identifying design analysis activities in >>>the >>> charter >>>=20 >>> The risk, and a very real one, is that design analysis turns into >>>design >>> paralysis. >>>=20 >>> I support Joel's call for simplifying the doc set and not letting >>>perfect >>> be the enemy of good. In this, a focused small design analysis >>> complementing key architectural decisions is useful, as adding color >>>to the >>> main docs. >>>=20 >>> Thanks, >>>=20 >>> -- Carlos. >>>=20 >>> On Sep 9, 2013, at 5:33 AM, christian.jacquenet@orange.com wrote: >>>=20 >>>> Dear all, >>>>=20 >>>> I share both Joel's and Med's positions. I think the design analysis >>> should be (1) explicitly mentioned as one of the activities conducted >>>by >>> the nsc WG in its charter and (2) documented in a chartered nsc WG >>>document >>> (be it the architecture document, as mentioned by Joel). >>>>=20 >>>> Cheers, >>>>=20 >>>> Christian. >>>>=20 >>>> -----Message d'origine----- >>>> De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de >>> Joel M. Halpern >>>> Envoy=E9 : lundi 9 septembre 2013 11:14 >>>> =C0 : BOUCADAIR Mohamed IMT/OLN >>>> Cc : nsc@ietf.org; Ken Gray; Ron Parker >>>> Objet : Re: [nsc] NSC Working Group Charter Proposal >>>>=20 >>>> I agree that capturing architecture / design rationale is very useful. >>>> I don't want it in a separate from the architecture / design that it >>>>is >>> supporting. >>>>=20 >>>> Also, we should be careful not to get to wrapped up in getting the >>> perfect explanation of the decisions. We need good explanations, not >>> perfect ones with all the nuances. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 9/9/13 4:32 AM, mohamed.boucadair@orange.com wrote: >>>>> Hi Ken, >>>>>=20 >>>>> I still think there is a value to include an explicit charter item >>>>>for >>>>> the design choice analysis document, at least for the following >>>>> reasons: >>>>>=20 >>>>> * The mailing list archives can be used to retrieve some of the >>>>> justifications for some design choices, but the result is not >>>>> guaranteed, the data is not structured, etc. >>>>>=20 >>>>> * There are even some WGs that do not publish the meeting >>>>> minutes...and for those WGs it is hard to find when and why a design >>>>> choice was made. >>>>>=20 >>>>> * IESG review may sometimes conflict with the WG consensus. Authors >>>>> are invited to engage in discussions to explain the motivations and >>>>> provide justification for the choices recorded in the draft. For the >>>>> context of the nsc effort, I do think that energy (time to resolve >>>>> concerns) can be optimized if a formal tool was provided by the >>>>> working group: (1) simple specification document + (2) a companion >>>>> document that motivates the design choices and the candidates >>>>> solutions that were considered. >>>>>=20 >>>>> * Given the aggressive proposed milestones for nsc, we need the work >>>>> to be focused so as to be able to produce the expected deliverables >>>>> while being open to any proposal that can put on the table. >>>>>=20 >>>>> Cheers, Med >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>________________________________________________________________________ >>>___ >>> ______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>> recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>>>messages >>> electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, >>>>deforme >>> ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>>privileged >>> information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and >>> delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have >>> been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>=20 > From kgray@juniper.net Mon Sep 9 07: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 937EC11E820B for ; Mon, 9 Sep 2013 07:54:13 -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 JMOAgtafF6tz for ; Mon, 9 Sep 2013 07:54:01 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id 5071421E81C8 for ; Mon, 9 Sep 2013 07:44:38 -0700 (PDT) Received: from mail72-db8-R.bigfish.com (10.174.8.244) by DB8EHSOBE042.bigfish.com (10.174.4.105) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 14:44:37 +0000 Received: from mail72-db8 (localhost [127.0.0.1]) by mail72-db8-R.bigfish.com (Postfix) with ESMTP id 0E18C14014A; Mon, 9 Sep 2013 14:44:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -72 X-BigFish: VPS-72(zzbb2dI98dI9371Ic89bh542I1432I15caKJdb82h853kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail72-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(479174003)(55784002)(24454002)(13464003)(189002)(51704005)(199002)(79102001)(81816001)(69226001)(80976001)(74876001)(561944002)(65816001)(51856001)(76176001)(76796001)(76786001)(46102001)(36756003)(81542001)(49866001)(47736001)(19580395003)(47976001)(50986001)(81686001)(81342001)(63696002)(19580405001)(83322001)(4396001)(74366001)(80022001)(83506001)(54316002)(56776001)(76482001)(53806001)(54356001)(77096001)(56816003)(59766001)(77982001)(47446002)(74502001)(83072001)(74706001)(31966008)(74662001)(21314002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB083; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail72-db8 (localhost.localdomain [127.0.0.1]) by mail72-db8 (MessageSwitch) id 1378737875206517_26198; Mon, 9 Sep 2013 14:44:35 +0000 (UTC) Received: from DB8EHSMHS003.bigfish.com (unknown [10.174.8.251]) by mail72-db8.bigfish.com (Postfix) with ESMTP id 2E18C8C0040; Mon, 9 Sep 2013 14:44:35 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS003.bigfish.com (10.174.4.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 14:44:35 +0000 Received: from BL2PR05MB083.namprd05.prod.outlook.com (10.255.232.26) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Mon, 9 Sep 2013 14:44:33 +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.745.25; Mon, 9 Sep 2013 14:44:32 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.191]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.191]) with mapi id 15.00.0745.000; Mon, 9 Sep 2013 14:44:32 +0000 From: Ken Gray To: "mohamed.boucadair@orange.com" , Ron Parker , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGCAACkCAIAADRKAgAABLQCAABHdAIAAKPeAgAAgwwCAAPvDAP//wsQAgAAPHYCABHuzcIAALegA Date: Mon, 9 Sep 2013 14:44:31 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF06D097B@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 09645BAC66 Content-Type: text/plain; charset="iso-8859-1" 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% Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 09 Sep 2013 14:54:13 -0000 Med, your arguments FOR doing this seem (to me) to be couched in correcting the way the IETF generally works within THIS workgroup. If there are shortcomings in the way we collect discussions/data (e.g. a need for structured data for research purposes), then they should be addressed at a higher level than within a single workgroup. The same can be said for any perceived historical mismatch between IESG review and consensus. =20 As to meeting notes, again, failures to publish should be noted to the chairs. =20 On 9/9/13 4:32 AM, "mohamed.boucadair@orange.com" wrote: >Hi Ken, > >I still think there is a value to include an explicit charter item for >the design choice analysis document, at least for the following reasons: > >* The mailing list archives can be used to retrieve some of the >justifications for some design choices, but the result is not guaranteed, >the data is not structured, etc. > >* There are even some WGs that do not publish the meeting minutes...and >for those WGs it is hard to find when and why a design choice was made. > >* IESG review may sometimes conflict with the WG consensus. Authors are >invited to engage in discussions to explain the motivations and provide >justification for the choices recorded in the draft. For the context of >the nsc effort, I do think that energy (time to resolve concerns) can be >optimized if a formal tool was provided by the working group: (1) simple >specification document + (2) a companion document that motivates the >design choices and the candidates solutions that were considered. > >* Given the aggressive proposed milestones for nsc, we need the work to >be focused so as to be able to produce the expected deliverables while >being open to any proposal that can put on the table. > >Cheers, >Med > >>-----Message d'origine----- >>De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Ken >>Gray >>Envoy=E9 : vendredi 6 septembre 2013 17:32 >>=C0 : Ron Parker; Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; >>nsc@ietf.org >>Objet : Re: [nsc] NSC Working Group Charter Proposal >> >>Hey, Ron. >> >>I tend to agree with the charter proposal as is. Those four documents >>should be more than adequate. >> >>The design/analysis document could be used as a strawman for the >>discussion of the decisions imbedded in the ultimate architecture >>document, but doesn't have to have a life of it's own ...those >>discussions >>can/would typically be archived in the WG mailer (THIS mailer) for anyone >>who would want to catch up on the discussion, IMO. >> >>(I had to capitalize the THIS because I also don't believe we need more >>than THIS list to discuss WG business. This has nothing to do with Ron, >>btw, I'm editorializing.) >> >> >>On 9/6/13 10:38 AM, "Ron Parker" wrote: >> >>>Hi, Linda, >>> >>>When I referenced an inner IP, I more properly should have referenced >>>"original packet", which I think you are pointing out, correctly, is not >>>necessarily IP. Even in this case, I think it is important to state >>>whether a new "transport" is always required in front of the "original >>>packet" or not. >>> >>>So if we exemplify this with a layer 2 "transport" and a layer 2 >>>original >>>packet, we might have something like: >>> >>> /encaps-enet/llc-snap/nsc-header/original-enet/payload >>> >>>If we take another example of a layer 2/3/4 "transport" and a layer 2 >>>original packet, we might have something like: >>> >>> /encaps-enet/ip/udp/nsc-header/original-enet/payload >>> >>>The reason I am being pedantic here is that these approaches contrast to >>>other possible solutions where an outer "transport" is not added. For >>>example, if we were entertaining mapping the nsc-header to a new IPv4 >>>option and new IPv6 extension header for use only when the "original >>>packet" is an IPv4 or IPv6 packet, then an encapsulating "transport" >>>would not necessarily be required. Again, we come to >>>simplicity/universality vs. efficiency (at least in terms of packet size >>>if not necessarily processing requirements). >>> >>>This is obviously an important area to cover in the WG. Some of this >>>analysis is presented in draft-boucadair-chaining-design-analysis and we >>>intend to add more of this pros/cons analysis wrt the overall >>>encapsulation issue in an upcoming revision. >>> >>>I would like to take the opportunity to back previous suggestions that a >>>design choices analysis document become a part of the WG chartered >>>deliverables as it encourages a more open and transparent process and >>>ultimately provides a better record of how the eventual recommendations >>>are arrived at. >>> >>> Ron >>> >>> >>> >>>-----Original Message----- >>>From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>Sent: Friday, September 06, 2013 10:17 AM >>>To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org >>>Subject: RE: [nsc] NSC Working Group Charter Proposal >>> >>>Ron, >>> >>>Great! I am glad to see that we go down this path. >>>We should also allow: /enet/ip/udp or tcp/nsc/... >>>i.e. not necessarily having an inner IP. >>> >>>Linda >>> >>> >>>> -----Original Message----- >>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>> Sent: Thursday, September 05, 2013 6:16 PM >>>> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org >>>> Subject: RE: [nsc] NSC Working Group Charter Proposal >>>> >>>> Hi, Linda. >>>> >>>> As it was recently explained on this thread, I don't think it needs to >>>> be necessary to always have it if we are willing to allow multiple >>>> overall "transport"+service encapsulations. For example: >>>> >>>> /enet/ip/udp/nsc/ip/tcp/... >>>> /enet/ip/gre/nsc/ip/tcp/... >>>> /enet/llc-snap/nsc/ip/tcp/... >>>> /enet/mpls/nsc/ip/tcp/... >>>> >>>> As much as I don't think we'll end up there, I do find a single >>>> overall universal transformation very attractive and any flavor that >>>> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same subnet >>>> or different subnet, l2 switches and/or l3 routers in between , >>>>OpenFlow >>>> or not OpenFlow, MPLS or not MPLS, ... The argument against this >>>> will be that the packets are bigger than they need to be for some >>>> network topologies/protocols. Simplicity or efficiency? >>>> >>>> Ron >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>> Sent: Thursday, September 05, 2013 5:19 PM >>>> To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; nsc@ietf.org >>>> Subject: RE: [nsc] NSC Working Group Charter Proposal >>>> >>>> I can see the need for this "NSC" header inserted to the packets, and >>>> occasionally needing an "outer-ip" encapsulation to by-pass nodes that >>>> can't parse the "NSC" header. >>>> >>>> Can someone explain why it is necessary to always have the "outer-ip" >>>> header? >>>> >>>> >>>> > -----Original Message----- >>>> > >>>> > Outer-ip/udp/nsc/inner-ip/tcp/payload >>>> >>>> >>>> >>>> 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 damascene.joachimpillai@verizon.com Wed Sep 4 11:36: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 4145E11E810B for ; Wed, 4 Sep 2013 11:36:42 -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 gybZWXlOaWe2 for ; Wed, 4 Sep 2013 11:36:36 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9D12911E80E7 for ; Wed, 4 Sep 2013 11:36:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe01.verizonbusiness.com with ESMTP; 04 Sep 2013 18:36:35 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208";a="541271414" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 04 Sep 2013 18:36:35 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Wed, 4 Sep 2013 14:36:35 -0400 To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" Date: Wed, 4 Sep 2013 14:36:33 -0400 Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: Ac6pnTssjGimBAbpQ121burQuzM+5AAAE8ZQ Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB012331636B@FHDP1LUMXC7V31.us.one.verizon.com> References: <68B171751455884590F8E38E96416F363F672511@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EF0336604@PUEXCB1B.nanterre.francetelecom.fr> <52277CE1.60805@joelhalpern.com> In-Reply-To: <52277CE1.60805@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 09 Sep 2013 08:19:44 -0700 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 04 Sep 2013 18:36:42 -0000 I completely concur with Joel here. I think we need two things: 1) A clear problem statement 2) An Architecture that addresses the problem=20 Once these two are established then we can go into the details of how. -- DJ -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Joel = M. Halpern Sent: Wednesday, September 04, 2013 2:33 PM To: mohamed.boucadair@orange.com Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] NSC Working Group Charter Proposal Clipping for focus... On 9/4/13 10:05 AM, mohamed.boucadair@orange.com wrote: > Hi Jim, > > Thank you for preparing the text. ... > To sum up: my suggestion is to go for this set of deliverables: > > (a) Problem Statement document > > (b) Framework document (terminology, functional elements,=20 > architecture, and overall procedure) > > (c) Requirements document > > (d) Design Analysis document > > (e) Specification document(s) > > I wouldn't object if the first charter of the future WG covers only=20 > items (a) to (d). An updated charter can be envisaged once the future=20 > WG has more visibility on the detailed set of specification documents. > > Cheers, > > Med I find this list difficult to understand. And the omissions of certain ite= ms from the previous proposal cause me personally some concern. Separating the problem statement, framework, requirements, and "design anal= ysis" produces a multiplicity of documents which will divide the WGs effort= s without, as far as I can tell, improving clarity. I also find the notion of a Design Analysis odd. What we need is an archit= ecture or design to drive the protocol effort. From where I sit, we need t= o pick an approach to the problem, and document that pick. In many ways, i= t is quite likely that we will have to pick simply because a choice is need= ed, not because one is universally better than another. I would strongly p= refer that the focus of the document be on the actual answer. Similarly, while I find use case drafts useful information for the WG to co= nsider, I think that arguing about which use cases we should put in an RFC,= would not be a good use of the WGs time and energy. Some discussion of im= portance is inevitable as we decide which pieces of the problem to solve we= ll, which pieces to solve awkwardly, and which pieces not to solve. Yours, Joel _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From kgray@juniper.net Wed Sep 4 11:37: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 EF07421F977A for ; Wed, 4 Sep 2013 11:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.974 X-Spam-Level: X-Spam-Status: No, score=-4.974 tagged_above=-999 required=5 tests=[AWL=1.025, 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 CckCXcfAfTlD for ; Wed, 4 Sep 2013 11:37:33 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id AA16011E81CD for ; Wed, 4 Sep 2013 11:37:29 -0700 (PDT) Received: from mail61-co9-R.bigfish.com (10.236.132.230) by CO9EHSOBE016.bigfish.com (10.236.130.79) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 18:37:29 +0000 Received: from mail61-co9 (localhost [127.0.0.1]) by mail61-co9-R.bigfish.com (Postfix) with ESMTP id EF262A01A7; Wed, 4 Sep 2013 18:37:28 +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: -75 X-BigFish: VPS-75(zzbb2dI98dI9371Ic89bh542I1432I15caKJzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h93fhe5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail61-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(55784002)(377454003)(479174003)(24454002)(189002)(199002)(51704005)(13464003)(56816003)(53806001)(74662001)(31966008)(51856001)(49866001)(74502001)(77096001)(76482001)(56776001)(54316002)(79102001)(54356001)(4396001)(47446002)(81542001)(76796001)(76786001)(36756003)(76176001)(47736001)(47976001)(63696002)(74876001)(50986001)(74706001)(77982001)(80022001)(65816001)(69226001)(80976001)(74366001)(83322001)(19580405001)(19580395003)(83506001)(83072001)(81342001)(81816001)(59766001)(46102001)(81686001)(1941001)(15975445006); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB241; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail61-co9 (localhost.localdomain [127.0.0.1]) by mail61-co9 (MessageSwitch) id 1378319846875878_875; Wed, 4 Sep 2013 18:37:26 +0000 (UTC) Received: from CO9EHSMHS007.bigfish.com (unknown [10.236.132.236]) by mail61-co9.bigfish.com (Postfix) with ESMTP id C6AE770004C; Wed, 4 Sep 2013 18:37:26 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS007.bigfish.com (10.236.130.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 18:37:24 +0000 Received: from BL2PR05MB241.namprd05.prod.outlook.com (10.242.198.139) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 4 Sep 2013 18:37:23 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB241.namprd05.prod.outlook.com (10.242.198.139) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 4 Sep 2013 18:37:22 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.100]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 18:37:22 +0000 From: Ken Gray To: Jerome Moisand , "christian.jacquenet@orange.com" , "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [nsc] NSC BoF Outcomes Thread-Index: AQHOqOMZHv0zVYXZE0SHEZHP0mGkNJm0jqkAgAAGpACAAAH1gIAAAJuAgAAFo4CAACDVAIAAqS8AgAAzlgCAAAYUgIAAFtUAgAAE+QCAAAITgIAAA/QA///js4A= Date: Wed, 4 Sep 2013 18:37:21 +0000 Message-ID: In-Reply-To: <22e3d4546f5140e8a7ac9ff20246c143@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.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 095972DF2F Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Mon, 09 Sep 2013 08:19:58 -0700 Cc: "nsc@ietf.org" , Thomas Nadeau , Linda Dunbar , "adrian@olddog.co.uk" , Thomas Narten , "Stewart Bryant \(stbryant\)" Subject: Re: [nsc] NSC BoF Outcomes 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, 04 Sep 2013 18:37:38 -0000 VGhpcyBnZXRzIGJhY2sgYXJvdW5kIHRvIFJFUSMzMCBpbiB0aGUgcmVxdWlyZW1lbnRzIGFscmVh ZHkgcHVibGlzaGVkLg0KDQpPbiA5LzQvMTMgMTI6MTggUE0sICJKZXJvbWUgTW9pc2FuZCIgPGpt b2lzYW5kQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPkkgd291bGQgdGVuZCB0byBhZ3JlZSB3aXRo IENocmlzdGlhbiwgcmVxdWlyZW1lbnRzIHNob3VsZCBiZSBhYm91dCB0aGUNCj5vdmVyYWxsIHBy b2JsZW0gdG8gc29sdmUuIFBsdXMgYSBjb250cm9sIHBsYW5lIHRlbmRzIHRvIGNvbnRyb2wuLi4g dGhlDQo+ZGF0YSBwbGFuZSEgU28gYmV0dGVyIHdvcmsgb24gcmVxdWlyZW1lbnRzIHdoaWNoIHdv dWxkIGJlIGNvbnNpc3RlbnQNCj5lbm91Z2ggdG8gYWNrbm93bGVkZ2Ugc3VjaCByZWxhdGlvbnNo aXAuDQo+DQo+Tm93LCBJIGFsc28gYWdyZWUgd2l0aCBSb24gdGhhdCBhIGNvbnRyb2wgcGxhbmUg bWF5IG5vdCBiZSByZXF1aXJlZCBpbg0KPmFsbCBjYXNlcy4gVGhpcyBzaG91bGQgcHJvYmFibHkg YmUgYSByZXF1aXJlbWVudCwgYWN0dWFsbHksIHRvIG5vdA0KPm1hbmRhdGUgYSBjb250cm9sIHBs YW5lIGluIGFsbCBjYXNlcyENCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206 IGNocmlzdGlhbi5qYWNxdWVuZXRAb3JhbmdlLmNvbQ0KPlttYWlsdG86Y2hyaXN0aWFuLmphY3F1 ZW5ldEBvcmFuZ2UuY29tXQ0KPlNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDA0LCAyMDEzIDEy OjA0IFBNDQo+VG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBSb24gUGFya2VyOyBKZXJvbWUg TW9pc2FuZA0KPkNjOiBuc2NAaWV0Zi5vcmc7IFRob21hcyBOYWRlYXU7IExpbmRhIER1bmJhcjsg YWRyaWFuQG9sZGRvZy5jby51azsNCj5UaG9tYXMgTmFydGVuOyBTdGV3YXJ0IEJyeWFudCAoc3Ri cnlhbnQpDQo+U3ViamVjdDogUkU6IFtuc2NdIE5TQyBCb0YgT3V0Y29tZXMNCj4NCj5IaSosDQo+ DQo+SSBzdXBwb3J0IHRoZSBwdWJsaWNhdGlvbiBvZiBhIHNpbmdsZSByZXF1aXJlbWVudHMgZG9j dW1lbnQgKGZvciB0aGUgc2FrZQ0KPm9mIGNvbnNpc3RlbmN5KSwgYW5kIHdoaWNoIHdvdWxkIGlu Y2x1ZGUgYm90aCBjb250cm9sIGFuZCBkYXRhIHBsYW5lDQo+Y29uc2lkZXJhdGlvbnMgYW1vbmcg b3RoZXIgdG9waWNzLg0KPg0KPkNoZWVycywNCj4NCj5DaHJpc3RpYW4uDQo+DQo+LS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+RGUgOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5z Yy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEppbQ0KPkd1aWNoYXJkIChqZ3VpY2hh cikgRW52b3nDqSA6IG1lcmNyZWRpIDQgc2VwdGVtYnJlIDIwMTMgMTc6NTcgw4AgOiBSb24NCj5Q YXJrZXI7IEplcm9tZSBNb2lzYW5kIENjIDogbnNjQGlldGYub3JnOyBUaG9tYXMgTmFkZWF1OyBM aW5kYSBEdW5iYXI7DQo+YWRyaWFuQG9sZGRvZy5jby51azsgVGhvbWFzIE5hcnRlbjsgU3Rld2Fy dCBCcnlhbnQgKHN0YnJ5YW50KSBPYmpldCA6IFJlOg0KPltuc2NdIE5TQyBCb0YgT3V0Y29tZXMN Cj4NCj5JcyB0aGUgc3VnZ2VzdGlvbiB0aGVyZWZvcmUgdGhhdCBzZXBhcmF0ZSBkYXRhIGFuZCBj b250cm9sIHBsYW5lDQo+cmVxdWlyZW1lbnRzIEktRCdzIHNob3VsZCBiZSBjcmVhdGVkIHJhdGhl ciB0aGFuIGFuIG92ZXJhbGwgcmVxdWlyZW1lbnRzDQo+ZG9jdW1lbnQgY292ZXJpbmcgYm90aD8N Cj4NCj5PbiA5LzQvMTMgMTE6MzkgQU0sICJSb24gUGFya2VyIiA8Um9uX1BhcmtlckBhZmZpcm1l ZG5ldHdvcmtzLmNvbT4gd3JvdGU6DQo+DQo+PkppbSwNCj4+DQo+PkkgYWdyZWUgdGhhdCB0aGUg Y2hhcnRlciBzaG91bGQgbm90IGJlIHRvbyBzcGVjaWZpYyBvbiB0aGUgZGVzaWduIG9mDQo+PnRo ZSBjb250cm9sIHBsYW5lLCBidXQgcmF0aGVyIHRvIHJlY29nbml6ZSB0aGF0IG9uZSBjb3VsZCBi ZQ0KPj5hZHZhbnRhZ2VvdXMgKGFsdGhvdWdoIG5vdCBuZWNlc3NhcmlseSByZXF1aXJlZCkgZm9y IHRoZSBvdmVyYWxsIHNlcnZpY2UNCj4+Y2hhaW5pbmcNCj4+c29sdXRpb24uICAgIEEgY29udHJv bCBwbGFuZSByZXF1aXJlbWVudHMgYW5kL29yIHVzZSBjYXNlcyBkb2N1bWVudA0KPj5zaG91bGQg cHJlY2VkZSBhbnkgY29udHJvbCBwbGFuZSBwcm90b2NvbCBkZXNpZ24gb3Igc2VsZWN0aW9uLg0K Pj4NCj4+ICAgUm9uDQo+Pg0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJv bTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+ PlNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDA0LCAyMDEzIDEwOjE3IEFNDQo+PlRvOiBKZXJv bWUgTW9pc2FuZDsgUm9uIFBhcmtlcg0KPj5DYzogbnNjQGlldGYub3JnOyBUaG9tYXMgTmFkZWF1 OyBUaG9tYXMgTmFydGVuOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOw0KPj5MaW5kYSBEdW5iYXI7IFN0 ZXdhcnQgQnJ5YW50IChzdGJyeWFudCkNCj4+U3ViamVjdDogUmU6IFtuc2NdIE5TQyBCb0YgT3V0 Y29tZXMNCj4+DQo+PkhpIEplcm9tZSwNCj4+DQo+Pk15IGJhZCAuLiBSZXNwb25kaW5nIHRvIHlv dXIgUFMgOykgxaAgUmlnaHQgbm93IHRoZSBjaGFydGVyIHN1Z2dlc3RzDQo+PnRoYXQgdGhlIFdH IGJlIHJlc3BvbnNpYmxlIGZvciBkZWZpbmluZyB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBjb250 cm9sDQo+PnBsYW5lIHdpdGggcmVzcGVjdCB0byBzZXJ2aWNlIGNoYWluaW5nLiBUaGUgcHJvYmxl bSBoZXJlIGlzIG9mIGNvdXJzZQ0KPj50aGF0IHRoZXJlIGFyZSBtdWx0aXBsZSBjb250cm9sIHBs YW5lcy4gSW4gbXkgbWluZCBpdCBtYWtlcyBsaXR0bGUNCj4+c2Vuc2UgdG8gdHJ5IGFuZCB0YWNr bGUgdGhlbSBhbGwgYnV0IHJhdGhlciBkZWZpbmUgd2hhdCBpcyBuZWNlc3NhcnkNCj4+Zm9yIGEg Y29udHJvbCBwbGFuZSB0byBpbXBsZW1lbnQgdG8gc3VjY2Vzc2Z1bGx5IGVuYWJsZSBzZXJ2aWNl IGNoYWlucw0KPj5hbmQgdGhlbiBsaWFpc2Ugd2l0aCBvdGhlciBXRydzIG9uIHRoZSBkZXRhaWxz Lg0KPj4NCj4+U29tZSBmdXJ0aGVyIGNvbW1lbnRzIGlubGluZS4NCj4+DQo+Pk9uIDkvNC8xMyA5 OjU1IEFNLCAiSmVyb21lIE1vaXNhbmQiIDxqbW9pc2FuZEBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+ Pg0KPj4+SXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgZW50aXJlIHBvaW50IG9mIHNlcnZpY2UgY2hh aW5pbmcgaXMgaW5kZWVkIHRvDQo+Pj5jaGFpbiB0b2dldGhlciBoZXRlcm9nZW5lb3VzIHNlcnZp Y2UtZW5hYmxpbmcgZWxlbWVudHMsIGFuZCBtYWtlIHRoZQ0KPj4+YmVzdCBvdXQgb2Ygc3VjaCBj b21iby4NCj4+DQo+PkppbT4gZXhhY3RseS4gVGhlIHBvaW50IGJlaW5nIHNlcGFyYXRlIHNlcnZp Y2UgZnVuY3Rpb25zIGludG8gYQ0KPj5KaW0+IHJlc291cmNlDQo+PnBvb2wgdGhhdCBjYW4gYmUg dXRpbGl6ZWQgYW5kIG5vdCBjb25zdHJhaW5lZCBiYXNlZCBvbiB0b3BvbG9neS4NCj4+DQo+Pj4g DQo+Pj4NCj4+PlNlcnZpY2UgRWRnZSByb3V0ZXJzIChpbmNsdWRpbmcgQml6LVBFcywgQk5HcyBh bmQgTW9iaWxlIEdXcykgZW5hYmxlDQo+Pj5MMyBzZXJ2aWNlcywgb24gYSBwZXIgc3Vic2NyaWJl ciBiYXNpcy4gRmlyZXdhbGxzIGNhbiBhY3QgZWl0aGVyIGF0DQo+Pj5MMy9MNCBvcg0KPj4+TDQv TDcgKGUuZy4gYWRkaW5nIHNvbWUgSW50cnVzaW9uIERldGVjdGlvbiB0byB0aGUgbWl4KS4gRFBJ IG9yIEhUVFANCj4+PlByb3hpZXMvRmlsdGVycyBlbmdpbmVzIGFjdCBhdCBMNy4gU2Vzc2lvbiBC b3JkZXIgQ29udHJvbGxlcnMgYWN0IGF0DQo+Pj5MNywgYWx0aG91Z2ggdGhleSBkbyBzb21lIEwz L0w0IHByb2Nlc3NpbmcgdG9vIChOQVQpLiBBbGwgdGhvc2UNCj4+PnZhcmlvdXMgZWxlbWVudHMg aGF2ZSB0aGVpciBvd24gc3RyZW5ndGhzIGluIHRlcm1zIG9mIHRyYWZmaWMNCj4+PmNsYXNzaWZp Y2F0aW9uIGFuZCBpbiB0ZXJtcyBvZiBwb2xpY3kgZW5mb3JjZW1lbnQuIFdoaWNoIGNhbiBjb21i aW5lZA0KPj4+aW4gc21hcnQgd2F5cyAoZS5nLg0KPj4+dXNlIERQSSB0byBpZGVudGlmeS9jbGFz c2lmeSBhbiBhcHBsaWNhdGlvbiBmbG93LCB1c2UgYW4gZWRnZSByb3V0ZXINCj4+PnRvIHBlcmZv cm0gZmFuY3kgcXVldWluZyBiYXNlZCBvbiBzdWNoIERQSSBjbGFzc2lmaWNhdGlvbiBhbW9uZyBv dGhlcg0KPj4+dHJhZmZpYyBmbG93cykuDQo+Pg0KPj5KaW0+IHllcC4gDQo+Pg0KPj4+IA0KPj4+ DQo+Pj5UaGUgYmVhdXR5IG9mIHNlcnZpY2UgY2hhaW5pbmcgaXMgdG8gY29tYmluZSBhbGwgdGhv c2UgZWxlbWVudHMgdG8NCj4+Pm1ha2Ugc29tZXRoaW5nIHRydWx5IHVzZWZ1bCAoZS5nLiBwcm92 aWRlIGEgbW9yZSBjb21wbGV4IFNlcnZpY2UgLXdpdGgNCj4+PmEgY2FwaXRhbCAnUyctIHRvIHNl cnZpY2UgcHJvdmlkZXIgdXNlcnMgb3IgZW50ZXJwcmlzZSB1c2VycykuIEFsbCB0aGUNCj4+PnVz ZSBjYXNlcyBJJ3ZlIGhlYXJkIHNvIGZhciBmcm9tIHZhcmlvdXMgcGFydGllcyBkbyBtaXggZWRn ZSByb3V0ZXJzLA0KPj4+c2VjdXJpdHkgYW5kIGFwcGxpY2F0aW9uLW9yaWVudGVkIGVsZW1lbnRz Lg0KPj4+DQo+Pj5Tby4uLiBJIHdvdWxkIG5vdCBiZSBzdXBwb3J0aXZlIHRvIHRyeWluZyB0byBz ZXBhcmF0ZSBhIGZvcm0gb2YgTDIvTDMNCj4+PmNoYWluaW5nIGZyb20gYSBmb3JtIG9mIEw0L0w3 IGNoYWluaW5nLiBPbiB0aGUgY29udHJhcnkhIDstKQ0KPj4+DQo+Pj5JIHdvdWxkIGFjdHVhbGx5 IGdvIGFzIGZhciBhcyBzdWdnZXN0aW5nIHRoYXQgd2Ugc2hvdWxkIG1ha2UgY2xlYXJlcg0KPj4+ aW4gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGhhdCB0aGlzIGlzIGEgc3Ryb25nIGdvYWwsIHRvIGRl YWwgd2l0aCBzdWNoDQo+Pj5oZXRlcm9nZW5lb3VzIGNvbWJvcy4NCj4+DQo+PkppbT4gYW55IHRl eHQgYW5kIHN1Z2dlc3Rpb24gb2Ygd2hlcmUgdG8gaW5zZXJ0IGludG8gdGhlIGNoYXJ0ZXI/DQo+ Pg0KPj4+DQo+Pj5KdXN0IG15IDIgY2VudHMsDQo+Pj5KZXJvbWUNCj4+Pg0KPj4+PT09PQ0KPj4+ VG90YWxseSB1bnJlbGF0ZWQgUFMgZm9yIEppbTogeW91IGRpZG4ndCBhbnN3ZXIgbXkgcXVlc3Rp b24gYWJvdXQgdGhlDQo+Pj5jb250cm9sIHBsYW5lIGFzcGVjdHMsIHRoaXMgbWF5IGhhdmUgc2xp cHBlZCB0aHJvdWdoIHRoZSBjcmFja3MhIDstKQ0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+RnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hh ckBjaXNjby5jb21dDQo+Pj5TZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMyA2OjUx IEFNDQo+Pj5UbzogUm9uIFBhcmtlcg0KPj4+Q2M6IG5zY0BpZXRmLm9yZzsgVGhvbWFzIE5hZGVh dTsgVGhvbWFzIE5hcnRlbjsgYWRyaWFuQG9sZGRvZy5jby51azsNCj4+PkxpbmRhIER1bmJhcjsg U3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KQ0KPj4+U3ViamVjdDogUmU6IFtuc2NdIE5TQyBCb0Yg T3V0Y29tZXMNCj4+Pg0KPj4+VGhlIHNhbWUgYXJndW1lbnQgY291bGQgYmUgYXBwbGllZCBmb3Ig ZmlyZXdhbGxzIGFzIHdpdGhvdXQgdGhlbQ0KPj4+cGFja2V0cyB3b3VsZCBnZXQgcm91dGVkIGlu c3RlYWQgb2YgcGVyaGFwcyBkcm9wcGVkLg0KPj4+DQo+Pj5TZW50IGZyb20gbXkgaVBob25lDQo+ Pj4NCj4+Pk9uIFNlcCAzLCAyMDEzLCBhdCA4OjQ1IFBNLCAiUm9uIFBhcmtlciINCj4+PjxSb25f UGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPiB3cm90ZToNCj4+Pg0KPj4+PiBIaSwgTGluZGEu DQo+Pj4+IA0KPj4+PiBXaXRoIHJlc3BlY3QgdG86DQo+Pj4+IA0KPj4+PiAgICAtIExheWVyIDQg dG8gTGF5ZXIgNyBzZXJ2aWNlIGZ1bmN0aW9ucyAob3Igc2VydmljZSBub2RlcykgYXJlIHRvDQo+ Pj4+YXBwbHkgYWN0aW9ucyB0byBkYXRhIHBhY2tldHMgdHJhdmVyc2luZyB0aHJvdWdoLiBUaGV5 IGRvbid0IGltcGFjdA0KPj4+Pm92ZXJhbGwgbmV0d29yayB0b3BvbG9naWVzL3JvdXRlcy9yZXN0 b3JhdGlvbnMuDQo+Pj4+IA0KPj4+PiBMYXllciA0LTcgc2VydmljZXMgY2FuLCBpbmRlZWQsIGlt cGFjdCByb3V0aW5nIGRlY2lzaW9ucy4gIEZvcg0KPj4+PmV4YW1wbGUsIGlmIHRoZSBzZXJ2aWNl IGlzIERQSSBhbmFseXNpcywgdGhlbiBhIGRldGVjdGVkIHByb3RvY29sIG1heQ0KPj4+PmNhdXNl IHRoZSBzdWJzZXF1ZW50IHBhY2tldHMgdG8gYmUgcG9saWN5IHJvdXRlZCBvbiBhIHBhdGggZGlm ZmVyZW50DQo+Pj4+dGhhbiB0aGUgU1BGIHBhdGguDQo+Pj4+IA0KPj4+PiAgIFJvbg0KPj4+PiAN Cj4+Pj4gDQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IG5zYy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0K Pj4+PiBPZiBMaW5kYSBEdW5iYXINCj4+Pj4gU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDAzLCAy MDEzIDY6NDggUE0NCj4+Pj4gVG86IFRob21hcyBOYWRlYXUNCj4+Pj4gQ2M6IG5zY0BpZXRmLm9y ZzsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IFRob21hcyBOYXJ0ZW47DQo+Pj4+IGFkcmlhbkBv bGRkb2cuY28udWs7IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFudCkNCj4+Pj4gU3ViamVjdDogUmU6 IFtuc2NdIE5TQyBCb0YgT3V0Y29tZXMNCj4+Pj4gDQo+Pj4+IEhlcmUgYXJlIHNvbWUgb2YgdGhl IHJlYXNvbnMgdGhhdCBjaGFpbmluZyBvZiBMYXllciAyIGFuZCAzIHNlcnZpY2UNCj4+Pj5mdW5j dGlvbnMgYXJlIGRpZmZlcmVudCBmcm9tIGNoYWluaW5nIG9mIExheWVyIDQgdG8gNyBzZXJ2aWNl DQo+Pj4+ZnVuY3Rpb25zIChJIHdpbGwgYWRkIG1vcmUgbGF0ZXIpOg0KPj4+PiANCj4+Pj4gDQo+ Pj4+IC0gTGF5ZXIgNCB0byBMYXllciA3IHNlcnZpY2UgZnVuY3Rpb25zIChvciBzZXJ2aWNlIG5v ZGVzKSBhcmUgdG8NCj4+Pj5hcHBseSBhY3Rpb25zIHRvIGRhdGEgcGFja2V0cyB0cmF2ZXJzaW5n IHRocm91Z2guIFRoZXkgZG9uJ3QgaW1wYWN0DQo+Pj4+b3ZlcmFsbCBuZXR3b3JrIHRvcG9sb2dp ZXMvcm91dGVzL3Jlc3RvcmF0aW9ucy4NCj4+Pj4gDQo+Pj4+IC0gTGF5ZXIgNC03IHNlcnZpY2Ug ZnVuY3Rpb25zIGRyb3AsIHBhc3MsIGNvbnN1bWUsIHJlLWluaXRpYXRlDQo+Pj4+cGFja2V0cywg ZXRjLiBUaGV5IGRvbid0IGNoYW5nZSBuZXR3b3JrIHRvcG9sb2dpZXMsIGFuZCB0aGV5IGRvbid0 DQo+Pj4+aW1wYWN0IG5ldHdvcmsgcmVzdG9yYXRpb24gc2NoZW1lIChlLmcuIGZhc3QgcmUtcm91 dGUpLiAgV2hlbiB5b3UNCj4+Pj5tb3ZlIGEgTGF5ZXIgNCBzZXJ2aWNlIG1vZHVsZSBmcm9tIExv Y2F0aW9uIEEgdG8gQiwgdGhlIExheWVyIDIvMw0KPj4+PnRvcG9sb2d5IGlzIG5vdCBjaGFuZ2Vk LCByb3V0ZXMvcmVzdG9yYXRpb24gYXJlIG5vdCBjaGFuZ2VkLg0KPj4+PiANCj4+Pj4gLSBXaGVu IGNoYWluaW5nIExheWVyIDQgdG8gTGF5ZXIgNyBzZXJ2aWNlIGZ1bmN0aW9ucyB0b2dldGhlciwg bGlrZQ0KPj4+PlMxLT5TMi0+UzMtPlM0LCB0aGV5IGFyZSBvdmVybGF5aW5nIG92ZXIgdGhlIHVu ZGVybGF5IG5ldHdvcmsuDQo+Pj4+IA0KPj4+PiAtICBMYXllciAyIGFuZCBsYXllciAzIG5vZGVz IGhhdmUgY29udHJvbCBwbGFuZSAoZS5nLiBJR1AvQkdQKSB0bw0KPj4+PmR5bmFtaWNhbGx5IGRp c2NvdmVyIHRvcG9sb2d5OyBmb3J3YXJkaW5nIHBhdGhzOyBwcm90ZWN0aW9uIHBhdGhzOw0KPj4+ PnJlc3RvcmF0aW9uIHBhdGhzLCBldGMuIFRvZGF5LCBhbGwgcm91dGVycyBhcmUgY29ubmVjdGVk IHRvZ2V0aGVyIGJ5DQo+Pj4+bGlua3MuIFRoZWlyIHRvcG9sb2d5IGlzIG1vcmUgbGlrZSBhIG1l c2hlZCBncmFwaCB0aGFuIGNoYWluLiBTbyB3aGVuDQo+Pj4+eW91IGNoYWluIFJvdXRlci0xPC0+ Um91dGVyLTI8LT5Sb3V0ZXItMywgYXJlIHlvdSB0YWxraW5nIGFib3V0DQo+Pj4+c291cmNlIHJv dXRpbmc/IFRoZXJlZm9yZSwgbmVlZCBhIGNsZWFyIGRlZmluaXRpb24gb24gd2hhdCBkb2VzIGl0 DQo+Pj4+cmVhbGx5IG1lYW4gYnkgY2hhaW5pbmcgTGF5ZXIgMi8zIHNlcnZpY2Ugbm9kZXMuDQo+ Pj4+IA0KPj4+PiBMaW5kYQ0KPj4+PiANCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4+PiBGcm9tOiBUaG9tYXMgTmFkZWF1IFttYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5j b21dDQo+Pj4+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDMsIDIwMTMgNToyOCBQTQ0KPj4+ Pj4gVG86IExpbmRhIER1bmJhcg0KPj4+Pj4gQ2M6IG5zY0BpZXRmLm9yZzsgSmltIEd1aWNoYXJk IChqZ3VpY2hhcik7IFN0ZXdhcnQgQnJ5YW50DQo+Pj4+PiAoc3RicnlhbnQpOyBUaG9tYXMgTmFy dGVuOyBhZHJpYW5Ab2xkZG9nLmNvLnVrDQo+Pj4+PiBTdWJqZWN0OiBSZTogW25zY10gTlNDIEJv RiBPdXRjb21lcw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE9uIFNlcCAzLCAyMDEzOjY6MjUgUE0s IGF0IDY6MjUgUE0sIExpbmRhIER1bmJhcg0KPj4+Pj4gPGxpbmRhLmR1bmJhckBodWF3ZWkuY29t PiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4+IFRob21hcywNCj4+Pj4+PiANCj4+Pj4+PiBBcmUgeW91 IHNheWluZyB0aGF0IHRoZSBOU0Mgc2NvcGUgaW5jbHVkZXMgY2hhaW5pbmcgTGF5ZXIgMiwgTGF5 ZXINCj4+Pj4+PiAzDQo+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucywgTGF5ZXIgNCB0byBMYXllciA3 IHNlcnZpY2UgZnVuY3Rpb25zLCBhbmQNCj4+Pj4+IHZhcmlvdXMgY29tYmluYXRpb24gb2YgdGhl bT8NCj4+Pj4+IA0KPj4+Pj4gICAgSSBkb24ndCBkZWZpbmUgdGhlIHNjb3BlOyB0aGF0cyB1cCB0 byB0aGUgQURzLg0KPj4+Pj4gDQo+Pj4+PiAgICBDb3VsZCB5b3UgcGxlYXNlIGFuc3dlciB0aGUg cXVlc3Rpb24gYmVsb3c/DQo+Pj4+PiANCj4+Pj4+ICAgIC0tVG9tDQo+Pj4+PiANCj4+Pj4+PiAN Cj4+Pj4+PiBMaW5kYQ0KPj4+Pj4+IA0KPj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+Pj4+PiBGcm9tOiBUaG9tYXMgTmFkZWF1IFttYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lv bi5jb21dDQo+Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwMywgMjAxMyA1OjE5IFBN DQo+Pj4+Pj4+IFRvOiBMaW5kYSBEdW5iYXINCj4+Pj4+Pj4gQ2M6IEppbSBHdWljaGFyZCAoamd1 aWNoYXIpOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBuc2NAaWV0Zi5vcmc7DQo+Pj4+Pj4+IFRob21h cyBOYXJ0ZW47IFN0ZXdhcnQgQnJ5YW50IChzdGJyeWFudCkNCj4+Pj4+Pj4gU3ViamVjdDogUmU6 IFtuc2NdIE5TQyBCb0YgT3V0Y29tZXMNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBPbiBT ZXAgMywgMjAxMzo1OjU0IFBNLCBhdCA1OjU0IFBNLCBMaW5kYSBEdW5iYXINCj4+Pj4+Pj4gPGxp bmRhLmR1bmJhckBodWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBNeSBjb21t ZW50cyBhcmUgaW5zZXJ0ZWQgYmVsb3cgbWFya2VkIGJ5IFtMaW5kYV06DQo+Pj4+Pj4+PiANCj4+ Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+Pj4gSG93ZXZlciwgaXQgd2FzIGxlc3MgY2xlYXIgdG8gbWUgdGhhdCB0aGVy ZSBpcyBhZ3JlZW1lbnQgYWJvdXQNCj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+IGxheWVyDQo+Pj4+Pj4+ Pj4+IGluDQo+Pj4+Pj4+Pj4+IHdoaWNoIHNlcnZpY2UgY2hhaW5pbmcgaGFzIHRvIGJlIHNvbHZl ZC4gSSBmZWx0IHRoYXQgc29tZQ0KPj4+Pj4+Pj4+PiBwZW9wbGUgd2VyZSB0YWxraW5nIGFib3V0 IHNlcnZpY2UgY2hhaW5pbmcgaW4gdGhlIGFwcGxpY2F0aW9uDQo+Pj4+Pj4+Pj4+IGxheWVyLA0K Pj4+Pj4gc29tZQ0KPj4+Pj4+Pj4+PiBhYm91dCBzZXJ2aWNlIGNoYWluaW5nIGJhc2VkIG9uIGZs b3dzLCBhbmQgc29tZSBhYm91dA0KPj4+Pj4+Pj4+PiBwZXItcGFja2V0IHNlcnZpY2VzLiBUaGUg c29sdXRpb25zIGFyZSwNCj4+Pj4+Pj4+PiBJDQo+Pj4+Pj4+Pj4+IHRoaW5rLA0KPj4+Pj4+Pj4+ PiBsaWtlbHkgdG8gYmUgdmVyeSBkaWZmZXJlbnQgZm9yIHRoZSBkaWZmZXJlbnQgcHJvYmxlbXMs IGFuZCBpdA0KPj4+Pj4+PiB3b3VsZA0KPj4+Pj4+Pj4+IGJlDQo+Pj4+Pj4+Pj4+IHdyb25nIHRv DQo+Pj4+Pj4+Pj4+IHRyeSB0byBidW5jaCB0aGVtIGFsbCB0b2dldGhlci4NCj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+PiBKaW0+IGFsdGhvdWdoIHRoZXJlIHdhcyBjZXJ0YWlubHkgaW5pdGlhbCBjb25m dXNpb24gSSBiZWxpZXZlDQo+Pj4+Pj4+Pj4gSmltPiB0aGlzDQo+Pj4+Pj4+IGlzDQo+Pj4+Pj4+ Pj4gYmVjb21pbmcgbGVzcyBhbmQgbGVzcyBzbyBhcyB3ZSBzb2NpYWxpemUgdGhlIGJhc2ljIGlk ZWEgb2YNCj4+Pj4+IHNlcnZpY2UNCj4+Pj4+Pj4+PiBjaGFpbmluZzsgaW5kZWVkLCBhcyB3ZSBt b3ZlIGZvcndhcmQgd2Ugd2lsbCByZWZsZWN0IGEgbW9yZQ0KPj4+Pj4+Pj4+IGNvbW1vbiB1bmRl cnN0YW5kaW5nIHdpdGhpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQuDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IEl0IGlzIHN0aWxsIG5vdCBjbGVhciB3aGljaCBsYXllciBzZXJ2aWNlIGZ1bmN0aW9ucyBh cmUgY2hhaW5lZA0KPj4+Pj4+PiB0b2dldGhlci4gVGhlIGRyYWZ0LXF1aW5uLW5zYy1wcm9ibGVt LXN0YXRlbWVudC0wMyBkaXNjdXNzZWQNCj4+Pj4+IGNoYWluaW5nDQo+Pj4+Pj4+IG9mIHNlcnZp Y2UgZnVuY3Rpb25zIHRoYXQgY2FuIGJlIGEgbmV0d29yayBvciBhcHBsaWNhdGlvbiBiYXNlZA0K Pj4+Pj4+PiBwYWNrZXQgdHJlYXRtZW50LC4uLiwgdG8gZW5hYmxlIGEgc2VydmljZSBvZmZlcmVk IGJ5IGEgbmV0d29yaw0KPj4+Pj4gb3BlcmF0b3JzLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gICAgV2h5 IGRvIHlvdSB0aGluayB0aGF0IG1hdHRlcnM/DQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gVG9kYXksIHRo ZXJlIGFyZSBtYW55IHNlcnZpY2VzIG9mZmVyZWQgYnkgb3BlcmF0b3JzLCBlLmcuIEwyVlBOLA0K Pj4+Pj4+Pj4gTDNWUE4sIFAyUCBwYXRocywgZXRjLiBTbyB5b3UgY2FuIGludGVycHJldCBOU0Mg YXMgY2hhaW5pbmcNCj4+Pj4+Pj4+IEwyL0wzDQo+Pj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zIChs aWtlIHByb3h5IGZvcndhcmRpbmcsIG9yIGZyYWdtZW50YXRpb24sDQo+Pj4+Pj4+IGV0Yy4pOyBZ b3UgY2FuIGFsc28gaW50ZXJwcmV0IE5TQyBhcyBjaGFpbmluZyBMNCAgKGFuZCBhYm92ZSkNCj4+ Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnM7IG9yIGNoYWluaW5nIG9mIG1peGVkIEw0LUw3IHNlcnZp Y2UgZnVuY3Rpb25zDQo+Pj4+Pj4+IChpLmUuIHdpdGggc29tZSBzZXJ2aWNlIG5vZGVzIGNvbnN1 bWluZyBwYWNrZXRzIGFuZCByZWluaXRpYXRlIG5ldw0KPj4+Pj4+PnBhY2tldHMpLg0KPj4+Pj4+ PiANCj4+Pj4+Pj4gICAgWW91IGNhbiwgYW5kIHBlb3BsZSBhY3R1YWxseSBkbyBpbXBsZW1lbnQg dGhpcyB0b2RheS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBJcyBOU0MgaW5jbHVkaW5nIGFsbCBjaGFp bmluZyBvZiBhbGwgdGhvc2Ugc2VydmljZXM/DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IExheWVyIDIv MyBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIG1pZ2h0IHJlcXVpcmUgZGlmZmVyZW50DQo+Pj4+ Pj4+PiBzY2hlbWVzDQo+Pj4+Pj4+IHRoYW4gTGF5ZXIgNC03IHNlcnZpY2UgY2hhaW5pbmcuIFRo ZXJlZm9yZSwgaXQgaXMgbW9yZSBlZmZlY3RpdmUNCj4+Pj4+Pj4gdG8gZGVmaW5lIHRoZW0gc2Vw YXJhdGVseSB0byBtYWtlIHRoZSBkaXNjdXNzaW9uIG1vcmUgZm9jdXNlZC4NCj4+Pj4+Pj4gDQo+ Pj4+Pj4+ICAgIEkgZG8gbm90IHRoaW5rIHNvLiBJJ2QgcHJlZmVyIHRvIG5vdCBtYWtlIHRoaXMg b25seSBhcw0KPj4+Pj4gY29tcGxpY2F0ZWQNCj4+Pj4+Pj4gYXMgaXQgbmVlZHMgdG8gYmUsIGFu ZCBubyBtb3JlLiBUaGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIG9mDQo+Pj4+Pj4+IExheWVyDQo+ Pj4+Pj4+IDIgYW5kIDMgY2hhaW5pbmcgdGhhdCBhcmUgYWxsIGRvbmUgd2l0aCB0aGUgc2FtZQ0K Pj4+Pj4+PiBlbmNhcC9wcm92aXNpb25pbmcgc3lzdGVtcy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICAg IC0tVG9tDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gTGluZGEgRHVu YmFyDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QN Cj4+Pj4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25zYw0KPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+ IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uc2MNCj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBuc2NAaWV0 Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0K Pj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pg0KPj4+DQo+Pg0KPg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bnNjIG1haWxp bmcgbGlzdA0KPm5zY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbnNjDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPmNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLA0K PmV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyDQo+ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzDQo+cGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcw0KPmQnYWx0ZXJhdGlvbiwg T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZQ0K PmFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+DQo+VGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQN Cj5pbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsDQo+dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u Lg0KPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQNCj5kZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuDQo+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig bWVzc2FnZXMgdGhhdCBoYXZlDQo+YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu DQo+VGhhbmsgeW91Lg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+bnNjIG1haWxpbmcgbGlzdA0KPm5zY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQoNCg== From Kevin.Glavin@riverbed.com Mon Sep 9 13:54: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 E966521E816E for ; Mon, 9 Sep 2013 13:54:09 -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 mpmuX2qEYVft for ; Mon, 9 Sep 2013 13:54:04 -0700 (PDT) Received: from smtp1.riverbed.com (smtp.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id A83C011E813A for ; Mon, 9 Sep 2013 13:54:04 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P3.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 09 Sep 2013 13:53:27 -0700 Received: from SFO1EXC-MBXP06.nbttech.com ([fe80::14e0:71aa:8def:2df5]) by 365EXCH-HUB-P3.nbttech.com ([::1]) with mapi id 14.02.0328.009; Mon, 9 Sep 2013 13:53:27 -0700 From: Kevin Glavin To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] Back to the charter ... Thread-Index: AQHOqyeZwMPgp+Js6UOHmDI/e3mhO5m95u+A Date: Mon, 9 Sep 2013 20:53:26 +0000 Message-ID: <9EA32E60D7600C43B6FE22876DF564C81D65765F@SFO1EXC-MBXP06.nbttech.com> In-Reply-To: <68B171751455884590F8E38E96416F363F678E4B@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.16.205.251] Content-Type: multipart/alternative; boundary="_000_9EA32E60D7600C43B6FE22876DF564C81D65765FSFO1EXCMBXP06nb_" MIME-Version: 1.0 Subject: Re: [nsc] Back to the 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, 09 Sep 2013 20:54:10 -0000 --_000_9EA32E60D7600C43B6FE22876DF564C81D65765FSFO1EXCMBXP06nb_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jim, With regards to the 'meta data' that may be shunted along the service chain= , is there any proposal to work on some minimum level of standardization of= this data with the scope of this charter? I assume that as a chain could/would be populated with service logic from m= ultiple vendors then a base set of capabilities within the meta data would = make initial adaption easier? If so is this part of (3) below, or is it something else that may need to b= e added to the target deliverables? The flip side of this is that this meta data may be tied to specific use ca= ses and as such would be handled in that sphere and considered outside the = scope of the current work deliverables. Kevin From: "Jim Guichard (jguichar)" > Date: Friday, September 6, 2013 10:36 AM To: "nsc@ietf.org" > Subject: [nsc] Back to the charter ... Folks, Here is the current version of the charter. Please be encouraged to review = further and add comments. I would especially welcome those subscribers on t= he list that have yet to comment =96 we have at current count 299 subscribe= rs so I know you are out there ;-) : Proposed NSC WG Charter =85.. 3) Service Function Chaining Data & Control Plane: A data plane document wi= ll describe on the wire data plane encapsulation in support of (2). A singl= e service-level encapsulation will be selected in order to enable interoper= ability of data plane components, which can in turn be carried in various t= ransport encapsulations (e.g., IP, MPLS, or other overlays). Supporting con= trol plane protocol elements will be added as needed (as a separate documen= t). =85=85 --_000_9EA32E60D7600C43B6FE22876DF564C81D65765FSFO1EXCMBXP06nb_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9589FC3EA65F47418040949DF50A872C@riverbed.com> Content-Transfer-Encoding: quoted-printable
Jim, 

With regards to the 'meta data' that may be shunted along the service = chain, is there any proposal to work on some minimum level of standardizati= on of this data with the scope of this charter? 
I assume that as a chain could/would be populated with service logic f= rom multiple vendors then a base set of capabilities within the meta data w= ould make initial adaption easier?  

If so is this part of (3) below, or is it something else that may need= to be added to the target deliverables? 

The flip side of this is that this meta data may be tied to specific u= se cases and as such would be handled in that sphere and considered outside= the scope of the current work deliverables. 

Kevin




From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Friday, September 6, 2013 10:= 36 AM
To: "nsc@ietf.org" <nsc@ietf.= org>
Subject: [nsc] Back to the charter = ...

Folks,

Here is the current version of the charter. Please be encouraged to re= view further and add comments. I would especially welcome those subscribers= on the list that have yet to comment =96 we have at current count 299 subs= cribers so I know you are out there ;-) :

Proposed NSC WG Charter

=85..

3) Service Function Chaining Data & Control Plane: A data plane do= cument will describe on the wire data plane encapsulation in support of (2)= . A single service-level encapsulation will be selected in order to enable = interoperability of data plane components, which can in turn be carried in various transport encapsulations (e.g., IP= , MPLS, or other overlays). Supporting control plane protocol elements will= be added as needed (as a separate document).

=85=85
 --_000_9EA32E60D7600C43B6FE22876DF564C81D65765FSFO1EXCMBXP06nb_-- From xuxiaohu@huawei.com Mon Sep 9 20:09: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 DD77011E812F for ; Mon, 9 Sep 2013 20:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[AWL=0.902, 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 ee5L-almovvf for ; Mon, 9 Sep 2013 20:09:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D8C1F11E80EA for ; Mon, 9 Sep 2013 20:09:10 -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.5-GA FastPath queued) with ESMTP id AXD04675; Tue, 10 Sep 2013 03:09:09 +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.146.0; Tue, 10 Sep 2013 04:09:02 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 04:09:08 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0146.000; Tue, 10 Sep 2013 11:09:01 +0800 From: Xuxiaohu To: "Surendra Kumar (smkumar)" , Ron Parker , "Jim Guichard (jguichar)" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] NSC Working Group Charter Proposal Thread-Index: AQHOqL7ArXOZ2m/vBEG19boxgCQmQ5m3HTiAgAAaTGD//6LlAIAADROAgAABLQCAABHdAIAAAysAgAFwEvA= Date: Tue, 10 Sep 2013 03:09:00 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820CDA5@NKGEML512-MBS.china.huawei.com> References: <8E86B6E7C6FB9F40A00B0E269045A7C9210F2222@xmb-aln-x09.cisco.com> In-Reply-To: <8E86B6E7C6FB9F40A00B0E269045A7C9210F2222@xmb-aln-x09.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 10 Sep 2013 03:09:28 -0000 SWYgVlhMQU4gaGVhZGVyIGlzIHVzZWQgYXMgYSB0cmFuc3BvcnQgaGVhZGVyLCBkb2VzIHRoYXQg bWVhbiB0aGUgZXhpc3RpbmcgVlhMQU4gaGVhZGVyIHNob3VsZCBiZSBtb2RpZmllZCBzbyBhcyB0 byBoYXZlIGEgcHJvdG9jb2wgdHlwZSBmaWVsZCBpbiBpdD8NCg0KQmVzdCByZWdhcmRzLA0KWGlh b2h1DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IG5zYy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBTdXJlbmRyYQ0K PiBLdW1hciAoc21rdW1hcikNCj4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0OeaciDbml6UgMzowNA0K PiDmlLbku7bkuro6IFJvbiBQYXJrZXI7IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBNZWxpbmRh IFNob3JlOyBuc2NAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW25zY10gTlNDIFdvcmtpbmcgR3Jv dXAgQ2hhcnRlciBQcm9wb3NhbA0KPiANCj4gSnVzdCB0byBhZGQsIGZvciBjbGFyaXR5KGhvcGVm dWxseSkuDQo+IA0KPiBUaGlzIGlzIHRoZSBpbnRlbnQ6IFtUcmFuc3BvcnQtRW5jYXBzdWxhdGlv bi9IZWFkZXIgfA0KPiBTZXJ2aWNlLUVuY2Fwc3VsYWl0b24vSGVhZGVyIHwgT3JpZ2luYWwtcGF5 bG9hZF0NCj4gV2hlcmUsDQo+IE9yaWdpbmFsLXBheWxvYWQgICAgICAgIDogYW4gSVAgcGFja2V0 IHdpdGhvdXQgdGhlIGxheWVyLTIgaGVhZGVyIG9yIGl0DQo+IGNvdWxkIGJlIGEgZnJhbWUgd2l0 aCB0aGUgTDItaGVhZGVyLiBUaGlzIGRlcGVuZHMgb24gdGhlIGludGVyY2VwdGlvbg0KPiBsYXll ci4NCj4gVHJhbnNwb3J0IEVuY2FwIGV4YW1wbGVzOiBMTEMvU05BUCwgR1JFL05WR1JFLCBWWExB TiwgVURQL1VEUC1saXRlLCDFoA0KPiBTZXJ2aWNlIEVuY2FwICAgICAgICAgICA6IGlzIHdoZXJl IHRoZSBzZXJ2aWNlLXBhdGgtaWRlbnRpZmllci8uLi4gSXMNCj4gY2FycmllZCBpbiBvcmRlciB0 byBiZSBhYmxlIHRvIGlkZW50aWZ5IHRoZSBjaGFpbiBvciB0aGUgZm9yd2FyZGluZyBwYXRoLg0K PiANCj4gU3VyZW5kcmEuDQo+IA0KPiBPbiA5LzUvMTMgMTE6NTIgQU0sICJSb24gUGFya2VyIiA8 Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4NCj4gd3JvdGU6DQo+IA0KPiA+VGhhbmtz IGZvciB5b3VyIHBhdGllbmNlLCBKaW0hDQo+ID4NCj4gPkRvZXMgeW91ciBkZXNjcmlwdGlvbiBw cmUtc3VwcG9zZSB0aGF0IHRoZXJlIGlzIGFsd2F5cyBhbm90aGVyIElQIGhlYWRlcg0KPiA+YXBw bGllZD8gICBGb3IgZXhhbXBsZSwgYW4gb3JpZ2luYWwgVENQIHNlZ21lbnQgY291bGQgbG9vayBs aWtlIHRoaXMNCj4gPihhc3N1bWluZyBVRFAtYmFzZWQgZW5jYXAgZm9yIHRoaXMgZXhhbXBsZSk6 DQo+ID4NCj4gPglPdXRlci1pcC91ZHAvbnNjL2lubmVyLWlwL3RjcC9wYXlsb2FkDQo+ID4NCj4g PkkgY2FuIGRlZmluaXRlbHkgZ2V0IG15IGhlYWQgYXJvdW5kIHRoYXQgYXMgaXQgaXMgYSB1bml2 ZXJzYWwgc29sdXRpb24NCj4gPnRoYXQgcHJlc3VtZXMgYW4gSVAgbmV0d29yaywgb25seS4NCj4g Pg0KPiA+SSBtYXkgYmUgbWlzaW50ZXJwcmV0aW5nIGJ1dCBJIHN1c3BlY3QgdGhhdCBzb21lIG9u IHRoaXMgdGhyZWFkIGFyZW4ndCBvbg0KPiA+dGhlIHNhbWUgcGFnZSAoYXQgbGVhc3QgeWV0KSBh bmQgbWF5IGJlIHRoaW5raW5nIHRoYXQgaW4gY2VydGFpbiBuZXR3b3JrDQo+ID50b3BvbG9naWVz IHRoZSBvdXRlciBJUCBjYW4vc2hvdWxkIGJlIGF2b2lkZWQuICAgICBJZiB0aGF0IGlzIHRoZSBj YXNlLCBJDQo+ID5jYW4ndCBzZWUgaG93IHRoZSBuc2MgaW5mb3JtYXRpb24gY2FuIGJlIGluc2Vy dGVkIGFmdGVyIHRoZSB0cmFuc3BvcnQsDQo+ID53aGljaCB3b3VsZCBjcmVhdGUgc29tZXRoaW5n IHRoYXQgbG9va3MgbGlrZSB0aGlzOg0KPiA+DQo+ID4JSXAvdGNwL25zYy9wYXlsb2FkDQo+ID4N Cj4gPlRoYW5rcy4NCj4gPg0KPiA+ICAgIFJvbg0KPiA+DQo+ID4NCj4gPi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID5Gcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpn dWljaGFyQGNpc2NvLmNvbV0NCj4gPlNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDUsIDIwMTMg MTo0OSBQTQ0KPiA+VG86IFJvbiBQYXJrZXI7IE1lbGluZGEgU2hvcmU7IG5zY0BpZXRmLm9yZw0K PiA+U3ViamVjdDogUmU6IFtuc2NdIE5TQyBXb3JraW5nIEdyb3VwIENoYXJ0ZXIgUHJvcG9zYWwN Cj4gPg0KPiA+SGkgUm9uLA0KPiA+DQo+ID5CeSBlbmNhcHN1bGF0aW9uIHdlIG1lYW4gc29tZXRo aW5nIGluc2VydGVkIGJldHdlZW4gdGhlIHRyYW5zcG9ydA0KPiA+ZW5jYXBzdWxhdGlvbiBhbmQg dGhlIG9yaWdpbmFsIHBhY2tldCBwYXlsb2FkLiBUaGVyZSBhcmUgdHdvIHRoaW5ncyB0aGF0DQo+ ID5uZWVkIHRvIGhhcHBlbjsgKDEpIGlkZW50aWZ5IHRoYXQgInNlcnZpY2UgY2hhaW5pbmciIGlu Zm9ybWF0aW9uIGZvbGxvd3MNCj4gPnRoZSB0cmFuc3BvcnQgaGVhZGVyLCBhbmQgKDIpIGVuY2Fw c3VsYXRlIHRoZSBhY3R1YWwgc2VydmljZSBjaGFpbmluZw0KPiA+aW5mb3JtYXRpb24uIE5vdyB5 b3UgY291bGQgZ28gZG93biB0aGUgcGF0aCBvZiB0cnlpbmcgdG8gZm9yY2UgZml0IHRoZQ0KPiA+ c2VydmljZSBjaGFpbmluZyBpbmZvcm1hdGlvbiBpbnRvIHRoZSB0cmFuc3BvcnQgYnV0IHRoYXQg aW1obyBpcyBhDQo+ID5taXN0YWtlIHdlIHNob3VsZCBhdm9pZC4NCj4gPg0KPiA+T24gOS81LzEz IDE6NDQgUE0sICJSb24gUGFya2VyIiA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4N Cj4gd3JvdGU6DQo+ID4NCj4gPj5JIGFwb2xvZ2l6ZSBpZiBJJ20gYmVpbmcgdGhpY2sgb24gdGhp cywgYnV0IEknbSBzdGlsbCBoYXZpbmcgdHJvdWJsZSB3aXRoDQo+ID4+dGhlIG1lYW5pbmcgb2Yg ImVuY2Fwc3VsYXRpb24iIGhlcmUuICAgSXQgaGFzIGJlZW4gcG9pbnRlZCBvdXQgdGhhdCBpdCBp cw0KPiA+PnRoZSB0aGluZyB0aGF0IGNhcnJpZXMgaW5mb3JtYXRpb24gbGlrZSBjaGFpbiBpZCwg aG9wIGluZGV4LCBhbmQgcG9zc2libHkNCj4gPj5tZXRhZGF0YSBhYm91dCB0aGUgZmxvdywgYnV0 IGV4Y2x1ZGVzIHRoZSAib3ZlcmxheSIgZW5jYXBzdWxhdGlvbi4gICAgU28NCj4gPj5pZiBJIHRo aW5rIGFib3V0IHNvbWV0aGluZyB0aGF0IHJlc2VtYmxlcyBHUkUsIHdoZW4gd2Ugc2F5DQo+ID4+ ZW5jYXBzdWxhdGlvbiwgd2UgYXJlIG1lYW5pbmcgdGhlIHBhcnQgb2YgR1JFIHRoYXQgaGFzIHRo ZSBrZXkgYnV0IG5vdA0KPiA+PnRoZSBwYXJ0IG9mIEdSRQ0KPiA+PnRoYXQgYWRkcyBhbm90aGVy IElQIGhlYWRlci4gICAgV2hlcmUgSSByZWFsbHkgZ2V0IHR3aXN0ZWQgYXJvdW5kIHRoZQ0KPiA+ PmF4bGUgaXMgaWYgSSB0aGluayBhYm91dCB0aGlzIGluZm9ybWF0aW9uIGJlaW5nIGVtYmVkZGVk IGluIGFuIElQdjQNCj4gPj5vcHRpb24gb3IgSVB2NiBleHRlbnNpb24gaGVhZGVyLiAgIE5vdCB0 aGF0IHdlJ3JlIG5lY2Vzc2FyaWx5IGNob29zaW5nDQo+ID4+dGhvc2UsIGJ1dCBpZiB3ZSBkaWQs IHdvdWxkIHdlIGNhbGwgdGhhdCAiZW5jYXBzdWxhdGlvbiI/DQo+ID4+DQo+ID4+VGhhbmtzLg0K PiA+Pg0KPiA+PiAgICBSb24NCj4gPj4NCj4gPj4NCj4gPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+PkZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+Pk1lbGluZGEgU2hvcmUNCj4gPj5TZW50OiBUaHVy c2RheSwgU2VwdGVtYmVyIDA1LCAyMDEzIDEyOjU4IFBNDQo+ID4+VG86IG5zY0BpZXRmLm9yZw0K PiA+PlN1YmplY3Q6IFJlOiBbbnNjXSBOU0MgV29ya2luZyBHcm91cCBDaGFydGVyIFByb3Bvc2Fs DQo+ID4+DQo+ID4+T24gOS81LzEzIDY6NDUgQU0sIExpbmRhIER1bmJhciB3cm90ZToNCj4gPj4+ IFRoaXMgdmVyc2lvbiBoYXNuJ3QgYWRkcmVzc2VkIHRoZSBjb21tZW50cyBvbiBCdWxsZXQgMyBv ZiByZXF1aXJpbmcgYQ0KPiA+Pj4gc2luZ2xlIGVuY2Fwc3VsYXRpb24gYmVpbmcgdG9vIGxpbWl0 aW5nIG9yIG1heSBub3QgZXZlbiBiZSByZWFsaXN0aWMuDQo+ID4+DQo+ID4+VGhlcmUncyBubyBh Z3JlZW1lbnQgdGhhdCB0aGF0J3MgdGhlIGNhc2UuDQo+ID4+DQo+ID4+TWVsaW5kYQ0KPiA+Pg0K PiA+Pg0KPiA+Pg0KPiA+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+bnNjIG1haWxpbmcgbGlzdA0KPiA+Pm5zY0BpZXRmLm9yZw0KPiA+Pmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+ID4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj5uc2MgbWFpbGluZyBsaXN0DQo+ ID4+bnNjQGlldGYub3JnDQo+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uc2MNCj4gPg0KPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPm5zYyBtYWlsaW5nIGxpc3QNCj4gPm5zY0BpZXRmLm9yZw0KPiA+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5zYyBtYWlsaW5nIGxpc3QNCj4gbnNj QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo= From jiangyuanlong@huawei.com Tue Sep 10 02:19: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 8E54A21E80AC for ; Tue, 10 Sep 2013 02:19:38 -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=[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 JjgFh1IN0MbZ for ; Tue, 10 Sep 2013 02:19:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DFB7A11E810B for ; Tue, 10 Sep 2013 02:19:31 -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.5-GA FastPath queued) with ESMTP id AXE14309; Tue, 10 Sep 2013 09:19:30 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 10:19:22 +0100 Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 10:19:28 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.229]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0146.000; Tue, 10 Sep 2013 17:19:14 +0800 From: Jiangyuanlong To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: Back to the charter ... Thread-Index: AQHOqyeZwMPgp+Js6UOHmDI/e3mhO5m+rpYg Date: Tue, 10 Sep 2013 09:19:14 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6AD8B3@szxema506-mbs.china.huawei.com> References: <68B171751455884590F8E38E96416F363F678E4B@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F678E4B@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_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6AD8B3szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Zhuhengjun Subject: Re: [nsc] Back to the charter ... X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 09:19:38 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6AD8B3szxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, Please see my inline comments on the new charter. Cheers, Yuanlong From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Saturday, September 07, 2013 1:36 AM To: nsc@ietf.org Subject: [nsc] Back to the charter ... Folks, Here is the current version of the charter. Please be encouraged to review = further and add comments. I would especially welcome those subscribers on t= he list that have yet to comment - we have at current count 299 subscribers= so I know you are out there ;-) : Proposed NSC WG Charter Existing service insertion and deployment techniques fail to address new ch= allenging requirements raised by the introduction of emerging technologies = such as multi-tenancy, virtualization, elasticity, and rich classification.= Networks, servers, and other storage technologies, let alone applications,= have all undergone significant change in recent years: virtualization, net= work overlays, and orchestration have increasingly become techniques that c= ount and sometimes prevail. All of these have profound effects on network a= nd services design. Today, deploying new services, or making changes to existing services, ofte= n requires network topology changes. Adding and removing service functions = is a complex, risky task, that is tied to operationalizing topological chan= ges leading to massively static configuration procedures for network servic= e delivery or update purposes. The structuring and the delivery of new netw= ork services assume the (smart) combination of various service functions as= shared resources, and enable the linkage of these resources using service = function chains that represent the abstracted view of the required service = functions, and define the order in which they should be invoked. Such (smar= t) combinations could be made of heterogeneous service functions which may = act at various layers of a protocol stack (network layer, application layer= , etc). When a service function chain is instantiated in a network, specifi= c instances of service functions are selected, and a service topology is cr= eated and used for forwarding packets according to the service function cha= in. A basic service function chain might simply utilize an existing overlay tec= hnology to force traffic through the necessary service functions. However, = additional information that is shared across a subset of service functions = may enable a richer service function chain for more advanced composite serv= ices. For example, shared information, such as the results of a classificat= ion function, may be passed to downstream service functions to enable the o= ffloading of service function processing or to share information that would= otherwise be hard to glean. The Network Service Chaining (NSC) working group focuses on new and simpler= approaches to network service structuring, insertion, and deployment, prov= iding a framework for the construction of services built using service func= tion chains. The WG focuses on the necessary protocols for management (e.g.= create, delete, monitor) of service function chains, and the transmission = of network and service-specific information from the network to service fun= ctions, and between service functions. When possible, the WG will extend ex= isting protocols to provide service chaining functionality, and any protoco= l extensions will be reviewed by both the Network Service Chaining WG and b= y the WG responsible for the protocol being extended. Specifically, the Network Service Chaining WG is chartered to deliver the f= ollowing work items: 1) Problem Statement: this document will provide a summary of the pro= blem space to be addressed by the Network Service Chaining WG including exa= mple high-level use cases. Additionally, the WG will normalize on nomencla= ture and definitions for service function chaining. [JY] I would expect most nomenclature and definitions for service function = chaining shall appear in the architecture document. 2) System Architecture: this set of documents will provide a descript= ion of the architecture building blocks and their relationships including i= nterconnection, placement of capabilities, and security models, as well as = requirements on the control mechanisms and data plane encapsulation. [JY] Data plane of service chaining may cover more topics than encapsulatio= n, could we remove "encapsulation" from the above texts to generalize it? 3) Service Function Chaining Data & Control Plane: A data plane docum= ent will describe on the wire data plane encapsulation in support of (2). A= single service-level encapsulation will be selected in order to enable int= eroperability of data plane components, which can in turn be carried in var= ious transport encapsulations (e.g., IP, MPLS, or other overlays). Supporti= ng control plane protocol elements will be added as needed (as a separate d= ocument). [JY] Same comment as 2), can we generalize the description of the data plan= e document? 4) Manageability: this document will address service function chainin= g management in support of (2) including relevant MIBs and YANG information= models, and service function chaining OAM. [JY] According to RFC 3444, information models are high level "abstract mod= els", while MIB and YANG are detailed data models. Thus it is proposed to r= eplace "relevant MIBs and YANG information models" with "information models= , relevant MIBs and YANG data models". Proposed Milestones: Dec 2013 Request publication of an Informational document defining the Netw= ork Service Function Chaining problem statement to the IESG Mar 2014 Request publication of informational documents defining the system= architecture including protocol requirements and framework to the IESG May 2014 Request publication of a Standards Track document specifying the d= ata-plane service-level encapsulation (including context data) for Service = Function Chaining to IESG May 2014 Request publication of an informational document specifying Servic= e Function Chaining Control Plane requirements to IESG Dec 2014 Request publication of Informational document(s) defining Network = Service Function Chaining use cases to IESG Dec 2014 Request publication of informational documents defining Service Fu= nction Chaining manageability including MIBs, OAM, and YANG information mod= els to IESG [JY] I think MIB, YANG data model and OAM should all be in Standards Track. --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6AD8B3szxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 = ;

Please see= my inline comments on the new charter.

 = ;

Cheers,

Yuanlong

 = ;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, September 07, 2013 1:36 AM
To: nsc@ietf.org
Subject: [nsc] Back to the charter ...

 

Folks,<= /o:p>

 <= /o:p>

Here is the = current version of the charter. Please be encouraged to review further and = add comments. I would especially welcome those subscribers on the list that have yet to comment – we have at current count 299 = subscribers so I know you are out there ;-) :

 <= /o:p>

Proposed = NSC WG Charter

 <= /o:p>

Existing ser= vice insertion and deployment techniques fail to address new challenging re= quirements raised by the introduction of emerging technologies such as multi-tenancy, virtualization, elasticity, and rich classification= . Networks, servers, and other storage technologies, let alone applications= , have all undergone significant change in recent years: virtualization, ne= twork overlays, and orchestration have increasingly become techniques that count and sometimes prevail. All = of these have profound effects on network and services design.

 <= /o:p>

Today, deplo= ying new services, or making changes to existing services, often requires n= etwork topology changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological cha= nges leading to massively static configuration procedures for network servi= ce delivery or update purposes. The structuring and the delivery of new net= work services assume the (smart) combination of various service functions as shared resources, and enable t= he linkage of these resources using service function chains that represent = the abstracted view of the required service functions, and define the order= in which they should be invoked. Such (smart) combinations could be made of heterogeneous service functions= which may act at various layers of a protocol stack (network layer, applic= ation layer, etc). When a service function chain is instantiated in a netwo= rk, specific instances of service functions are selected, and a service topology is created and used for for= warding packets according to the service function chain.<= /p>

 <= /o:p>

A basic serv= ice function chain might simply utilize an existing overlay technology to f= orce traffic through the necessary service functions. However, additional information that is shared across a subset of service functions= may enable a richer service function chain for more advanced composite ser= vices. For example, shared information, such as the results of a classifica= tion function, may be passed to downstream service functions to enable the offloading of service function = processing or to share information that would otherwise be hard to glean.&n= bsp;

 <= /o:p>

The Network = Service Chaining (NSC) working group focuses on new and simpler approaches = to network service structuring, insertion, and deployment, providing a framework for the construction of services built using service= function chains. The WG focuses on the necessary protocols for management = (e.g. create, delete, monitor) of service function chains, and the transmis= sion of network and service-specific information from the network to service functions, and between service fun= ctions. When possible, the WG will extend existing protocols to provide ser= vice chaining functionality, and any protocol extensions will be reviewed b= y both the Network Service Chaining WG and by the WG responsible for the protocol being extended.  <= /o:p>

 <= /o:p>

Specifically= , the Network Service Chaining WG is chartered to deliver the following wor= k items: 

 <= /o:p>

1)=        Prob= lem Statement: this document will provide a summary of the problem space to= be addressed by the Network Service Chaining WG including example high-level use cases.  Additionally, the WG will normalize on= nomenclature and definitions for service function chaining.

= [JY] I would expect most nomencla= ture and definitions for service function chaining shall appear in the architecture document.

 <= /o:p>

2)=        Syst= em Architecture: this set of documents will provide a description of the ar= chitecture building blocks and their relationships including interconnection, placement of capabilities, and security models, as well a= s requirements on the control mechanisms and data plane encapsulation.

= [JY] Data plane of service chaini= ng may cover more topics than encapsulation, could we remove “encapsulation” from the above texts to generalize it?

 <= /o:p>

3)=        Serv= ice Function Chaining Data & Control Plane: A data plane document will = describe on the wire data plane encapsulation in support of (2). A single service-level encapsulation will be selected in order to ena= ble interoperability of data plane components, which can in turn be carried= in various transport encapsulations (e.g., IP, MPLS, or other overlays). S= upporting control plane protocol elements will be added as needed (as a separate document).

= [JY] Same comment as 2), can we g= eneralize the description of the data plane document?

=  

 <= /o:p>

4)=        Mana= geability: this document will address service function chaining management = in support of (2) including relevant MIBs and YANG information models, and service function chaining OAM.

= [JY] According to RFC 3444, infor= mation models are high level “abstract models”, while MIB and YANG are detailed data models. Thus it is proposed to replace “relev= ant MIBs and YANG information models” with “information models,= relevant MIBs and YANG data models”.

=  

 <= /o:p>

Proposed Mil= estones:

 <= /o:p>

Dec 2013 Req= uest publication of an Informational document defining the Network Service = Function Chaining problem statement to the IESG

 <= /o:p>

Mar 2014 Req= uest publication of informational documents defining the system architectur= e including protocol requirements and framework to the IESG

 <= /o:p>

May 2014 Req= uest publication of a Standards Track document specifying the data-plane se= rvice-level encapsulation (including context data) for Service Function Chaining to IESG

 <= /o:p>

May 2014 Req= uest publication of an informational document specifying Service Function C= haining Control Plane requirements to IESG

 <= /o:p>

Dec 2014 Req= uest publication of Informational document(s) defining Network Service Func= tion Chaining use cases to IESG

 <= /o:p>

Dec 2014 Req= uest publication of informational documents defining Service Function Chain= ing manageability including MIBs, OAM, and YANG information models to IESG 

[JY] I thi= nk MIB, YANG data model and OAM should all be in Standards Track.

 

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6AD8B3szxema506mbschi_-- From tnadeau@lucidvision.com Tue Sep 10 05: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 EF9CE21E8051 for ; Tue, 10 Sep 2013 05:17:51 -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 C8Qql5pBYC2q for ; Tue, 10 Sep 2013 05:17:47 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8979421E808F for ; Tue, 10 Sep 2013 05:17:43 -0700 (PDT) Received: from [172.28.130.161] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id BA5672564B6C; Tue, 10 Sep 2013 08:17:41 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_06044D71-C2F3-4930-AFB5-3EB24748F9A0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: <522D9151.2060701@joelhalpern.com> Date: Tue, 10 Sep 2013 08:17:40 -0400 Message-Id: <2EDE883A-5CD8-47B3-937B-2DA43827FB5E@lucidvision.com> References: <94C682931C08B048B7A8645303FDC9F36EF06D097B@PUEXCB1B.nanterre.francetelecom.fr> <522D9151.2060701@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1508) Cc: "nsc@ietf.org" , mohamed.boucadair@orange.com, Ken Gray , Ron Parker Subject: Re: [nsc] NSC Working Group Charter Proposal 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, 10 Sep 2013 12:17:52 -0000 --Apple-Mail=_06044D71-C2F3-4930-AFB5-3EB24748F9A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I'd second that. We shouldn't get caught up in documenting = things in unnecessarily heavyweight ways. If someone wants to write an = informational draft that captures this information, that is totally cool = - and I'd imagine the WG would encourage it - but an explicit charter = item seems like overkill to me.=20 --Tom On Sep 9, 2013:5:13 AM, at 5:13 AM, "Joel M. Halpern" = wrote: > I agree that capturing architecture / design rationale is very useful. > I don't want it in a separate from the architecture / design that it = is supporting. >=20 > Also, we should be careful not to get to wrapped up in getting the = perfect explanation of the decisions. We need good explanations, not = perfect ones with all the nuances. >=20 > Yours, > Joel >=20 > On 9/9/13 4:32 AM, mohamed.boucadair@orange.com wrote: >> Hi Ken, >>=20 >> I still think there is a value to include an explicit charter item >> for the design choice analysis document, at least for the following >> reasons: >>=20 >> * The mailing list archives can be used to retrieve some of the >> justifications for some design choices, but the result is not >> guaranteed, the data is not structured, etc. >>=20 >> * There are even some WGs that do not publish the meeting >> minutes...and for those WGs it is hard to find when and why a design >> choice was made. >>=20 >> * IESG review may sometimes conflict with the WG consensus. Authors >> are invited to engage in discussions to explain the motivations and >> provide justification for the choices recorded in the draft. For the >> context of the nsc effort, I do think that energy (time to resolve >> concerns) can be optimized if a formal tool was provided by the >> working group: (1) simple specification document + (2) a companion >> document that motivates the design choices and the candidates >> solutions that were considered. >>=20 >> * Given the aggressive proposed milestones for nsc, we need the work >> to be focused so as to be able to produce the expected deliverables >> while being open to any proposal that can put on the table. >>=20 >> Cheers, Med >>=20 >>> -----Message d'origine----- De : nsc-bounces@ietf.org >>> [mailto:nsc-bounces@ietf.org] De la part de Ken Gray Envoy=E9 : >>> vendredi 6 septembre 2013 17:32 =C0 : Ron Parker; Linda Dunbar; Jim >>> Guichard (jguichar); Melinda Shore; nsc@ietf.org Objet : Re: [nsc] >>> NSC Working Group Charter Proposal >>>=20 >>> Hey, Ron. >>>=20 >>> I tend to agree with the charter proposal as is. Those four >>> documents should be more than adequate. >>>=20 >>> The design/analysis document could be used as a strawman for the >>> discussion of the decisions imbedded in the ultimate architecture >>> document, but doesn't have to have a life of it's own ...those >>> discussions can/would typically be archived in the WG mailer (THIS >>> mailer) for anyone who would want to catch up on the discussion, >>> IMO. >>>=20 >>> (I had to capitalize the THIS because I also don't believe we need >>> more than THIS list to discuss WG business. This has nothing to do >>> with Ron, btw, I'm editorializing.) >>>=20 >>>=20 >>> On 9/6/13 10:38 AM, "Ron Parker" >>> wrote: >>>=20 >>>> Hi, Linda, >>>>=20 >>>> When I referenced an inner IP, I more properly should have >>>> referenced "original packet", which I think you are pointing out, >>>> correctly, is not necessarily IP. Even in this case, I think >>>> it is important to state whether a new "transport" is always >>>> required in front of the "original packet" or not. >>>>=20 >>>> So if we exemplify this with a layer 2 "transport" and a layer 2 >>>> original packet, we might have something like: >>>>=20 >>>> /encaps-enet/llc-snap/nsc-header/original-enet/payload >>>>=20 >>>> If we take another example of a layer 2/3/4 "transport" and a >>>> layer 2 original packet, we might have something like: >>>>=20 >>>> /encaps-enet/ip/udp/nsc-header/original-enet/payload >>>>=20 >>>> The reason I am being pedantic here is that these approaches >>>> contrast to other possible solutions where an outer "transport" >>>> is not added. For example, if we were entertaining mapping the >>>> nsc-header to a new IPv4 option and new IPv6 extension header for >>>> use only when the "original packet" is an IPv4 or IPv6 packet, >>>> then an encapsulating "transport" would not necessarily be >>>> required. Again, we come to simplicity/universality vs. >>>> efficiency (at least in terms of packet size if not necessarily >>>> processing requirements). >>>>=20 >>>> This is obviously an important area to cover in the WG. Some of >>>> this analysis is presented in >>>> draft-boucadair-chaining-design-analysis and we intend to add >>>> more of this pros/cons analysis wrt the overall encapsulation >>>> issue in an upcoming revision. >>>>=20 >>>> I would like to take the opportunity to back previous suggestions >>>> that a design choices analysis document become a part of the WG >>>> chartered deliverables as it encourages a more open and >>>> transparent process and ultimately provides a better record of >>>> how the eventual recommendations are arrived at. >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- From: Linda Dunbar >>>> [mailto:linda.dunbar@huawei.com] Sent: Friday, September 06, 2013 >>>> 10:17 AM To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; >>>> nsc@ietf.org Subject: RE: [nsc] NSC Working Group Charter >>>> Proposal >>>>=20 >>>> Ron, >>>>=20 >>>> Great! I am glad to see that we go down this path. We should >>>> also allow: /enet/ip/udp or tcp/nsc/... i.e. not necessarily >>>> having an inner IP. >>>>=20 >>>> Linda >>>>=20 >>>>=20 >>>>> -----Original Message----- From: Ron Parker >>>>> [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, >>>>> September 05, 2013 6:16 PM To: Linda Dunbar; Jim Guichard >>>>> (jguichar); Melinda Shore; nsc@ietf.org Subject: RE: [nsc] NSC >>>>> Working Group Charter Proposal >>>>>=20 >>>>> Hi, Linda. >>>>>=20 >>>>> As it was recently explained on this thread, I don't think it >>>>> needs to be necessary to always have it if we are willing to >>>>> allow multiple overall "transport"+service encapsulations. >>>>> For example: >>>>>=20 >>>>> /enet/ip/udp/nsc/ip/tcp/... /enet/ip/gre/nsc/ip/tcp/... >>>>> /enet/llc-snap/nsc/ip/tcp/... /enet/mpls/nsc/ip/tcp/... >>>>>=20 >>>>> As much as I don't think we'll end up there, I do find a >>>>> single overall universal transformation very attractive and any >>>>> flavor that is /{l2}/ip/xxx/ip/tcp would be universally >>>>> applicable -- same subnet or different subnet, l2 switches >>>>> and/or l3 routers in between , OpenFlow or not OpenFlow, MPLS >>>>> or not MPLS, ... The argument against this will be that the >>>>> packets are bigger than they need to be for some network >>>>> topologies/protocols. Simplicity or efficiency? >>>>>=20 >>>>> Ron >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- From: Linda Dunbar >>>>> [mailto:linda.dunbar@huawei.com] Sent: Thursday, September 05, >>>>> 2013 5:19 PM To: Ron Parker; Jim Guichard (jguichar); Melinda >>>>> Shore; nsc@ietf.org Subject: RE: [nsc] NSC Working Group >>>>> Charter Proposal >>>>>=20 >>>>> I can see the need for this "NSC" header inserted to the >>>>> packets, and occasionally needing an "outer-ip" encapsulation >>>>> to by-pass nodes that can't parse the "NSC" header. >>>>>=20 >>>>> Can someone explain why it is necessary to always have the >>>>> "outer-ip" header? >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>>=20 >>>>>> Outer-ip/udp/nsc/inner-ip/tcp/payload >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Linda >>>> _______________________________________________ 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 >> _______________________________________________ nsc mailing list >> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >>=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 --Apple-Mail=_06044D71-C2F3-4930-AFB5-3EB24748F9A0 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 iQIcBAEBCgAGBQJSLw3kAAoJEPcO+I7eiUJZHfAP/izJR65iQPEBWztpm4an4i+t R3yhn1smvbu1mQW1Gjh04lSEMZ4usoYNURSpA9y2/OgvP4IOesyr++jZM/KkvoB6 xf1i7N7rWBuOss4bPw1oXw3Yx2NIVjH17H7WTUKgR1/HdKL9WQu7byQJdLJJxAWm xBKsoojCEgwHdWgrgRIQOBbt0j68GTjFRDL4MwvWnt8MWQuhQg4sYgaePpXbYwzf jn9/lekT6bCiYG5EdB6e6mwQaCrxFdWuNDyHVraQTCZ5Xgf1PwHcWceNGnQ5LaWF Upg4XfFE0cv7ZkG1Mg+LiDXLWId5V5PDH8QUGnbnPXokRv3Oo2wfbhOYbd21UbYW cS8JBhjaY429G01yBa3M9bm4xjVQeH+8eVJy8RjQ/UAj8JvMNyjopJm5OYj4mg7i 3WjRs/wwefr0BRwO94fPgGKpJRAKhfJmBfqBddX1gc6MzUiHREQEiSBqiciUlBh8 SGjjWCa+q7q/3wL89WQUeYcAHFg1Xq5pc9irnYth076BcN2+AfdS3cDGhG85UAuB SOyNlDUQqV+FcdWeoeRrXVhZwfCFKi4fl36UcCMiLyt1qCeT1FCjUp2+5ky9xQ2n 7aOi3MuhO2XFEEG7E3lee81EiwyHojeORx3rwoWJmHLbnK+09cjG4yaHOw+7TmU9 kI/XAwoQR43bnaQXd8cZ =Hbyr -----END PGP SIGNATURE----- --Apple-Mail=_06044D71-C2F3-4930-AFB5-3EB24748F9A0-- From jguichar@cisco.com Tue Sep 10 15:56: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 5E12921F9A17 for ; Tue, 10 Sep 2013 15:56:25 -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=[AWL=-0.000, 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 Aw+gibSH4qx2 for ; Tue, 10 Sep 2013 15:56:08 -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 A813721F8721 for ; Tue, 10 Sep 2013 15:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11011; q=dns/txt; s=iport; t=1378853768; x=1380063368; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=RXaUDgIEyEoZ9D0SGYZY6aKNVwSISU23Z/KWEh9yJy0=; b=YZ8UIwMX8fMWToeSBYYBn3dQx2gRHnTIZ+4oVxs8SH1uZaQjuma/24eW Z1v8qUoIEDtMyzDnafdQMmAxsOuaOCHqkJHiX4MTnJww+aS3Bm06+gAfz 9VMUxFAd7hmmRSA823aGraz2RkDwyxwtCgGngZwWediQGP/ffrKf1bpGo M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAHCiL1KtJV2c/2dsb2JhbABbgkNEgQnCYIElFnSCJQEBAQRnJAEIEQMBAgsdORQJCAIEARIIh3rDJ44SgRggGIMdgQADlByVRYMggXE5 X-IronPort-AV: E=Sophos;i="4.90,880,1371081600"; d="scan'208,217";a="258064768" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 10 Sep 2013 22:55:57 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8AMtv7h029236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Sep 2013 22:55:57 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 10 Sep 2013 17:55:56 -0500 From: "Jim Guichard (jguichar)" To: Kevin Glavin , "nsc@ietf.org" Thread-Topic: [nsc] Back to the charter ... Thread-Index: AQHOqyeZwMPgp+Js6UOHmDI/e3mhO5m95u+AgAHFUwA= Date: Tue, 10 Sep 2013 22:55:56 +0000 Message-ID: <68B171751455884590F8E38E96416F363F67E325@xmb-rcd-x01.cisco.com> In-Reply-To: <9EA32E60D7600C43B6FE22876DF564C81D65765F@SFO1EXC-MBXP06.nbttech.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.86.241.111] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F67E325xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] Back to the charter ... X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 22:56:44 -0000 --_000_68B171751455884590F8E38E96416F363F67E325xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kevin, Apologies for my delayed response; just catching up on email. Inline. From: Kevin Glavin > Date: Monday, September 9, 2013 4:53 PM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: Re: [nsc] Back to the charter ... Jim, With regards to the 'meta data' that may be shunted along the service chain= , is there any proposal to work on some minimum level of standardization of= this data with the scope of this charter? I assume that as a chain could/would be populated with service logic from m= ultiple vendors then a base set of capabilities within the meta data would = make initial adaption easier? Jim> I don't think that belongs in the charter, rather, if needed we can lo= ok at two approaches to address this: 1. Decide on a registry for common metadata. 2. Write a draft that defines some core metadata that is broadly agreed as= needed. Having said that, I think of these as future work, i.e. we won't bite it of= f now. If so is this part of (3) below, or is it something else that may need to b= e added to the target deliverables? The flip side of this is that this meta data may be tied to specific use ca= ses and as such would be handled in that sphere and considered outside the = scope of the current work deliverables. Jim> We expect this as well. For example, in mobile, the operators will ha= ve metadata specific to their deployment. I think option #2 above, specifi= c drafts, or well defined and partitioned registration procedures, will be = required. Kevin From: "Jim Guichard (jguichar)" > Date: Friday, September 6, 2013 10:36 AM To: "nsc@ietf.org" > Subject: [nsc] Back to the charter ... Folks, Here is the current version of the charter. Please be encouraged to review = further and add comments. I would especially welcome those subscribers on t= he list that have yet to comment =96 we have at current count 299 subscribe= rs so I know you are out there ;-) : Proposed NSC WG Charter =85.. 3) Service Function Chaining Data & Control Plane: A data plane document wi= ll describe on the wire data plane encapsulation in support of (2). A singl= e service-level encapsulation will be selected in order to enable interoper= ability of data plane components, which can in turn be carried in various t= ransport encapsulations (e.g., IP, MPLS, or other overlays). Supporting con= trol plane protocol elements will be added as needed (as a separate documen= t). =85=85 --_000_68B171751455884590F8E38E96416F363F67E325xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <364BB1094E3CC2479CB2C5F5FF289D57@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Kevin,

Apologies for my delayed response; jus= t catching up on email. Inline. 

From: Kevin Glavin <Kevin.Glavin@riverbed.com>
Date: Monday, September 9, 2013 4:5= 3 PM
To: Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Back to the char= ter ...

Jim, 

With regards to the 'meta data' that may be shunted along the service = chain, is there any proposal to work on some minimum level of standardizati= on of this data with the scope of this charter? 
I assume that as a chain could/would be populated with service logic f= rom multiple vendors then a base set of capabilities within the meta data w= ould make initial adaption easier?  

Jim> I don't think that belongs in the chart= er, rather, if needed we can look at two approaches to address this:

1.  Decide on a = registry for common metadata.
2.  Write a draf= t that defines some core metadata that is broadly agreed as needed.<= /div>

Having said that, I t= hink of these as future work, i.e. we won't bite it off now.
If so is this part of (3) below, or is it something else that may need= to be added to the target deliverables? 

The flip side of this is that this meta data may be tied to specific u= se cases and as such would be handled in that sphere and considered outside= the scope of the current work deliverables. 

Jim> We expect this as well.  For examp= le, in mobile, the operators will have metadata specific to their deployment.  I think option #2 above, specific drafts, or&nb= sp;well defined and partitioned registration procedures, will be required.

Kevin




From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Friday, September 6, 2013 10:= 36 AM
To: "nsc@ietf.org" <nsc@ietf.= org>
Subject: [nsc] Back to the charter = ...

Folks,

Here is the current version of the charter. Please be encouraged to re= view further and add comments. I would especially welcome those subscribers= on the list that have yet to comment =96 we have at current count 299 subs= cribers so I know you are out there ;-) :

Proposed NSC WG Charter

=85..

3) Service Function Chaining Data & Control Plane: A data plane do= cument will describe on the wire data plane encapsulation in support of (2)= . A single service-level encapsulation will be selected in order to enable = interoperability of data plane components, which can in turn be carried in various transport encapsulations (e.g., IP= , MPLS, or other overlays). Supporting control plane protocol elements will= be added as needed (as a separate document).

=85=85
 --_000_68B171751455884590F8E38E96416F363F67E325xmbrcdx01ciscoc_-- From mohamed.boucadair@orange.com Tue Sep 10 23:53: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 B8DF021F9D70 for ; Tue, 10 Sep 2013 23:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.190, 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 vnXKenknnCJh for ; Tue, 10 Sep 2013 23:53:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2078921F9FD0 for ; Tue, 10 Sep 2013 23:53:32 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 14C4E264538; Wed, 11 Sep 2013 08:53:31 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DFCA735C04E; Wed, 11 Sep 2013 08:53:30 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 11 Sep 2013 08:53:28 +0200 From: To: "Carlos Pignataro (cpignata)" Date: Wed, 11 Sep 2013 08:53:27 +0200 Thread-Topic: [nsc] Explicitly identifying design analysis activities in the charter Thread-Index: Ac6tPvgKt/rWZcFNTlm9NDAtkUmduAAQ2beAAAnYU3D//71UgP/9m3UQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0EE8145@PUEXCB1B.nanterre.francetelecom.fr> References: <13701_1378719226_522D95FA_13701_2718_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C56F653EA@PUEXCB1C.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED325F154CD@xmb-aln-x02.cisco.com> <94C682931C08B048B7A8645303FDC9F36EF06D0B4A@PUEXCB1B.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED325F1584E@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED325F1584E@xmb-aln-x02.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.11.44515 Cc: "nsc@ietf.org" , "Joel M. Halpern" , Ron Parker , Ken Gray , JACQUENET Christian IMT/OLN Subject: Re: [nsc] Explicitly identifying design analysis activities in the charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 06:53:37 -0000 Hi Carlos, Glad to see we are voicing for a simple design and avoid over-specifying. Given the answers received so far:=20 * there is a common agreement (some) design analysis is useful and will be = needed * the analysis can be included in the documents already listed in the chart= er proposal.=20 That's fair and fine by me.=20 Can we update the charter to reflect that outcome: i.e., update items (3) a= nd (4) of the proposed charter to mention the design analysis? Cheers, Med=20 >-----Message d'origine----- >De=A0: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >Envoy=E9=A0: lundi 9 septembre 2013 15:14 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: JACQUENET Christian IMT/OLN; Joel M. Halpern; nsc@ietf.org; Ken Gra= y; >Ron Parker >Objet=A0: Re: [nsc] Explicitly identifying design analysis activities in t= he >charter > >Hi, Med, > >Thanks for the follow-up, please see inline. > >On Sep 9, 2013, at 9:01 AM, > wrote: > >> Hi Carlos, >> >> If there is a risk for paralysis then the root causes are elsewhere ... >not in the analysis itself. >> >> We all agree there is no perfect solution. > >I think that the best approach is to sparringly sprinkle analysis details >when needed for a particularly important or contentious decision, inside >another doc as per charter, and not peanut-butter (meaning adding >unconditionally everywhere) design decision rationale or create a new doc. > >> That's not the point. The main point of the analysis is to explain the >design choices and make sure we are not over specifying as per: > >I would not feel the need to explain every design choice. Only very small >number of limited ones. > >> >> "A protocol design is complete not when you can't think of any >> more things to add, but when you have removed everything you can >> and you can't see how to remove any more", >> > >"Il semble que la perfection soit atteinte non quand il n'y a plus rien = =E0 >ajouter, mais quand il n'y a plus rien =E0 retrancher.", Antoine de Saint >Exup=E9ry. > >And RFC 1925. > >Indeed, that should be a guiding principle here. > >Thanks, > >-- Carlos. > >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>> Envoy=E9 : lundi 9 septembre 2013 14:31 >>> =C0 : JACQUENET Christian IMT/OLN >>> Cc : Joel M. Halpern; BOUCADAIR Mohamed IMT/OLN; nsc@ietf.org; Ken Gray= ; >>> Ron Parker >>> Objet : Re: [nsc] Explicitly identifying design analysis activities in >the >>> charter >>> >>> The risk, and a very real one, is that design analysis turns into desig= n >>> paralysis. >>> >>> I support Joel's call for simplifying the doc set and not letting >perfect >>> be the enemy of good. In this, a focused small design analysis >>> complementing key architectural decisions is useful, as adding color to >the >>> main docs. >>> >>> Thanks, >>> >>> -- Carlos. >>> >>> On Sep 9, 2013, at 5:33 AM, christian.jacquenet@orange.com wrote: >>> >>>> Dear all, >>>> >>>> I share both Joel's and Med's positions. I think the design analysis >>> should be (1) explicitly mentioned as one of the activities conducted b= y >>> the nsc WG in its charter and (2) documented in a chartered nsc WG >document >>> (be it the architecture document, as mentioned by Joel). >>>> >>>> Cheers, >>>> >>>> Christian. >>>> >>>> -----Message d'origine----- >>>> De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de >>> Joel M. Halpern >>>> Envoy=E9 : lundi 9 septembre 2013 11:14 >>>> =C0 : BOUCADAIR Mohamed IMT/OLN >>>> Cc : nsc@ietf.org; Ken Gray; Ron Parker >>>> Objet : Re: [nsc] NSC Working Group Charter Proposal >>>> >>>> I agree that capturing architecture / design rationale is very useful. >>>> I don't want it in a separate from the architecture / design that it i= s >>> supporting. >>>> >>>> Also, we should be careful not to get to wrapped up in getting the >>> perfect explanation of the decisions. We need good explanations, not >>> perfect ones with all the nuances. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 9/9/13 4:32 AM, mohamed.boucadair@orange.com wrote: >>>>> Hi Ken, >>>>> >>>>> I still think there is a value to include an explicit charter item fo= r >>>>> the design choice analysis document, at least for the following >>>>> reasons: >>>>> >>>>> * The mailing list archives can be used to retrieve some of the >>>>> justifications for some design choices, but the result is not >>>>> guaranteed, the data is not structured, etc. >>>>> >>>>> * There are even some WGs that do not publish the meeting >>>>> minutes...and for those WGs it is hard to find when and why a design >>>>> choice was made. >>>>> >>>>> * IESG review may sometimes conflict with the WG consensus. Authors >>>>> are invited to engage in discussions to explain the motivations and >>>>> provide justification for the choices recorded in the draft. For the >>>>> context of the nsc effort, I do think that energy (time to resolve >>>>> concerns) can be optimized if a formal tool was provided by the >>>>> working group: (1) simple specification document + (2) a companion >>>>> document that motivates the design choices and the candidates >>>>> solutions that were considered. >>>>> >>>>> * Given the aggressive proposed milestones for nsc, we need the work >>>>> to be focused so as to be able to produce the expected deliverables >>>>> while being open to any proposal that can put on the table. >>>>> >>>>> Cheers, Med >>>>> >>>> >>>> >>> >__________________________________________________________________________= _ >>> ______________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>> recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >messages >>> electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, deform= e >>> ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or privilege= d >>> information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and >>> delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have >>> been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >> From jguichar@cisco.com Fri Sep 13 07:08: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 59DB821F9D34 for ; Fri, 13 Sep 2013 07:08:12 -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=[AWL=-0.000, 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 kGE8phN3K8D2 for ; Fri, 13 Sep 2013 07:08:06 -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 1290B21F9D62 for ; Fri, 13 Sep 2013 07:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37165; q=dns/txt; s=iport; t=1379081286; x=1380290886; h=from:to:subject:date:message-id:mime-version; bh=rpUXOZMO5p8kyo121VKKHlfxTa0ywJFdHdch/7dhSfg=; b=XcGdCefLDl/MNBGsmEQK8fvTV0JTS5qgqiOag5P/CAu0D7M0jN+sG7wa jwRDrZY1t05w/0YJ2RXYq3oO47WAjbDf2kpu6hb2GLHOmiKxz2iIqHS2+ nUv941XgdLFhPsspoYRO0ZfJww8yV6Z3+gISLgoJB+F3Fk6sRaecfxpUq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAKwbM1KtJXG//2dsb2JhbABbgkNEgQrAaoEZFm0HgicBBCkEOgsZAQIYEBYBPxcQBBsMh2+ZDqEGjj6BAoNWgQADlB6VUIMkgWlB X-IronPort-AV: E=Sophos;i="4.90,898,1371081600"; d="scan'208,217";a="259359235" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 13 Sep 2013 14:08:05 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8DE85kh004858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Sep 2013 14:08:05 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 13 Sep 2013 09:08:05 -0500 From: "Jim Guichard (jguichar)" To: "nsc@ietf.org" Thread-Topic: New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2Ig== Importance: high X-Priority: 1 Date: Fri, 13 Sep 2013 14:08:03 +0000 Message-ID: <68B171751455884590F8E38E96416F363F68DCFA@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.86.240.56] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F68DCFAxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: [nsc] New NSC 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, 13 Sep 2013 14:08:12 -0000 --_000_68B171751455884590F8E38E96416F363F68DCFAxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network. Service deliver= y is currently both a technical and organisational challenge that involves = significant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_68B171751455884590F8E38E96416F363F68DCFAxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <9F27FBC4D964C24ABFC3F4BCD0D673D7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Greetings,

We have been working with the routing area= AD's and our IAB shepherd Joel Halpern over the last few days to refine th= e NSC WG charter. The following is our proposal to the community for review= and comment. Please note that as an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "S= ervice Function Chaining (SFC)". 

Proposed Service Function Chaining (= SFC) WG Charter

Networks, servers, storage te= chnologies, and applications, have all undergone significant change in rece= nt years with the introduction of virtualization, network overlays, and orchestration. The process of service delivery is ch= anging from the physical insertion of equipment on the path into a mechanis= m for causing the path or data to transit specific physical or virtual node= s on which the service functions are performed. For a given service, t= he abstracted view of the required service functions and the order in which= they are to be invoked is called a Service Function Chain (SFC). Since a given serv= ice function may be available on more than one node within a network, a Ser= viceFunction Chain is instantiated via the selection of specific service fu= nction instances and the network nodes on which they are provided, thereby forming a servicetopology: this = is called a Service Function Path. The service functions may be applied at = a specific layer within the network protocol stack (network layer, applicat= ion layer, etc.).

The Service Function C= haining (SFC) working group will develop new approaches to service delivery= and deployment, by providing a framework for service function chaining and the necessary p= rotocols or protocol extensions to convey the service path = and for communication between nodes that implement service functions.  The working group will also examine what information needs to be gat= hered from the network and service functions in support of service function= chaining and how that information may be made available to nodes that impl= ement the service functions.

Specifical= ly, the SFC WG is chartered to deliver the following: 

1) Problem= Statement: This document will provide a summary of the problem space to be= addressed by the WG including example high-level use cases.  Additionally, the = WG will normalize nomenclature and definitions for service function chainin= g.

2) Archite= cture: This document will provide a description of the architectural buildi= ng blocks and their relationships including interconnection, placement of capabiliti= es, management, diagnostics, and security models, as well as requirements o= n the protocol mechanisms.

3) Generic= Service Function Chaining Encapsulation: A document will describe the sing= le service-level encapsulation protocol for conveying the service function chain and the se= rvice function path, and for communicating information between nodes that i= mplement service functions. It is intended that the encapsulation be agnost= ic to thenetwork layer at which it is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realised at the netwo= rk layer or at any other layer, and the same encapsulation willapply for th= e construction of service function paths regardless of the actual service.

4) Control= Plane Mechanisms: A set of documents will be developed to describe require= ments and protocols necessary to convey information to service function implementati= on points. Where possible, existing IETF protocols will be used and extende= d. All protocol extensions work should be carried out = in the working groups responsible for the protocols being modified in coord= ination with this working group, but may be done in this working group afte= r agreement with all the relevant WG chairs and responsible ADs.

5) Managea= bility: This document will address the management of service function chain= ing includingrelevant MIBs and YANG data modules, and service function chaining diagnostics.

Proposed M= ilestones (all dates TBD):

Request th= e IESG for publication of an Informational document defining the problem st= atement and core use cases for Service Function Chaining

Request th= e IESG for publication of Informational documents defining the architecture= for SFC and describing the framework and requirements for a generic service functi= on chaining encapsulation protocol.

Request th= e IESG for publication of a Standards Track document specifying the generic= service function chaining encapsulation protocol.

Request th= e IESG for publication of Informational documents specifying control plane = requirements in support of specific SFC use cases.

Request th= e IESG for publication of an Informational document defining SFC manageabil= ity including diagnostics, and MIB and YANG data models to IESG <= /p>

Request the IES= G for publication of Informational applicability documents defining how the= protocol elements developed by the WG may be combined with other IETF protocols to satisfy the use cases.



--_000_68B171751455884590F8E38E96416F363F68DCFAxmbrcdx01ciscoc_-- From linda.dunbar@huawei.com Fri Sep 13 07:42:16 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 30F9B21F9F77 for ; Fri, 13 Sep 2013 07:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=0.765, 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 M4Gcca57XiQd for ; Fri, 13 Sep 2013 07:42:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3EF21F9F01 for ; Fri, 13 Sep 2013 07:42:10 -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.5-GA FastPath queued) with ESMTP id AXH33915; Fri, 13 Sep 2013 14:42:08 +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.146.0; Fri, 13 Sep 2013 15:41:44 +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.146.0; Fri, 13 Sep 2013 15:42:01 +0100 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.225]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 07:41:55 -0700 From: Linda Dunbar To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnDu0AQ Date: Fri, 13 Sep 2013 14:41:54 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F68DCFA@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.99.203.187] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645BBCA42dfweml509mbbchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] New NSC 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, 13 Sep 2013 14:42:16 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645BBCA42dfweml509mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like the new name! "Service Function Chaining" is much more clear in describing the intent of = the proposed work. IMHO, it would be even more clear to replace the "Services" across the char= ter with "Service Functions", like "..Service functions delivery...", to di= fferentiate from the today's connectivity/VPN "services". Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network. Service deliver= y is currently both a technical and organisational challenge that involves = significant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_4A95BA014132FF49AE685FAB4B9F17F645BBCA42dfweml509mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like = the new name!

“= Service Function Chaining” is much more clear in describing the inten= t of the proposed work.

IMHO, i= t would be even more clear to replace the “Services” across the= charter with “Service Functions”, like “..Service functi= ons delivery...”, to differentiate from the today’s connectivit= y/VPN “services”.

&n= bsp;

Linda

&n= bsp;

From: nsc-bounces@ietf.org [mailto:ns= c-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational = challenge that involves significant modification to the network configurati= on.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):<= /o:p>

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645BBCA42dfweml509mbbchi_-- From adrian@olddog.co.uk Fri Sep 13 08:00: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 1C23321E80D5 for ; Fri, 13 Sep 2013 08:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.084, 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 ElEf+C6jcCVG for ; Fri, 13 Sep 2013 08:00:01 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id D964F11E8170 for ; Fri, 13 Sep 2013 08:00:00 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8DExmoM027790; Fri, 13 Sep 2013 15:59:48 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8DExkxN027718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Sep 2013 15:59:47 +0100 From: "Adrian Farrel" To: "'Linda Dunbar'" , "'Jim Guichard \(jguichar\)'" , References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> Date: Fri, 13 Sep 2013 15:59:48 +0100 Message-ID: <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0215_01CEB09A.46512BE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEu6VdITONGxYVPfqNTPZVA4U3NIgGSN51Qmva+qwA= Content-Language: en-gb Subject: Re: [nsc] New NSC WG Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 15:00:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0215_01CEB09A.46512BE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Linda, I think it is important to be very clear when we mean service and when we mean service function. IMHO, service functions are not delivered. Service functions are executed to deliver services. Perhaps rather than a global search and replace, you could suggest specific instances to be replaced? Thanks, Adrian From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of the proposed work. IMHO, it would be even more clear to replace the "Services" across the charter with "Service Functions", like "..Service functions delivery...", to differentiate from the today's connectivity/VPN "services". Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel Halpern over the last few days to refine the NSC WG charter. The following is our proposal to the community for review and comment. Please note that as an outcome of the various discussions on the list we are proposing that the WG name change from "Network Service Chaining (NSC)" to "Service Function Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergone significant change in recent years with the introduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the physical insertion of equipment on the path into a mechanism for causing the path or data to transit specific physical or virtual nodes on which the service functions are performed. Services are typically implemented by the ordered combination of a number of service functions that may be implemented at different points within the network. Service delivery is currently both a technical and organisational challenge that involves significant modification to the network configuration. For a given service, the abstracted view of the required service functions and the order in which they are to be invoked is called a Service Function Chain (SFC). Since a given service function may be available on more than one node within a network, a ServiceFunction Chain is instantiated via the selection of specific service function instances and the network nodes on which they are provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be applied at a specific layer within the network protocol stack (network layer, application layer, etc.). The Service Function Chaining (SFC) working group will develop new approaches to service delivery and deployment, 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. The working group will also examine what information needs to be gathered from the network and service functions in support of service function chaining and how that information may be made available to nodes that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high-level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining. 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level encapsulation protocol for conveying the service function chain and the service function path, and for communicating information between nodes that implement service functions. It is intended that the encapsulation be agnostic to thenetwork layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realised at the network layer or at any other layer, and the same encapsulation willapply for the construction of service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service function chaining includingrelevant MIBs and YANG data modules, and service function chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the architecture for SFC and describing the framework and requirements for a generic service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying the generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying control plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents defining how the protocol elements developed by the WG may be combined with other IETF protocols to satisfy the use cases. ------=_NextPart_000_0215_01CEB09A.46512BE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Linda,

I think it is = important to be very clear when we mean service and when we mean service = function.

IMHO, service = functions are not delivered. Service functions are executed to deliver = services.

Perhaps rather than a = global search and replace, you could suggest specific instances to be = replaced?

Thanks,

Adrian

 

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f= ont-family:"Times New = Roman";mso-ansi-language:EN-US'>From: = nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of = Linda Dunbar
Sent: 13 September 2013 15:42
To: = Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] New = NSC WG Charter

 

I like the new name!

“Service Function = Chaining” is much more clear in describing the intent of the = proposed work.

IMHO, it would be even more clear to replace the = “Services” across the charter with “Service = Functions”, like “..Service functions delivery...”, to = differentiate from the today’s connectivity/VPN = “services”.

 

Linda

 

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-ansi-lang= uage:EN-US'>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On = Behalf Of Jim Guichard (jguichar)
Sent: Friday, September = 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New = NSC WG Charter
Importance: = High

 

Greetings,<= o:p>

 =

We have = been working with the routing area AD's and our IAB shepherd Joel = Halpern over the last few days to refine the NSC WG charter. The = following is our proposal to the community for review and comment. = Please note that as an outcome of the various discussions on the list we = are proposing that the WG name change from "Network Service = Chaining (NSC)" to "Service Function Chaining = (SFC)". 

 =

<= u>Proposed = Service Function Chaining (SFC) WG Charter=

 =

Networks, = servers, storage technologies, and applications, have all undergone = significant change in recent years with the introduction of = virtualization, network overlays, and orchestration. The process of = service delivery is changing from the physical insertion of equipment on = the path into a mechanism for causing the path or data to transit = specific physical or virtual nodes on which the service functions are = performed. Services are typically implemented by the ordered combination = of a number of service functions that may be implemented at different = points within the network. Service delivery = is currently both a technical and organisational challenge that involves = significant modification to the network configuration.=

For a given = service, the abstracted view of the required service functions and the = order in which they are to be invoked is called a Service Function Chain = (SFC). Since a given service function may be available on more than one = node within a network, a ServiceFunction Chain is instantiated via the = selection of specific service function instances and the network nodes = on which they are provided, thereby forming a servicetopology: this is = called a Service Function Path. The service functions may be applied at = a specific layer within the network protocol stack (network layer, = application layer, etc.).=

The Service = Function Chaining (SFC) working group will develop new approaches to = service delivery and deployment, 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.  The working group will also examine = what information needs to be gathered from the network and service = functions in support of service function chaining and how that = information may be made available to nodes that implement the service = functions.=

Specifically, = the SFC WG is chartered to deliver the following: =

1) Problem = Statement: This document will provide a summary of the problem space to = be addressed by the WG including example high-level use cases. =  Additionally, the WG will normalize nomenclature and definitions = for service function chaining.=

2) Architecture: = This document will provide a description of the architectural building = blocks and their relationships including interconnection, placement of = capabilities, management, diagnostics, and security models, as well as = requirements on the protocol mechanisms.=

3) Generic = Service Function Chaining Encapsulation: A document will describe the = single service-level encapsulation protocol for conveying the service = function chain and the service function path, and for communicating = information between nodes that implement service functions. It is = intended that the encapsulation be agnostic to thenetwork layer at which = it is applied and the service that is being constructed. That is, the = same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation = willapply for the construction of service function paths regardless of = the actual service.=

4) Control Plane = Mechanisms: A set of documents will be developed to describe = requirements and protocols necessary to convey information to service = function implementation points. Where possible, existing IETF protocols = will be used and extended. All protocol = extensions work should be carried out in the working groups responsible = for the protocols being modified in coordination with this working = group, but may be done in this working group after agreement with all = the relevant WG chairs and responsible ADs.

5) = Manageability: This document will address the management of service = function chaining includingrelevant MIBs and YANG data modules, and = service function chaining diagnostics.=

Proposed = Milestones (all dates TBD):=

Request the IESG = for publication of an Informational document defining the problem = statement and core use cases for Service Function Chaining=

Request the IESG = for publication of Informational documents defining the architecture for = SFC and describing the framework and requirements for a generic service = function chaining encapsulation protocol.=

Request the IESG = for publication of a Standards Track document specifying the generic = service function chaining encapsulation protocol.=

Request the IESG = for publication of Informational documents specifying control plane = requirements in support of specific SFC use cases.=

Request the IESG = for publication of an Informational document defining SFC manageability = including diagnostics, and MIB and YANG data models to = IESG =

Request the IESG = for publication of Informational applicability documents defining how = the protocol elements developed by the WG may be combined with other = IETF protocols to satisfy the use cases.=

 =

 =

------=_NextPart_000_0215_01CEB09A.46512BE0-- From Ron_Parker@affirmednetworks.com Fri Sep 13 08:03: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 831C321F9C9A for ; Fri, 13 Sep 2013 08:03:27 -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 9iremluXKu5g for ; Fri, 13 Sep 2013 08:03:21 -0700 (PDT) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8C71F11E8113 for ; Fri, 13 Sep 2013 08:03:21 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0123.003; Fri, 13 Sep 2013 08:03:21 -0700 From: Ron Parker To: "adrian@olddog.co.uk" , 'Linda Dunbar' , "'Jim Guichard (jguichar)'" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnDu0AQgAB8ywD//4r/MA== Date: Fri, 13 Sep 2013 15:03:19 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> In-Reply-To: <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> 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_CDF2F015F4429F458815ED2A6C2B6B0B1A6F2748MBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:03:27 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6F2748MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I tend to agree. A service is something that a service provider could des= cribe as an offering to its customers and perhaps charge for it. A good = many of these service offerings are realized by the application of a sequen= ce of one or more service functions in the data plane. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Adria= n Farrel Sent: Friday, September 13, 2013 11:00 AM To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of = the proposed work. IMHO, it would be even more clear to replace the "Services" across the char= ter with "Service Functions", like "..Service functions delivery...", to di= fferentiate from the today's connectivity/VPN "services". Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network. Service deliver= y is currently both a technical and organisational challenge that involves = significant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6F2748MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I tend to agree. =   A service is something that a service provider could describe as an = offering to its customers and perhaps charge for it.    A go= od many of these service offerings are realized by the application of a sequence of one or more service functions in the data plane.

   Ron<= /o:p>

From: nsc-bounces@ietf.org [mailto:nsc-bounce= s@ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= o:p>

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 

I like = the new name!

“= Service Function Chaining” is much more clear in describing the inten= t of the proposed work.

IMHO, i= t would be even more clear to replace the “Services” across the= charter with “Service Functions”, like “..Service functi= ons delivery...”, to differentiate from the today’s connectivit= y/VPN “services”.

&n= bsp;

Linda

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational = challenge that involves significant modification to the network configurati= on.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):<= /o:p>

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6F2748MBX021W3CA2exch_-- From andre.beliveau@ericsson.com Fri Sep 13 08:08: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 C76D121E80AD for ; Fri, 13 Sep 2013 08:08:05 -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 ZKva0OGW-t1w for ; Fri, 13 Sep 2013 08:07:59 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id BB3EE21E8055 for ; Fri, 13 Sep 2013 08:07:58 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-d4-52332a4b90b4 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 51.4C.03458.B4A23325; Fri, 13 Sep 2013 17:07:56 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Fri, 13 Sep 2013 11:07:55 -0400 From: Andre Beliveau To: Ron Parker , "adrian@olddog.co.uk" , 'Linda Dunbar' , "'Jim Guichard (jguichar)'" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnDu0AQgABKgACAAAD8gP//vR2Q Date: Fri, 13 Sep 2013 15:07:55 +0000 Message-ID: <3049626EAC5C3E43866CD2692A7E19AC1C2317B0@eusaamb103.ericsson.se> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_3049626EAC5C3E43866CD2692A7E19AC1C2317B0eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPrK6PlnGQQWuboMWPnhvMFkvnqVvc bZnIZHF83342iwtPpzI7sHq8uPKM2WPK742sHi1H3rJ6LFnyk8ljxeaVjAGsUVw2Kak5mWWp Rfp2CVwZl148YCyYfYuxYsbM2ewNjGf3MXYxcnBICJhITLzv3cXICWSKSVy4t56ti5GLQ0jg KKNE26K9TBDOckaJQxtBGjg52ASMJN5fmcQIkhARuMMo8frmL3aQhLCAqsT9/dOZQWwRATWJ rlMLGCFsN4kvuxeA1bAA1czovcACYvMK+ErcWrgeasMsJolPPy+xgiQ4BaIljs75C2YzCshK bJj4DayBWUBc4taT+UwQtwpILNlznhnCFpV4+fgfK4StLPF9ziOo+nyJFZfvMEIsE5Q4OfMJ ywRGkVlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxchRWpxalptuZLiJ ERh/xyTYHHcwLvhkeYhRmoNFSZx3g96ZQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MsyZu KBZNvbPt/43Vp6ya3XZp8K/sClgQ2Zm79aoxk8Las9yVRoKJZ673blzOnPvQ+vO1QCPz+Afy myZf1OfLPakGjJNV2TePuM78wmMmP3PhF5e0a0t+Zn5q/22s537xrJRMRNTr/2eEL9sdYM9o 77O6vE9w+RKn40mq8y6oMt85KfJoyixnJZbijERDLeai4kQAg+Nzv40CAAA= Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:08:06 -0000 --_000_3049626EAC5C3E43866CD2692A7E19AC1C2317B0eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some suggestion for the new name for "The resulting service that a service = provider can offer to its customers as a result of forming Service Function= Chains" : Delivered Service Network Service (which could be confused with earlier usage of the name) Composite Service Resulting Service My preference goes for Composite Service. /AB From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron P= arker Sent: September-13-13 11:03 AM To: adrian@olddog.co.uk; 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@iet= f.org Subject: Re: [nsc] New NSC WG Charter I tend to agree. A service is something that a service provider could des= cribe as an offering to its customers and perhaps charge for it. A good = many of these service offerings are realized by the application of a sequen= ce of one or more service functions in the data plane. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Adrian Farrel Sent: Friday, September 13, 2013 11:00 AM To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of = the proposed work. IMHO, it would be even more clear to replace the "Services" across the char= ter with "Service Functions", like "..Service functions delivery...", to di= fferentiate from the today's connectivity/VPN "services". Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network. Service deliver= y is currently both a technical and organisational challenge that involves = significant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_3049626EAC5C3E43866CD2692A7E19AC1C2317B0eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some suggestion for th= e new name for “The resulting se= rvice that a service provider can offer to its customers as a result of for= ming Service Function Chains” :<= o:p>

Delivered Service
Network Service (which could be confused with earlier usage of the name) Composite Service
Resulting Service

My preference goes for= Composite Service.

/AB<= /p>

From: nsc-bounces@ietf.org [mailto:ns= c-bounces@ietf.org] On Behalf Of Ron Parker
Sent: September-13-13 11:03 AM
To: adrian@olddog.co.uk; 'Linda Dunbar'; 'Jim Guichard (jguichar)'; = nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

I tend to agree. =   A service is something that a service provider could describe as an = offering to its customers and perhaps charge for it.    A go= od many of these service offerings are realized by the application of a sequence of one or more service functions in the data plane.

   Ron<= /o:p>

 

From: nsc-bounces@ietf.org [mailto:n= sc-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= o:p>

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 

I like = the new name!

“= Service Function Chaining” is much more clear in describing the inten= t of the proposed work.

IMHO, i= t would be even more clear to replace the “Services” across the= charter with “Service Functions”, like “..Service functi= ons delivery...”, to differentiate from the today’s connectivit= y/VPN “services”.

&n= bsp;

Linda

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational = challenge that involves significant modification to the network configurati= on.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):<= /o:p>

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_3049626EAC5C3E43866CD2692A7E19AC1C2317B0eusaamb103erics_-- From lucy.yong@huawei.com Fri Sep 13 08:09: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 3C47911E8113 for ; Fri, 13 Sep 2013 08:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.206, 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 AfzA5GFjdpix for ; Fri, 13 Sep 2013 08:09:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5C011E812F for ; Fri, 13 Sep 2013 08:08:57 -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.5-GA FastPath queued) with ESMTP id AVJ48216; Fri, 13 Sep 2013 15:08: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.146.0; Fri, 13 Sep 2013 16:08:38 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 16:08:54 +0100 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.225]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 08:08:46 -0700 From: Lucy yong To: Ron Parker , "adrian@olddog.co.uk" , Linda Dunbar , "'Jim Guichard (jguichar)'" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQEu6VdITONGxYVPfqNTPZVA4U3NIgGSN51Qmva+qwCAAHcFgP//iydA Date: Fri, 13 Sep 2013 15:08:45 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452C67D1@dfweml509-mbb.china.huawei.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.16] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452C67D1dfweml509mbbchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:09:09 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452C67D1dfweml509mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do you mean "by the application of a sequence of service functions that are= available on some nodes within a network." Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron P= arker Sent: Friday, September 13, 2013 10:03 AM To: adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.= org Subject: Re: [nsc] New NSC WG Charter I tend to agree. A service is something that a service provider could des= cribe as an offering to its customers and perhaps charge for it. A good = many of these service offerings are realized by the application of a sequen= ce of one or more service functions in the data plane. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Adrian Farrel Sent: Friday, September 13, 2013 11:00 AM To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of = the proposed work. IMHO, it would be even more clear to replace the "Services" across the char= ter with "Service Functions", like "..Service functions delivery...", to di= fferentiate from the today's connectivity/VPN "services". Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network. Service deliver= y is currently both a technical and organisational challenge that involves = significant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_2691CE0099834E4A9C5044EEC662BB9D452C67D1dfweml509mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Do you mean “by = the application of a sequence of service functions that are available on so= me nodes within a network.”

Lucy=

 

From: nsc-bounces@ietf.org [mailto:ns= c-bounces@ietf.org] On Behalf Of Ron Parker
Sent: Friday, September 13, 2013 10:03 AM
To: adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; ns= c@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

I tend to agree. =   A service is something that a service provider could describe as an = offering to its customers and perhaps charge for it.    A go= od many of these service offerings are realized by the application of a sequence of one or more service functions in the data plane.

   Ron<= /o:p>

 

From: nsc-bounces@ietf.org [mailto:n= sc-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= o:p>

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 

I like = the new name!

“= Service Function Chaining” is much more clear in describing the inten= t of the proposed work.

IMHO, i= t would be even more clear to replace the “Services” across the= charter with “Service Functions”, like “..Service functi= ons delivery...”, to differentiate from the today’s connectivit= y/VPN “services”.

&n= bsp;

Linda

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational = challenge that involves significant modification to the network configurati= on.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):<= /o:p>

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D452C67D1dfweml509mbbchi_-- From kgray@juniper.net Fri Sep 13 08:13: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 595DC21F95DC for ; Fri, 13 Sep 2013 08:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kIHLTldpU4Vo for ; Fri, 13 Sep 2013 08:13:17 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0991721E8109 for ; Fri, 13 Sep 2013 08:13:12 -0700 (PDT) Received: from mail107-va3-R.bigfish.com (10.7.14.232) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Sep 2013 15:13:11 +0000 Received: from mail107-va3 (localhost [127.0.0.1]) by mail107-va3-R.bigfish.com (Postfix) with ESMTP id C0FFF801BF; Fri, 13 Sep 2013 15:13:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zzdb82h9371Ic85ehzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de097h186068h8275bh8275dhz2fh2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h1155h) Received-SPF: pass (mail107-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(189002)(199002)(65816001)(80976001)(16236675002)(69226001)(19580395003)(4396001)(81542001)(561944002)(49866001)(47736001)(50986001)(47976001)(83322001)(19580405001)(54316002)(83506001)(56776001)(81342001)(15975445006)(54356001)(56816003)(74366001)(31966008)(74502001)(74876001)(79102001)(63696002)(74662001)(74706001)(18717965001)(36756003)(47446002)(81816001)(76176001)(77096001)(77982001)(59766001)(46102001)(76482001)(15202345003)(76796001)(81686001)(51856001)(83072001)(53806001)(76786001)(80022001)(19300405004); 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 mail107-va3 (localhost.localdomain [127.0.0.1]) by mail107-va3 (MessageSwitch) id 1379085188570642_6964; Fri, 13 Sep 2013 15:13:08 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.237]) by mail107-va3.bigfish.com (Postfix) with ESMTP id 780122C005D; Fri, 13 Sep 2013 15:13:08 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 13 Sep 2013 15:13:08 +0000 Received: from BL2PR05MB083.namprd05.prod.outlook.com (10.255.232.26) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.353.4; Fri, 13 Sep 2013 15:13:04 +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.775.9; Fri, 13 Sep 2013 15:13:02 +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.0775.005; Fri, 13 Sep 2013 15:13:02 +0000 From: Ken Gray To: Linda Dunbar , "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnDu0AQ///IAIA= Date: Fri, 13 Sep 2013 15:13:02 +0000 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@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: 0968D37274 Content-Type: multipart/alternative; boundary="_000_CE589FBE16B856kgrayjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:13:22 -0000 --_000_CE589FBE16B856kgrayjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Or we can just agree that, while we're in a WG room labeled Service Functio= n Chaining or reading a document with such a heading =85 that we're not imp= lying connectivity/VPN services (or any other macro use of the word service= ) and are really just discussing - service functions. I hope this isn't mis-interpreted, because I (for one) am sure to slip and = say "service" instead of "service function" in such a context and hope to a= ssume that everyone will be understanding. From: Linda Dunbar = > Date: Fri, 13 Sep 2013 14:41:54 +0000 To: "Jim Guichard (jguichar)" >, "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter I like the new name! =93Service Function Chaining=94 is much more clear in describing the intent= of the proposed work. IMHO, it would be even more clear to replace the =93Services=94 across the = charter with =93Service Functions=94, like =93..Service functions delivery.= ..=94, to differentiate from the today=92s connectivity/VPN =93services=94. Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network.Service delivery= is currently both a technical and organisational challenge that involves s= ignificant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. _______________________________________________ nsc mailing list nsc@ietf.o= rg https://www.ietf.org/mailman/listinfo/nsc --_000_CE589FBE16B856kgrayjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Or we can just agree that, while we're in a WG room labeled Service Fu= nction Chaining or reading a document with such a heading =85 that we're no= t implying connectivity/VPN services (or any other macro use of the word se= rvice) and are really just discussing - service functions.  

I hope this isn't mis-interpreted, because I (for one) am sure to slip= and say "service" instead of "service function" in suc= h a context and hope to assume that everyone will be understanding.

From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Fri, 13 Sep 2013 14:41:54 = 3;0000
To: "Jim Guichard (jguichar)&q= uot; <jguichar@cisco.com>, = "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] New NSC WG Chart= er

I like = the new name!

=93Serv= ice Function Chaining=94 is much more clear in describing the intent of the= proposed work.

IMHO, i= t would be even more clear to replace the =93Services=94 across the charter= with =93Service Functions=94, like =93..Service functions delivery...=94, = to differentiate from the today=92s connectivity/VPN =93services=94.

&n= bsp;

Linda

&n= bsp;

From:= nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge that i= nvolves significant modification to the network configuration.=

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):<= /o:p>

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

_______________________________________________ nsc mailing list nsc@ietf.org http= s://www.ietf.org/mailman/listinfo/nsc --_000_CE589FBE16B856kgrayjunipernet_-- From andre.beliveau@ericsson.com Fri Sep 13 08:19: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 D232D11E812F for ; Fri, 13 Sep 2013 08:19:14 -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 XCnh37lZmV8q for ; Fri, 13 Sep 2013 08:19:08 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9170721F99BD for ; Fri, 13 Sep 2013 08:18:37 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-6b-52332ccc47fb Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4C.DF.09414.CCC23325; Fri, 13 Sep 2013 17:18:37 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Fri, 13 Sep 2013 11:18:19 -0400 From: Andre Beliveau To: "nsc@ietf.org" Thread-Topic: Re: [nsc] New NSC WG Charter Thread-Index: Ac6wlE1Wh6GxIpwbRKirnkegTPG0Nw== Date: Fri, 13 Sep 2013 15:18:18 +0000 Message-ID: <3049626EAC5C3E43866CD2692A7E19AC1C231980@eusaamb103.ericsson.se> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_3049626EAC5C3E43866CD2692A7E19AC1C231980eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyuXRPrO5ZHeMgg033mSyO79vP5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujK9vvzAWXNKtaJku28C4VaOLkZNDQsBE4t+BblYIW0ziwr31 bF2MXBxCAkcZJc41nmWFcJYzSvy7OIkRpIpNwEji/RUQm4NDREBRYuebFJCwsICqxKSGycwg toiAlsT6F/fYIEr0JA7/VAQJswCV7DzdzAJi8wr4Smya+pAdxGYUkJXYMPEbWJxZQFzi1pP5 TBD3CEgs2XOeGcIWlXj5+B/UncoS3+c8gqrPl5j47BQjxExBiZMzn7BMYBSahWTULCRls5CU QcT1JG5MncIGYWtLLFv4mhnC1pWY8e8QC7L4Akb2VYwcpcWpZbnpRgabGIFBf0yCTXcH456X locYpTlYlMR5V+mdCRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAyKEw28Il7dWGEuHM5YZi Max7f+wJqPqVeNbBsqdg8feLO5c7qF1ltF+4btrEZqMHvLtfzWpaUbX/YOW3iyfbZzZFTBXc /aHBNut9NOsGzTqJ/3sinKa/c7j+xm+TWc0ktmUh+ltm8c93PVn/NvTT8XM8K6MWMiZseeh2 +9rRU58Yj1gk/XNcmq7EUpyRaKjFXFScCABtFXmTSAIAAA== Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:19:14 -0000 --_000_3049626EAC5C3E43866CD2692A7E19AC1C231980eusaamb103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Here are the sentences where I would replace Service by Composite Service (= or another agreed name) in the proposed charter: --- Composite Services are typically implemented by the ordered combination of = a number of service functions that may be implemented at different points w= ithin the network. Composite Services delivery is currently both a technica= l and organisational challenge that involves significant modification to th= e network configuration. For a given Composite Service, the abstracted view of the required service = functions and the order in which they are to be invoked is called a Service= Function Chain (SFC). The Service Function Chaining (SFC) working group wi= ll develop new approaches to Composite Service delivery and deployment, by = providing a framework for service function chaining and the necessary proto= cols or protocol extensions to convey the service path and for communicatio= n between nodes that implement service functions. --- Regards, Andr=E9 B=E9liveau, Ing. Tel.: +1 (514) 345 2708 Mobile: +1 (514) 502 9592 mailto:andre.beliveau@ericsson.com --_000_3049626EAC5C3E43866CD2692A7E19AC1C231980eusaamb103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Here are the sentences where I = would replace Service by Composite Service (or another agreed name) in the = proposed charter:

---

Composite Services are typicall= y implemented by the ordered combination of a number of service functions t= hat may be implemented at different points within the network. Composite Se= rvices delivery is currently both a technical and organisational challenge that involves significant modificat= ion to the network configuration.

For a given Composite Service, = the abstracted view of the required service functions and the order in whic= h they are to be invoked is called a Service Function Chain (SFC). The Serv= ice Function Chaining (SFC) working group will develop new approaches to Composite Service delivery and deploy= ment, by providing a framework for service function chaining and the necess= ary protocols or protocol extensions to convey the service path and for com= munication between nodes that implement service functions. 

---

 

Regards,

Andr=E9 B=E9liveau, Ing.

Tel.: +1 (514) 345 2708

Mobile: +1 (514) 502 9= 592  mailto:andre.beliveau@ericsson.com

 

--_000_3049626EAC5C3E43866CD2692A7E19AC1C231980eusaamb103erics_-- From Ron_Parker@affirmednetworks.com Fri Sep 13 08:26: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 CE76A11E819D for ; Fri, 13 Sep 2013 08:26:10 -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 xeei-Fvl-X-K for ; Fri, 13 Sep 2013 08:26: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 C6B8A11E818E for ; Fri, 13 Sep 2013 08:26:04 -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, 13 Sep 2013 08:26:04 -0700 From: Ron Parker To: Andre Beliveau , "nsc@ietf.org" Thread-Topic: Re: [nsc] New NSC WG Charter Thread-Index: Ac6wlE1Wh6GxIpwbRKirnkegTPG0NwAALkZw Date: Fri, 13 Sep 2013 15:26:03 +0000 Message-ID: References: <3049626EAC5C3E43866CD2692A7E19AC1C231980@eusaamb103.ericsson.se> In-Reply-To: <3049626EAC5C3E43866CD2692A7E19AC1C231980@eusaamb103.ericsson.se> 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_CDF2F015F4429F458815ED2A6C2B6B0B1A6F3805MBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:26:11 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6F3805MBX021W3CA2exch_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andre, That sounds good. However, can we make it clearer that the complete chain may be the concaten= ation of multiple composite services? It may be useful to add this additi= onal layer to the hierarchy such that highest level service offerings (i.e.= , chains) could be described as {composite service A, composite service B} = or {composite service A, composite service C, ...}. Thanks. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Andre= Beliveau Sent: Friday, September 13, 2013 11:18 AM To: nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi, Here are the sentences where I would replace Service by Composite Service (= or another agreed name) in the proposed charter: --- Composite Services are typically implemented by the ordered combination of = a number of service functions that may be implemented at different points w= ithin the network. Composite Services delivery is currently both a technica= l and organisational challenge that involves significant modification to th= e network configuration. For a given Composite Service, the abstracted view of the required service = functions and the order in which they are to be invoked is called a Service= Function Chain (SFC). The Service Function Chaining (SFC) working group wi= ll develop new approaches to Composite Service delivery and deployment, by = providing a framework for service function chaining and the necessary proto= cols or protocol extensions to convey the service path and for communicatio= n between nodes that implement service functions. --- Regards, Andr=E9 B=E9liveau, Ing. Tel.: +1 (514) 345 2708 Mobile: +1 (514) 502 9592 mailto:andre.beliveau@ericsson.com --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6F3805MBX021W3CA2exch_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Andre,

 

That sounds good. = ; 

 

However, can we make i= t clearer that the complete chain may be the concatenation of multiple comp= osite services?   It may be useful to add this additional layer t= o the hierarchy such that highest level service offerings (i.e., chains) could be described as {composite service A, compo= site service B} or {composite service A, composite service C, …}.

 

Thanks.

 

   Ron<= /o:p>

 

 

From: nsc-bounces@ietf.org [mailto:nsc-bounce= s@ietf.org] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 11:18 AM
To: nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi,

 

Here are the sentences where I = would replace Service by Composite Service (or another agreed name) in the = proposed charter:

---

Composite Services are typicall= y implemented by the ordered combination of a number of service functions t= hat may be implemented at different points within the network. Composite Se= rvices delivery is currently both a technical and organisational challenge that involves significant modificat= ion to the network configuration.

For a given Composite Service, = the abstracted view of the required service functions and the order in whic= h they are to be invoked is called a Service Function Chain (SFC). The Serv= ice Function Chaining (SFC) working group will develop new approaches to Composite Service delivery and deploy= ment, by providing a framework for service function chaining and the necess= ary protocols or protocol extensions to convey the service path and for com= munication between nodes that implement service functions. 

---

 

Regards,

Andr=E9 B=E9liveau, Ing.

Tel.: +1 (514) 345 2708

Mobile: +1 (514) 502 9= 592  mailto:andre.beliveau@ericsson.com<= o:p>

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6F3805MBX021W3CA2exch_-- From lucy.yong@huawei.com Fri Sep 13 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 0B84A21F8F24 for ; Fri, 13 Sep 2013 08:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.189, 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 L7hTvH1bftsD for ; Fri, 13 Sep 2013 08:33:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 69EF621E8055 for ; Fri, 13 Sep 2013 08:33:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AXH37278; Fri, 13 Sep 2013 15:33:06 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 16:32:10 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 16:32:25 +0100 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.225]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 08:32:13 -0700 From: Lucy yong To: Andre Beliveau , Ron Parker , "adrian@olddog.co.uk" , Linda Dunbar , "'Jim Guichard (jguichar)'" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQEu6VdITONGxYVPfqNTPZVA4U3NIgGSN51Qmva+qwCAAHcFgIAAAUmA//+NAoA= Date: Fri, 13 Sep 2013 15:32:12 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452C67FF@dfweml509-mbb.china.huawei.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> <3049626EAC5C3E43866CD2692A7E19AC1C2317B0@eusaamb103.ericsson.se> In-Reply-To: <3049626EAC5C3E43866CD2692A7E19AC1C2317B0@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.16] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452C67FFdfweml509mbbchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:33:18 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452C67FFdfweml509mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andre, Who will be a customer for this service? Is service provider self or third = party? If it is the third party, what is the motivation for the third party= to use it? Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Andre= Beliveau Sent: Friday, September 13, 2013 10:08 AM To: Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)= '; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Some suggestion for the new name for "The resulting service that a service = provider can offer to its customers as a result of forming Service Function= Chains" : Delivered Service Network Service (which could be confused with earlier usage of the name) Composite Service Resulting Service My preference goes for Composite Service. /AB From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Ron Parker Sent: September-13-13 11:03 AM To: adrian@olddog.co.uk; 'Linda Dunbar'; 'Jim G= uichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I tend to agree. A service is something that a service provider could des= cribe as an offering to its customers and perhaps charge for it. A good = many of these service offerings are realized by the application of a sequen= ce of one or more service functions in the data plane. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Adrian Farrel Sent: Friday, September 13, 2013 11:00 AM To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of = the proposed work. IMHO, it would be even more clear to replace the "Services" across the char= ter with "Service Functions", like "..Service functions delivery...", to di= fferentiate from the today's connectivity/VPN "services". Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network. Service deliver= y is currently both a technical and organisational challenge that involves = significant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_2691CE0099834E4A9C5044EEC662BB9D452C67FFdfweml509mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andre,

Who will be a customer= for this service? Is service provider self or third party? If it is the th= ird party, what is the motivation for the third party to use it?

Lucy=

 

From: nsc-bounces@ietf.org [mailto:ns= c-bounces@ietf.org] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:08 AM
To: Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jg= uichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Some suggestion for th= e new name for “The resulting service that a service provider can off= er to its customers as a result of forming Service Function Chains” :=

Delivered Service
Network Service (which could be confused with earlier usage of the name) Composite Service
Resulting Service

My preference goes for= Composite Service.

/AB<= /p>

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker
Sent: September-13-13 11:03 AM
To: adrian@olddog.co.uk; = 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

I tend to agree. =   A service is something that a service provider could describe as an = offering to its customers and perhaps charge for it.    A go= od many of these service offerings are realized by the application of a sequence of one or more service functions in the data plane.

   Ron<= /o:p>

 

From: nsc-bounces@ietf.org [mailto:n= sc-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= o:p>

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 

I like = the new name!

“= Service Function Chaining” is much more clear in describing the inten= t of the proposed work.

IMHO, i= t would be even more clear to replace the “Services” across the= charter with “Service Functions”, like “..Service functi= ons delivery...”, to differentiate from the today’s connectivit= y/VPN “services”.

&n= bsp;

Linda

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational = challenge that involves significant modification to the network configurati= on.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):<= /o:p>

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D452C67FFdfweml509mbbchi_-- From andre.beliveau@ericsson.com Fri Sep 13 08:37:36 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30EB11E819D for ; Fri, 13 Sep 2013 08:37:35 -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 waGTU9mXAy58 for ; Fri, 13 Sep 2013 08:37:29 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2111711E8170 for ; Fri, 13 Sep 2013 08:37:29 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-78-52333138b63e Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9B.1E.03458.83133325; Fri, 13 Sep 2013 17:37:28 +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; Fri, 13 Sep 2013 11:37:27 -0400 From: Andre Beliveau To: Ron Parker , "nsc@ietf.org" Thread-Topic: Re: [nsc] New NSC WG Charter Thread-Index: Ac6wlE1Wh6GxIpwbRKirnkegTPG0NwAALkZwAAArxOA= Date: Fri, 13 Sep 2013 15:37:27 +0000 Message-ID: <3049626EAC5C3E43866CD2692A7E19AC1C231C48@eusaamb103.ericsson.se> References: <3049626EAC5C3E43866CD2692A7E19AC1C231980@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_3049626EAC5C3E43866CD2692A7E19AC1C231C48eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyuXRPgq6FoXGQwdmTRhbH9+1ns7jwdCqz A5PHiyvPmD2WLPnJFMAUxWWTkpqTWZZapG+XwJXRdWcJe8Hn8Irlbz+zNjB2+nYxcnBICJhI XPjg3sXICWSKSVy4t56ti5GLQ0jgKKPExU8NzBDOckaJv1cbWECq2ASMJN5fmcQIYosIBEps XtDIDmILC2hKND3cwwQR15JY/+IeG4RtJfG+aSOYzSKgKtG9fyVYPa+Ar8SnHftZQWwhgXmM Eqf/RYHYnALREm2dv5hBbEYBWYkNE7+B7WUWEJe49WQ+E8SlAhJL9pxnhrBFJV4+/scKYStL fJ/zCKo+X2L2zznMELsEJU7OfMIygVFkFpJRs5CUzUJSBhHXk7gxdQobhK0tsWzha2YIW1di xr9DLMjiCxjZVzFylBanluWmGxluYgRGzzEJNscdjAs+WR5ilOZgURLn3aB3JlBIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QDo5FUmD23+MtMhaf9Zs36M1i7a2q/POb/84zT5p7VstoPHUXc 70onqL/31r51U8M12XNuW4FRjPCdQ+WTX1/rPvYy5RqrI3N7j8TMyxGnN76rn1p+4I2Bc1dg TaHBhi3LW52ZE4t5nRZum+i492LAwaPz4oy6pt783am/6f+tq8yM6skRcxh0lViKMxINtZiL ihMB1pHtXmwCAAA= Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:37:36 -0000 --_000_3049626EAC5C3E43866CD2692A7E19AC1C231C48eusaamb103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ron, I would rather embed SF chains within themselves and talk about the "extern= ally visible" service with a unique name. But it is true that if we allow = recursion, we should rather define Service Function Chains as an ordered li= st of Service Functions or existing Service Function Chains. IMHO, I would think that using recursion is more an implementation issue. = If it becomes important for simplification to detail this recursion, we can= do that later when we have sufficient design justification to include it i= n the standard. /AB From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: September-13-13 11:26 AM To: Andre Beliveau; nsc@ietf.org Subject: RE: Re: [nsc] New NSC WG Charter Andre, That sounds good. However, can we make it clearer that the complete chain may be the concaten= ation of multiple composite services? It may be useful to add this additi= onal layer to the hierarchy such that highest level service offerings (i.e.= , chains) could be described as {composite service A, composite service B} = or {composite service A, composite service C, ...}. Thanks. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 11:18 AM To: nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi, Here are the sentences where I would replace Service by Composite Service (= or another agreed name) in the proposed charter: --- Composite Services are typically implemented by the ordered combination of = a number of service functions that may be implemented at different points w= ithin the network. Composite Services delivery is currently both a technica= l and organisational challenge that involves significant modification to th= e network configuration. For a given Composite Service, the abstracted view of the required service = functions and the order in which they are to be invoked is called a Service= Function Chain (SFC). The Service Function Chaining (SFC) working group wi= ll develop new approaches to Composite Service delivery and deployment, by = providing a framework for service function chaining and the necessary proto= cols or protocol extensions to convey the service path and for communicatio= n between nodes that implement service functions. --- Regards, Andr=E9 B=E9liveau, Ing. Tel.: +1 (514) 345 2708 Mobile: +1 (514) 502 9592 mailto:andre.beliveau@ericsson.com --_000_3049626EAC5C3E43866CD2692A7E19AC1C231C48eusaamb103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ron,

I would rather embed S= F chains within themselves and talk about the “externally visibleR= 21; service with a unique name.  But it is true that if we allow recur= sion, we should rather define Service Function Chains as an ordered list of Service Functions or existing Service Function Chain= s.

 

IMHO, I would think th= at using recursion is more an implementation issue.  If it becomes imp= ortant for simplification to detail this recursion, we can do that later wh= en we have sufficient design justification to include it in the standard.

 

/AB<= /p>

 

From: Ron Park= er [mailto:Ron_Parker@affirmednetworks.com]
Sent: September-13-13 11:26 AM
To: Andre Beliveau; nsc@ietf.org
Subject: RE: Re: [nsc] New NSC WG Charter

 

Andre,

 

That sounds good. = ; 

 

However, can we make i= t clearer that the complete chain may be the concatenation of multiple comp= osite services?   It may be useful to add this additional layer t= o the hierarchy such that highest level service offerings (i.e., chains) could be described as {composite service A, compo= site service B} or {composite service A, composite service C, …}.

 

Thanks.

 

   Ron

 

 

From: nsc-bounces@ietf.org [mailto:n= sc-bounces@ietf.org] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 11:18 AM
To: nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi,

 

Here are the sentences where I = would replace Service by Composite Service (or another agreed name) in the = proposed charter:

---

Composite Services are typicall= y implemented by the ordered combination of a number of service functions t= hat may be implemented at different points within the network. Composite Se= rvices delivery is currently both a technical and organisational challenge that involves significant modificat= ion to the network configuration.

For a given Composite Service, = the abstracted view of the required service functions and the order in whic= h they are to be invoked is called a Service Function Chain (SFC). The Serv= ice Function Chaining (SFC) working group will develop new approaches to Composite Service delivery and deploy= ment, by providing a framework for service function chaining and the necess= ary protocols or protocol extensions to convey the service path and for com= munication between nodes that implement service functions. 

---

 

Regards,

Andr=E9 B=E9liveau, Ing.

Tel.: +1 (514) 345 2708

Mobile: +1 (514) 502 9= 592  mailto:andre.beliveau@ericsson.com<= /p>

 

--_000_3049626EAC5C3E43866CD2692A7E19AC1C231C48eusaamb103erics_-- From Ron_Parker@affirmednetworks.com Fri Sep 13 08:40: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 4B28921E80B7 for ; Fri, 13 Sep 2013 08:40:14 -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 3FbAniFIlLmX for ; Fri, 13 Sep 2013 08:39:58 -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 0404F21E8055 for ; Fri, 13 Sep 2013 08:39:34 -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.0123.003; Fri, 13 Sep 2013 08:39:34 -0700 From: Ron Parker To: Andre Beliveau , "nsc@ietf.org" Thread-Topic: Re: [nsc] New NSC WG Charter Thread-Index: Ac6wlE1Wh6GxIpwbRKirnkegTPG0NwAALkZwAAArxOAAAGmwsA== Date: Fri, 13 Sep 2013 15:39:33 +0000 Message-ID: References: <3049626EAC5C3E43866CD2692A7E19AC1C231980@eusaamb103.ericsson.se> <3049626EAC5C3E43866CD2692A7E19AC1C231C48@eusaamb103.ericsson.se> In-Reply-To: <3049626EAC5C3E43866CD2692A7E19AC1C231C48@eusaamb103.ericsson.se> 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_CDF2F015F4429F458815ED2A6C2B6B0B1A6F3842MBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:40:14 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6F3842MBX021W3CA2exch_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We could always say that service chains may be concatenated together. Ron From: Andre Beliveau [mailto:andre.beliveau@ericsson.com] Sent: Friday, September 13, 2013 11:37 AM To: Ron Parker; nsc@ietf.org Subject: RE: Re: [nsc] New NSC WG Charter Ron, I would rather embed SF chains within themselves and talk about the "extern= ally visible" service with a unique name. But it is true that if we allow = recursion, we should rather define Service Function Chains as an ordered li= st of Service Functions or existing Service Function Chains. IMHO, I would think that using recursion is more an implementation issue. = If it becomes important for simplification to detail this recursion, we can= do that later when we have sufficient design justification to include it i= n the standard. /AB From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: September-13-13 11:26 AM To: Andre Beliveau; nsc@ietf.org Subject: RE: Re: [nsc] New NSC WG Charter Andre, That sounds good. However, can we make it clearer that the complete chain may be the concaten= ation of multiple composite services? It may be useful to add this additi= onal layer to the hierarchy such that highest level service offerings (i.e.= , chains) could be described as {composite service A, composite service B} = or {composite service A, composite service C, ...}. Thanks. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 11:18 AM To: nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi, Here are the sentences where I would replace Service by Composite Service (= or another agreed name) in the proposed charter: --- Composite Services are typically implemented by the ordered combination of = a number of service functions that may be implemented at different points w= ithin the network. Composite Services delivery is currently both a technica= l and organisational challenge that involves significant modification to th= e network configuration. For a given Composite Service, the abstracted view of the required service = functions and the order in which they are to be invoked is called a Service= Function Chain (SFC). The Service Function Chaining (SFC) working group wi= ll develop new approaches to Composite Service delivery and deployment, by = providing a framework for service function chaining and the necessary proto= cols or protocol extensions to convey the service path and for communicatio= n between nodes that implement service functions. --- Regards, Andr=E9 B=E9liveau, Ing. Tel.: +1 (514) 345 2708 Mobile: +1 (514) 502 9592 mailto:andre.beliveau@ericsson.com --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6F3842MBX021W3CA2exch_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We could always say th= at service chains may be concatenated together.

 

   Ron<= /o:p>

 

 

From: Andre Beliveau [mailto:andre.beliveau@e= ricsson.com]
Sent: Friday, September 13, 2013 11:37 AM
To: Ron Parker; nsc@ietf.org
Subject: RE: Re: [nsc] New NSC WG Charter

 

Ron,

I would rather embed S= F chains within themselves and talk about the “externally visibleR= 21; service with a unique name.  But it is true that if we allow recur= sion, we should rather define Service Function Chains as an ordered list of Service Functions or existing Service Function Chain= s.

 

IMHO, I would think th= at using recursion is more an implementation issue.  If it becomes imp= ortant for simplification to detail this recursion, we can do that later wh= en we have sufficient design justification to include it in the standard.

 

/AB<= /p>

 

From: Ron Park= er [mailto:Ron_Parker@af= firmednetworks.com]
Sent: September-13-13 11:26 AM
To: Andre Beliveau; nsc@ietf.org=
Subject: RE: Re: [nsc] New NSC WG Charter

 

Andre,

 

That sounds good. = ; 

 

However, can we make i= t clearer that the complete chain may be the concatenation of multiple comp= osite services?   It may be useful to add this additional layer t= o the hierarchy such that highest level service offerings (i.e., chains) could be described as {composite service A, compo= site service B} or {composite service A, composite service C, …}.

 

Thanks.

 

   Ron

 

 

From: nsc-bounces@ietf.org [mailto:n= sc-bounces@ietf.org] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 11:18 AM
To: nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi,

 

Here are the sentences where I = would replace Service by Composite Service (or another agreed name) in the = proposed charter:

---

Composite Services are typicall= y implemented by the ordered combination of a number of service functions t= hat may be implemented at different points within the network. Composite Se= rvices delivery is currently both a technical and organisational challenge that involves significant modificat= ion to the network configuration.

For a given Composite Service, = the abstracted view of the required service functions and the order in whic= h they are to be invoked is called a Service Function Chain (SFC). The Serv= ice Function Chaining (SFC) working group will develop new approaches to Composite Service delivery and deploy= ment, by providing a framework for service function chaining and the necess= ary protocols or protocol extensions to convey the service path and for com= munication between nodes that implement service functions. 

---

 

Regards,

Andr=E9 B=E9liveau, Ing.

Tel.: +1 (514) 345 2708

Mobile: +1 (514) 502 9= 592  mailto:andre.beliveau@ericsson.com<= /p>

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A6F3842MBX021W3CA2exch_-- From linda.dunbar@huawei.com Fri Sep 13 08:43: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 6811121E80CA for ; Fri, 13 Sep 2013 08:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.903 X-Spam-Level: X-Spam-Status: No, score=-5.903 tagged_above=-999 required=5 tests=[AWL=0.695, 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 UrkalANycjbk for ; Fri, 13 Sep 2013 08:43:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 44ABD21F9C46 for ; Fri, 13 Sep 2013 08:43:53 -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.5-GA FastPath queued) with ESMTP id AVJ50404; Fri, 13 Sep 2013 15:43:51 +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.146.0; Fri, 13 Sep 2013 16:43:34 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 16:43:51 +0100 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.225]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 08:43:47 -0700 From: Linda Dunbar To: "adrian@olddog.co.uk" , "'Jim Guichard (jguichar)'" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnDu0AQgAB8ywD//4tIEA== Date: Fri, 13 Sep 2013 15:43:47 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BBCB43@dfweml509-mbb.china.huawei.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> In-Reply-To: <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.99.203.187] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645BBCB43dfweml509mbbchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:43:59 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645BBCB43dfweml509mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian, My interpretation of "Service function Chaining" is about network services = that require a sequence of service functions to be applied to a selective d= ata flows. So it is less about "service delivery", but more about "the mech= anism of applying service functions to data flows". So I would suggest the sentence "The process of service delivery is.." in = the first paragraph to "The process of applying service functions to selective data flows is c= hanging from the physical insertion of equipment on the path into a mechani= sm for causing the path or ..." The wording of the charter: "Services are typically implemented by the orde= red combination of a number of service functions that may be implemented at= different points within the network", gives me the impression that the ch= arter is about chaining a sequence of applications, like chaining WebServer= <->AppServer<->DBserver. If that is the intent of the charter, it is fine= with me. Linda From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, September 13, 2013 10:00 AM To: Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda= Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of = the proposed work. IMHO, it would be even more clear to replace the "Services" across the char= ter with "Service Functions", like "..Service functions delivery...", to di= fferentiate from the today's connectivity/VPN "services". Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network. Service deliver= y is currently both a technical and organisational challenge that involves = significant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_4A95BA014132FF49AE685FAB4B9F17F645BBCB43dfweml509mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Adrian,

My interpretation of &= #8220;Service function Chaining” is about network services that requi= re a sequence of service functions to be applied to a selective data flows.= So it is less about “service delivery”, but more about “the mechanism of applying service functions to data flowsR= 21;.

So I would suggest the= sentence “The process of service delivery is..R= 21;  in the first paragraph to     “The process of applying service function= s to selective data flows is changing from the physical insertion of equipm= ent on the path into a mechanism for causing the path or ...”

 

The wording of the cha= rter: “Services are typically implemented by the ordered com= bination of a number of service functions that may be implemented at different points within the network”,  gives me the impression that the charter= is about chaining a sequence of applications, like chaining WebServer <= ->AppServer<->DBserver.  If that is the intent of the charter, it is fine with me.

Linda

From: Adrian Farrel [mailto:adrian@ol= ddog.co.uk]
Sent: Friday, September 13, 2013 10:00 AM
To: Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

 

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= o:p>

&n= bsp;

From: nsc-bounces@ietf.org [mailto:ns= c-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

I like = the new name!

“= Service Function Chaining” is much more clear in describing the inten= t of the proposed work.

IMHO, i= t would be even more clear to replace the “Services” across the= charter with “Service Functions”, like “..Service functi= ons delivery...”, to differentiate from the today’s connectivit= y/VPN “services”.

&n= bsp;

Linda

&n= bsp;

From: nsc-bounces@ietf.org [mailto:ns= c-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational = challenge that involves significant modification to the network configurati= on.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):<= /o:p>

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645BBCB43dfweml509mbbchi_-- From andre.beliveau@ericsson.com Fri Sep 13 08:44: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 259B521E80A7 for ; Fri, 13 Sep 2013 08:44:38 -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=[AWL=-0.000, 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 P4lGoR+1H83U for ; Fri, 13 Sep 2013 08:44:31 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 099A811E818E for ; Fri, 13 Sep 2013 08:44:30 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-67-523332dd577f Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 91.81.09414.DD233325; Fri, 13 Sep 2013 17:44:29 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Fri, 13 Sep 2013 11:44:17 -0400 From: Andre Beliveau To: Lucy yong , Ron Parker , "adrian@olddog.co.uk" , Linda Dunbar , "'Jim Guichard (jguichar)'" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnDu0AQgABKgACAAAD8gP//vR2QgABK9AD//76bIA== Date: Fri, 13 Sep 2013 15:44:17 +0000 Message-ID: <3049626EAC5C3E43866CD2692A7E19AC1C231D5A@eusaamb103.ericsson.se> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> <3049626EAC5C3E43866CD2692A7E19AC1C2317B0@eusaamb103.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D452C67FF@dfweml509-mbb.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452C67FF@dfweml509-mbb.china.huawei.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.135] Content-Type: multipart/alternative; boundary="_000_3049626EAC5C3E43866CD2692A7E19AC1C231D5Aeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPoO5dI+Mgg11z5Sx+9Nxgtlg6T93i bstEJouNvxaxWRzft5/N4sLTqcwObB4vrjxj9pjyeyOrR8uRt6weS5b8ZPJYsXklYwBrFJdN SmpOZllqkb5dAlfGhhNP2Qqm/mGs2P5sO1MD4847jF2MnBwSAiYS+3afZYWwxSQu3FvP1sXI wSEkcJRR4lAsSFhIYDmjxK+bxiA2m4CRxPsrk4BauThEBP4xSsyfM4EdJCEsoCpxf/90ZhBb REBNouvUAkYIO0xiwdu5LCA2C1DNltYnYDavgK9E99QzLCCDhARWMUv8eb0QrIETqOHB3jls IDajgKzEhonfwBqYBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/9BPaAs8X3OI6j6fInuFzfZIJYJ Spyc+YRlAqPILCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9i5CgtTi3L TTcy2MQIjMJjEmy6Oxj3vLQ8xCjNwaIkzrtK70ygkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6p BkYLbckT55RO8D2ZbXa/RfDiay/OvQH63L72G//+Yjh79kCH8G5uu4AbTDdXnu2tYrogpCZ/ v4/x9h2bh6wyU8oPO3FmZFttbumSPi3vf3UJT3TW4xNHa98J/ZfqmGCg6FvcICuYMiukXWbf 9u3cUx5llfjK7FP028fyKfZbUnm37p90b/Hva5VYijMSDbWYi4oTAaIcpX+QAgAA Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:44:38 -0000 --_000_3049626EAC5C3E43866CD2692A7E19AC1C231D5Aeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lucy, Think of the Composite Service customer as a person or organization which w= ill subscribe or use the Composite Service but does not need to know of the= internals (e.g. what is the order of the services). In other word, this i= s the simple or abstract view of the Service Function Chain as seen from th= e outside world. I can give you a few examples if needed. /AB From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: September-13-13 11:32 AM To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Gui= chard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Andre, Who will be a customer for this service? Is service provider self or third = party? If it is the third party, what is the motivation for the third party= to use it? Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 10:08 AM To: Ron Parker; adrian@olddog.co.uk; Linda Dunb= ar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Some suggestion for the new name for "The resulting service that a service = provider can offer to its customers as a result of forming Service Function= Chains" : Delivered Service Network Service (which could be confused with earlier usage of the name) Composite Service Resulting Service My preference goes for Composite Service. /AB From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Ron Parker Sent: September-13-13 11:03 AM To: adrian@olddog.co.uk; 'Linda Dunbar'; 'Jim G= uichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I tend to agree. A service is something that a service provider could des= cribe as an offering to its customers and perhaps charge for it. A good = many of these service offerings are realized by the application of a sequen= ce of one or more service functions in the data plane. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Adrian Farrel Sent: Friday, September 13, 2013 11:00 AM To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of = the proposed work. IMHO, it would be even more clear to replace the "Services" across the char= ter with "Service Functions", like "..Service functions delivery...", to di= fferentiate from the today's connectivity/VPN "services". Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network. Service deliver= y is currently both a technical and organisational challenge that involves = significant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_3049626EAC5C3E43866CD2692A7E19AC1C231D5Aeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lucy,

Think of the Composite= Service customer as a person or organization which will subscribe or use t= he Composite Service but does not need to know of the internals (e.g. what = is the order of the services).  In other word, this is the simple or abstract view of the Service Function Chain as= seen from the outside world.  I can give you a few examples if needed= .

/AB<= /p>

From: Lucy yong [mailto:lucy.yong@hua= wei.com]
Sent: September-13-13 11:32 AM
To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; '= Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

 

Andre,

Who will be a customer= for this service? Is service provider self or third party? If it is the th= ird party, what is the motivation for the third party to use it?

Lucy=

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:08 AM
To: Ron Parker; adrian@olddog= .co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Some suggestion for th= e new name for “The resulting service that a service provider can off= er to its customers as a result of forming Service Function Chains” :=

Delivered Service
Network Service (which could be confused with earlier usage of the name) Composite Service
Resulting Service

My preference goes for= Composite Service.

/AB<= /p>

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker
Sent: September-13-13 11:03 AM
To: adrian@olddog.co.uk; = 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

I tend to agree. =   A service is something that a service provider could describe as an = offering to its customers and perhaps charge for it.    A go= od many of these service offerings are realized by the application of a sequence of one or more service functions in the data plane.

   Ron<= /o:p>

 

From: nsc-bounces@ietf.org [mailto:n= sc-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= o:p>

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 

I like = the new name!

“= Service Function Chaining” is much more clear in describing the inten= t of the proposed work.

IMHO, i= t would be even more clear to replace the “Services” across the= charter with “Service Functions”, like “..Service functi= ons delivery...”, to differentiate from the today’s connectivit= y/VPN “services”.

&n= bsp;

Linda

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational = challenge that involves significant modification to the network configurati= on.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):<= /o:p>

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_3049626EAC5C3E43866CD2692A7E19AC1C231D5Aeusaamb103erics_-- From andre.beliveau@ericsson.com Fri Sep 13 08:47: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 4102111E8167 for ; Fri, 13 Sep 2013 08:47:46 -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 l2gfdz+B4a39 for ; Fri, 13 Sep 2013 08:47:39 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7190D11E812F for ; Fri, 13 Sep 2013 08:47:39 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-80-5233339ab497 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 28.CE.03458.A9333325; Fri, 13 Sep 2013 17:47:39 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Fri, 13 Sep 2013 11:47:38 -0400 From: Andre Beliveau To: Ron Parker , "nsc@ietf.org" Thread-Topic: Re: [nsc] New NSC WG Charter Thread-Index: Ac6wlE1Wh6GxIpwbRKirnkegTPG0NwAALkZwAAArxOAAAGmwsAAAOw1g Date: Fri, 13 Sep 2013 15:47:37 +0000 Message-ID: <3049626EAC5C3E43866CD2692A7E19AC1C231E47@eusaamb103.ericsson.se> References: <3049626EAC5C3E43866CD2692A7E19AC1C231980@eusaamb103.ericsson.se> <3049626EAC5C3E43866CD2692A7E19AC1C231C48@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_3049626EAC5C3E43866CD2692A7E19AC1C231E47eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyuXSPt+5sY+Mgg5OzuCyO79vPZnHh6VRm ByaPF1eeMXssWfKTKYApissmJTUnsyy1SN8ugSujedEeloLO7Ipfuz+yNTC2xnUxcnJICJhI rGh4yA5hi0lcuLeerYuRi0NI4CijxPmGWcwQznJGiSWrD4NVsQkYSby/MokRxBYRCJTYvKAR LC4soCnR9HAPE0RcS2L9i3tsELabxMKva1hAbBYBVYmd656A2bwCvhINy2eyQyzYzCSx4+g6 VpAEp0C0xP6lO8CGMgrISmyY+A2sgVlAXOLWk/lMEKcKSCzZc54ZwhaVePn4HyuErSzxfc4j qPp8iSXvPrBBLBOUODnzCcsERpFZSEbNQlI2C0kZRFxP4sbUKWwQtrbEsoWvmSFsXYkZ/w6x IIsvYGRfxchRWpxalptuZLiJERhBxyTYHHcwLvhkeYhRmoNFSZx3g96ZQCGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2MHtMbpny7v9DnS+S7RfM3lYbJr846WWGh+vPN7NUZjDvsTE58MM76 zL6hreclc6igzP8H379+0W8Ict3TY709ek/XPgk/J5G978WOcta+kq1/dKw6uOfO4qDqzV9C d745+E0/TFn9+YyLxxsWVfd6zRH4/rpo1/aLlUc/9T12P5FrWhYQ6Sklp8RSnJFoqMVcVJwI AIprLdhuAgAA Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:47:46 -0000 --_000_3049626EAC5C3E43866CD2692A7E19AC1C231E47eusaamb103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree. There are different ways to represent a hierarchy or composition. From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: September-13-13 11:40 AM To: Andre Beliveau; nsc@ietf.org Subject: RE: Re: [nsc] New NSC WG Charter We could always say that service chains may be concatenated together. Ron From: Andre Beliveau [mailto:andre.beliveau@ericsson.com] Sent: Friday, September 13, 2013 11:37 AM To: Ron Parker; nsc@ietf.org Subject: RE: Re: [nsc] New NSC WG Charter Ron, I would rather embed SF chains within themselves and talk about the "extern= ally visible" service with a unique name. But it is true that if we allow = recursion, we should rather define Service Function Chains as an ordered li= st of Service Functions or existing Service Function Chains. IMHO, I would think that using recursion is more an implementation issue. = If it becomes important for simplification to detail this recursion, we can= do that later when we have sufficient design justification to include it i= n the standard. /AB From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: September-13-13 11:26 AM To: Andre Beliveau; nsc@ietf.org Subject: RE: Re: [nsc] New NSC WG Charter Andre, That sounds good. However, can we make it clearer that the complete chain may be the concaten= ation of multiple composite services? It may be useful to add this additi= onal layer to the hierarchy such that highest level service offerings (i.e.= , chains) could be described as {composite service A, composite service B} = or {composite service A, composite service C, ...}. Thanks. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 11:18 AM To: nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi, Here are the sentences where I would replace Service by Composite Service (= or another agreed name) in the proposed charter: --- Composite Services are typically implemented by the ordered combination of = a number of service functions that may be implemented at different points w= ithin the network. Composite Services delivery is currently both a technica= l and organisational challenge that involves significant modification to th= e network configuration. For a given Composite Service, the abstracted view of the required service = functions and the order in which they are to be invoked is called a Service= Function Chain (SFC). The Service Function Chaining (SFC) working group wi= ll develop new approaches to Composite Service delivery and deployment, by = providing a framework for service function chaining and the necessary proto= cols or protocol extensions to convey the service path and for communicatio= n between nodes that implement service functions. --- Regards, Andr=E9 B=E9liveau, Ing. Tel.: +1 (514) 345 2708 Mobile: +1 (514) 502 9592 mailto:andre.beliveau@ericsson.com --_000_3049626EAC5C3E43866CD2692A7E19AC1C231E47eusaamb103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Agree.  There are= different ways to represent a hierarchy or composition.<= /p>

 

From: Ron Park= er [mailto:Ron_Parker@affirmednetworks.com]
Sent: September-13-13 11:40 AM
To: Andre Beliveau; nsc@ietf.org
Subject: RE: Re: [nsc] New NSC WG Charter

 

We could always say th= at service chains may be concatenated together.

 

   Ron

 

 

From: Andre Beliveau [mailto:andre.beliveau@ericsson.com]
Sent: Friday, September 13, 2013 11:37 AM
To: Ron Parker; nsc@ietf.org
Subject: RE: Re: [nsc] New NSC WG Charter

 

Ron,

I would rather embed S= F chains within themselves and talk about the “externally visibleR= 21; service with a unique name.  But it is true that if we allow recur= sion, we should rather define Service Function Chains as an ordered list of Service Functions or existing Service Function Chain= s.

 

IMHO, I would think th= at using recursion is more an implementation issue.  If it becomes imp= ortant for simplification to detail this recursion, we can do that later wh= en we have sufficient design justification to include it in the standard.

 

/AB<= /p>

 

From: Ron Park= er [mailto:Ron_Parker@af= firmednetworks.com]
Sent: September-13-13 11:26 AM
To: Andre Beliveau; nsc@ietf.org=
Subject: RE: Re: [nsc] New NSC WG Charter

 

Andre,

 

That sounds good. = ; 

 

However, can we make i= t clearer that the complete chain may be the concatenation of multiple comp= osite services?   It may be useful to add this additional layer t= o the hierarchy such that highest level service offerings (i.e., chains) could be described as {composite service A, compo= site service B} or {composite service A, composite service C, …}.

 

Thanks.

 

   Ron

 

 

From: nsc-bounces@ietf.org [mailto:n= sc-bounces@ietf.org] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 11:18 AM
To: nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi,

 

Here are the sentences where I = would replace Service by Composite Service (or another agreed name) in the = proposed charter:

---

Composite Services are typicall= y implemented by the ordered combination of a number of service functions t= hat may be implemented at different points within the network. Composite Se= rvices delivery is currently both a technical and organisational challenge that involves significant modificat= ion to the network configuration.

For a given Composite Service, = the abstracted view of the required service functions and the order in whic= h they are to be invoked is called a Service Function Chain (SFC). The Serv= ice Function Chaining (SFC) working group will develop new approaches to Composite Service delivery and deploy= ment, by providing a framework for service function chaining and the necess= ary protocols or protocol extensions to convey the service path and for com= munication between nodes that implement service functions. 

---

 

Regards,

Andr=E9 B=E9liveau, Ing.

Tel.: +1 (514) 345 2708

Mobile: +1 (514) 502 9= 592  mailto:andre.beliveau@ericsson.com<= /p>

 

--_000_3049626EAC5C3E43866CD2692A7E19AC1C231E47eusaamb103erics_-- From lucy.yong@huawei.com Fri Sep 13 08:53:16 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 6B54E21F8756 for ; Fri, 13 Sep 2013 08:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.174, 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 DlEdnEpBDCvC for ; Fri, 13 Sep 2013 08:53:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7D85021E8114 for ; Fri, 13 Sep 2013 08:53:06 -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.5-GA FastPath queued) with ESMTP id AXH38527; Fri, 13 Sep 2013 15:52:58 +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; Fri, 13 Sep 2013 16:52:05 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 16:52:20 +0100 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.225]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 08:52:08 -0700 From: Lucy yong To: Andre Beliveau , Ron Parker , "adrian@olddog.co.uk" , Linda Dunbar , "'Jim Guichard (jguichar)'" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQEu6VdITONGxYVPfqNTPZVA4U3NIgGSN51Qmva+qwCAAHcFgIAAAUmA//+NAoCAAH0ngP//i60A Date: Fri, 13 Sep 2013 15:52:07 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452C6830@dfweml509-mbb.china.huawei.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> <3049626EAC5C3E43866CD2692A7E19AC1C2317B0@eusaamb103.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D452C67FF@dfweml509-mbb.china.huawei.com> <3049626EAC5C3E43866CD2692A7E19AC1C231D5A@eusaamb103.ericsson.se> In-Reply-To: <3049626EAC5C3E43866CD2692A7E19AC1C231D5A@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.16] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452C6830dfweml509mbbchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:53:16 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452C6830dfweml509mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andre, You mean the order of the service functions, right? What this abstract vie= w means to the customer then? Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Andre= Beliveau Sent: Friday, September 13, 2013 10:44 AM To: Lucy yong; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard= (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Lucy, Think of the Composite Service customer as a person or organization which w= ill subscribe or use the Composite Service but does not need to know of the= internals (e.g. what is the order of the services). In other word, this i= s the simple or abstract view of the Service Function Chain as seen from th= e outside world. I can give you a few examples if needed. /AB From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: September-13-13 11:32 AM To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Andre, Who will be a customer for this service? Is service provider self or third = party? If it is the third party, what is the motivation for the third party= to use it? Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 10:08 AM To: Ron Parker; adrian@olddog.co.uk; Linda Dunb= ar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Some suggestion for the new name for "The resulting service that a service = provider can offer to its customers as a result of forming Service Function= Chains" : Delivered Service Network Service (which could be confused with earlier usage of the name) Composite Service Resulting Service My preference goes for Composite Service. /AB From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Ron Parker Sent: September-13-13 11:03 AM To: adrian@olddog.co.uk; 'Linda Dunbar'; 'Jim G= uichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I tend to agree. A service is something that a service provider could des= cribe as an offering to its customers and perhaps charge for it. A good = many of these service offerings are realized by the application of a sequen= ce of one or more service functions in the data plane. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Adrian Farrel Sent: Friday, September 13, 2013 11:00 AM To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of = the proposed work. IMHO, it would be even more clear to replace the "Services" across the char= ter with "Service Functions", like "..Service functions delivery...", to di= fferentiate from the today's connectivity/VPN "services". Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network. Service deliver= y is currently both a technical and organisational challenge that involves = significant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_2691CE0099834E4A9C5044EEC662BB9D452C6830dfweml509mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andre,

You mean the order of = the service functions, right?  What this abstract view means to the cu= stomer then?

Lucy=

 

From: nsc-bounces@ietf.org [mailto:ns= c-bounces@ietf.org] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:44 AM
To: Lucy yong; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim G= uichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Lucy,

Think of the Composite= Service customer as a person or organization which will subscribe or use t= he Composite Service but does not need to know of the internals (e.g. what = is the order of the services).  In other word, this is the simple or abstract view of the Service Function Chain as= seen from the outside world.  I can give you a few examples if needed= .

/AB<= /p>

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: September-13-13 11:32 AM
To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

 

Andre,

Who will be a customer= for this service? Is service provider self or third party? If it is the th= ird party, what is the motivation for the third party to use it?

Lucy=

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:08 AM
To: Ron Parker; adrian@olddog= .co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Some suggestion for th= e new name for “The resulting service that a service provider can off= er to its customers as a result of forming Service Function Chains” :=

Delivered Service
Network Service (which could be confused with earlier usage of the name) Composite Service
Resulting Service

My preference goes for= Composite Service.

/AB<= /p>

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker
Sent: September-13-13 11:03 AM
To: adrian@olddog.co.uk; = 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

I tend to agree. =   A service is something that a service provider could describe as an = offering to its customers and perhaps charge for it.    A go= od many of these service offerings are realized by the application of a sequence of one or more service functions in the data plane.

   Ron<= /o:p>

 

From: nsc-bounces@ietf.org [mailto:n= sc-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= o:p>

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 

I like = the new name!

“= Service Function Chaining” is much more clear in describing the inten= t of the proposed work.

IMHO, i= t would be even more clear to replace the “Services” across the= charter with “Service Functions”, like “..Service functi= ons delivery...”, to differentiate from the today’s connectivit= y/VPN “services”.

&n= bsp;

Linda

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational = challenge that involves significant modification to the network configurati= on.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):<= /o:p>

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D452C6830dfweml509mbbchi_-- From jguichar@cisco.com Fri Sep 13 08:58: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 C589A21F9BFF for ; Fri, 13 Sep 2013 08:58:44 -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=[AWL=-0.000, 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 JxqVIvsXkgcl for ; Fri, 13 Sep 2013 08:58: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 A09F021F9E04 for ; Fri, 13 Sep 2013 08:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37540; q=dns/txt; s=iport; t=1379087915; x=1380297515; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=LglPn18gB2YzhIslW9wcuhbl00j3h8nmq7Ttb3JYGFU=; b=HlA7yzDelFQg3LjxAnQFO33aU7yBwVmNhErXNhESCGVyBBAu9hkleaXF ycckODVPoNbDoK0iz0QxaMtpBu+vHi7D18Z/xZRdBmlEsiFVTy6wWA8Qc T1cy3QnFzzezgU13UpnMnT0xFjMCoBkYrl366oRt6Omi5ayUN2cwg6UvM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAJg1M1KtJV2Z/2dsb2JhbABbgkNEOFLAdIEbFnSCJQEBAQQtOgsZAQgRAQIBAQELAhQBBjkUAwYIAgQBEggMh2+6II4oFoECDRMXAQKDHIEAA5NdQZVQgySBaQgXIg X-IronPort-AV: E=Sophos;i="4.90,899,1371081600"; d="scan'208,217";a="259407558" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 13 Sep 2013 15:58:33 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8DFwX8u012954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 15:58:33 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 13 Sep 2013 10:58:33 -0500 From: "Jim Guichard (jguichar)" To: Lucy yong , Andre Beliveau , Ron Parker , "adrian@olddog.co.uk" , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnDu0AQgABbRACAAAD7gIAAAUmAgAAGyQCAAANggIAAAjGA//++ugA= Date: Fri, 13 Sep 2013 15:58:32 +0000 Message-ID: <68B171751455884590F8E38E96416F363F68E06F@xmb-rcd-x01.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452C6830@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.86.254.92] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F68E06Fxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] New NSC 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, 13 Sep 2013 15:58:44 -0000 --_000_68B171751455884590F8E38E96416F363F68E06Fxmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Are we really having this discussion again? From where I am sitting Andre's= email is very clear =96 a composite service is something constructed from = one or more service functions and a consumer of said service has no knowled= ge (or frankly concern) of what particular service functions are used in it= s construction. Please let's not overcomplicate this!! From: Lucy yong > Date: Friday, September 13, 2013 11:52 AM To: Andre Beliveau >, Ron Parker >, "adrian@olddog.co.uk" >, Linda Dunbar >, Microsoft Office User >, "nsc@ietf.org= " > Subject: RE: [nsc] New NSC WG Charter Andre, You mean the order of the service functions, right? What this abstract vie= w means to the customer then? Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 10:44 AM To: Lucy yong; Ron Parker; adrian@olddog.co.uk;= Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Lucy, Think of the Composite Service customer as a person or organization which w= ill subscribe or use the Composite Service but does not need to know of the= internals (e.g. what is the order of the services). In other word, this i= s the simple or abstract view of the Service Function Chain as seen from th= e outside world. I can give you a few examples if needed. /AB From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: September-13-13 11:32 AM To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Andre, Who will be a customer for this service? Is service provider self or third = party? If it is the third party, what is the motivation for the third party= to use it? Lucy From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 10:08 AM To: Ron Parker; adrian@olddog.co.uk; Linda Dunb= ar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Some suggestion for the new name for =93The resulting service that a servic= e provider can offer to its customers as a result of forming Service Functi= on Chains=94 : Delivered Service Network Service (which could be confused with earlier usage of the name) Composite Service Resulting Service My preference goes for Composite Service. /AB From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Ron Parker Sent: September-13-13 11:03 AM To: adrian@olddog.co.uk; 'Linda Dunbar'; 'Jim G= uichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I tend to agree. A service is something that a service provider could des= cribe as an offering to its customers and perhaps charge for it. A good = many of these service offerings are realized by the application of a sequen= ce of one or more service functions in the data plane. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Adrian Farrel Sent: Friday, September 13, 2013 11:00 AM To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! =93Service Function Chaining=94 is much more clear in describing the intent= of the proposed work. IMHO, it would be even more clear to replace the =93Services=94 across the = charter with =93Service Functions=94, like =93..Service functions delivery.= ..=94, to differentiate from the today=92s connectivity/VPN =93services=94. Linda From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network.Service delivery= is currently both a technical and organisational challenge that involves s= ignificant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_68B171751455884590F8E38E96416F363F68E06Fxmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <211727CF861DC446AA727ADC17CC019E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Are we really having this discussion again? From where I am sitting An= dre's email is very clear =96 a composite = service is something constructed from one or more service functions and a c= onsumer of said service has no knowledge (or frankly concern) of what parti= cular service functions are used in its construction. Please let's not overcomplicate this!!

From: Lucy yong <lucy.yong@huawei.com>
Date: Friday, September 13, 2013 11= :52 AM
To: Andre Beliveau <andre.beliveau@ericsson.com>, Ron= Parker <Ron_Parker@a= ffirmednetworks.com>, "a= drian@olddog.co.uk" <adrian@olddog.co.uk>, Li= nda Dunbar <linda.dunbar@huaw= ei.com>, Microsoft Office User <jguichar@cisco.com>, "nsc@= ietf.org" <nsc@ietf.org>
Subject: RE: [nsc] New NSC WG Chart= er

Andre,

You mean the order of = the service functions, right?  What this abstract view means to the cu= stomer then?

Lucy=

 

From:= nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:44 AM
To: Lucy yong; Ron Parker; ad= rian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Lucy,

Think of the Composite= Service customer as a person or organization which will subscribe or use t= he Composite Service but does not need to know of the internals (e.g. what = is the order of the services).  In other word, this is the simple or abstract view of the Service Function Chain as= seen from the outside world.  I can give you a few examples if needed= .

/AB<= /p>

From:= mailto:lucy.yong@hua= wei.com]
Sent: September-13-13 11:32 AM
To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

 

Andre,

Who will be a customer= for this service? Is service provider self or third party? If it is the th= ird party, what is the motivation for the third party to use it?

Lucy=

 

From:= nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:08 AM
To: Ron Parker; adrian@olddog= .co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Some suggestion for th= e new name for =93The resulting service that a service provider can offer t= o its customers as a result of forming Service Function Chains=94 :

Delivered Service
Network Service (which could be confused with earlier usage of the name) Composite Service
Resulting Service

My preference goes for= Composite Service.

/AB<= /p>

From:= nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker
Sent: September-13-13 11:03 AM
To: adrian@olddog.co.uk; = 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

I tend to agree. =   A service is something that a service provider could describe as an = offering to its customers and perhaps charge for it.    A go= od many of these service offerings are realized by the application of a sequence of one or more service functions in the data plane.

   Ron<= /o:p>

 

From: nsc-bounces@ietf.org [mailto:n= sc-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= o:p>

&n= bsp;

From:= nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 

I like = the new name!

=93Serv= ice Function Chaining=94 is much more clear in describing the intent of the= proposed work.

IMHO, i= t would be even more clear to replace the =93Services=94 across the charter= with =93Service Functions=94, like =93..Service functions delivery...=94, = to differentiate from the today=92s connectivity/VPN =93services=94.

&n= bsp;

Linda

&n= bsp;

From:= nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge that i= nvolves significant modification to the network configuration.=

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):<= /o:p>

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

 --_000_68B171751455884590F8E38E96416F363F68E06Fxmbrcdx01ciscoc_-- From adrian@olddog.co.uk Fri Sep 13 09:08:20 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AEA21F96CA for ; Fri, 13 Sep 2013 09:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.077, 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 NdFbxuHfSBRA for ; Fri, 13 Sep 2013 09:08:14 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 1155111E8167 for ; Fri, 13 Sep 2013 09:08:12 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8DG88aM010926; Fri, 13 Sep 2013 17:08:08 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8DG86Of010908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Sep 2013 17:08:07 +0100 From: "Adrian Farrel" To: "'Jim Guichard \(jguichar\)'" , References: <2691CE0099834E4A9C5044EEC662BB9D452C6830@dfweml509-mbb.china.huawei.com> <68B171751455884590F8E38E96416F363F68E06F@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F68E06F@xmb-rcd-x01.cisco.com> Date: Fri, 13 Sep 2013 17:08:08 +0100 Message-ID: <028f01ceb09b$705ee610$511cb230$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0290_01CEB0A3.D227E1F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbC552nD0HCPpjG3YvpU1l3PcJvpmrHwHg Content-Language: en-gb Subject: Re: [nsc] New NSC WG Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:08:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0290_01CEB0A3.D227E1F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Well, I agree :-) But I would observe that a "composite service" as defined here is a composition of one or more service functions. How is that difference from a "service"? Simplicity seems to say don't use additional words if they aren't needed. A From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: 13 September 2013 16:59 To: Lucy yong; Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Are we really having this discussion again? From where I am sitting Andre's email is very clear - a composite service is something constructed from one or more service functions and a consumer of said service has no knowledge (or frankly concern) of what particular service functions are used in its construction. Please let's not overcomplicate this!! From: Lucy yong Date: Friday, September 13, 2013 11:52 AM To: Andre Beliveau , Ron Parker , "adrian@olddog.co.uk" , Linda Dunbar , Microsoft Office User , "nsc@ietf.org" Subject: RE: [nsc] New NSC WG Charter Andre, You mean the order of the service functions, right? What this abstract view means to the customer then? Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 10:44 AM To: Lucy yong; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Lucy, Think of the Composite Service customer as a person or organization which will subscribe or use the Composite Service but does not need to know of the internals (e.g. what is the order of the services). In other word, this is the simple or abstract view of the Service Function Chain as seen from the outside world. I can give you a few examples if needed. /AB From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: September-13-13 11:32 AM To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Andre, Who will be a customer for this service? Is service provider self or third party? If it is the third party, what is the motivation for the third party to use it? Lucy From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 10:08 AM To: Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Some suggestion for the new name for "The resulting service that a service provider can offer to its customers as a result of forming Service Function Chains" : Delivered Service Network Service (which could be confused with earlier usage of the name) Composite Service Resulting Service My preference goes for Composite Service. /AB From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: September-13-13 11:03 AM To: adrian@olddog.co.uk; 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I tend to agree. A service is something that a service provider could describe as an offering to its customers and perhaps charge for it. A good many of these service offerings are realized by the application of a sequence of one or more service functions in the data plane. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, September 13, 2013 11:00 AM To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we mean service function. IMHO, service functions are not delivered. Service functions are executed to deliver services. Perhaps rather than a global search and replace, you could suggest specific instances to be replaced? Thanks, Adrian From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of the proposed work. IMHO, it would be even more clear to replace the "Services" across the charter with "Service Functions", like "..Service functions delivery...", to differentiate from the today's connectivity/VPN "services". Linda From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel Halpern over the last few days to refine the NSC WG charter. The following is our proposal to the community for review and comment. Please note that as an outcome of the various discussions on the list we are proposing that the WG name change from "Network Service Chaining (NSC)" to "Service Function Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergone significant change in recent years with the introduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the physical insertion of equipment on the path into a mechanism for causing the path or data to transit specific physical or virtual nodes on which the service functions are performed. Services are typically implemented by the ordered combination of a number of service functions that may be implemented at different points within the network.Service delivery is currently both a technical and organisational challenge that involves significant modification to the network configuration. For a given service, the abstracted view of the required service functions and the order in which they are to be invoked is called a Service Function Chain (SFC). Since a given service function may be available on more than one node within a network, a ServiceFunction Chain is instantiated via the selection of specific service function instances and the network nodes on which they are provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be applied at a specific layer within the network protocol stack (network layer, application layer, etc.). The Service Function Chaining (SFC) working group will develop new approaches to service delivery and deployment, 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. The working group will also examine what information needs to be gathered from the network and service functions in support of service function chaining and how that information may be made available to nodes that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high-level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining. 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level encapsulation protocol for conveying the service function chain and the service function path, and for communicating information between nodes that implement service functions. It is intended that the encapsulation be agnostic to thenetwork layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realised at the network layer or at any other layer, and the same encapsulation willapply for the construction of service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service function chaining includingrelevant MIBs and YANG data modules, and service function chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the architecture for SFC and describing the framework and requirements for a generic service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying the generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying control plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents defining how the protocol elements developed by the WG may be combined with other IETF protocols to satisfy the use cases. ------=_NextPart_000_0290_01CEB0A3.D227E1F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, I agree = :-)

But I would observe = that a "composite service" as defined here is a composition of = one or more service functions.

How is that difference = from a "service"?

Simplicity seems to = say don't use additional words if they aren't = needed.

A

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f= ont-family:"Times New = Roman";mso-ansi-language:EN-US'>From: Jim Guichard = (jguichar) [mailto:jguichar@cisco.com]
Sent: 13 September = 2013 16:59
To: Lucy yong; Andre Beliveau; Ron Parker; = adrian@olddog.co.uk; Linda Dunbar; nsc@ietf.org
Subject: Re: = [nsc] New NSC WG Charter

 

Are we really having this discussion again? = >From where I am sitting Andre's email is very clear – = a composite service is something constructed from one or more service = functions and a consumer of said service has no knowledge (or frankly = concern) of what particular service functions are used in its = construction. Please let's not overcomplicate = this!!

 

From: = Lucy yong <lucy.yong@huawei.com>
D= ate: Friday, September 13, 2013 11:52 AM
To: Andre = Beliveau <andre.beliveau@ericsson.com>, Ron Parker <Ron_Parker@affirmednetwor= ks.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Linda = Dunbar <linda.dunbar@huawei.com>, = Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: = [nsc] New NSC WG Charter

 

Andre,

You mean the order of = the service functions, right?  What this abstract view means to the = customer then?

Lucy

 

=

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black;m= so-ansi-language:EN-US'>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Andre Beliveau
Sent: Friday, September 13, = 2013 10:44 AM
To: Lucy yong; Ron Parker; adrian@olddog.co.uk; Linda = Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: = [nsc] New NSC WG Charter

 

Hi Lucy,

Think of the Composite = Service customer as a person or organization which will subscribe or use = the Composite Service but does not need to know of the internals (e.g. = what is the order of the services).  In other word, this is the = simple or abstract view of the Service Function Chain as seen from the = outside world.  I can give you a few examples if = needed.

/AB

=

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black;m= so-ansi-language:EN-US'>From: Lucy yong [mailto:lucy.yong@huawei.com] =
Sent: September-13-13 11:32 AM
To: Andre Beliveau; = Ron Parker; adrian@olddog.co.uk; Linda = Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: = [nsc] New NSC WG Charter

 

Andre,

Who will be a customer = for this service? Is service provider self or third party? If it is the = third party, what is the motivation for the third party to use it? =

Lucy

 

=

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black;m= so-ansi-language:EN-US'>From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Andre Beliveau
Sent: Friday, September 13, = 2013 10:08 AM
To: Ron Parker; adrian@olddog.co.uk; Linda = Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: = [nsc] New NSC WG Charter

 

Some suggestion for the = new name for “The resulting service that a service provider can = offer to its customers as a result of forming Service Function = Chains” :

Delivered = Service
Network Service (which could be confused with earlier usage = of the name)
Composite Service
Resulting Service

My preference goes for = Composite Service.

/AB

=

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black;m= so-ansi-language:EN-US'>From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Ron Parker
Sent: September-13-13 11:03 = AM
To: adrian@olddog.co.uk; 'Linda = Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: = [nsc] New NSC WG Charter

 

I tend to = agree.   A service is something that a service provider could = describe as an offering to its customers and perhaps charge for = it.    A good many of these service offerings are = realized by the application of a sequence of one or more service = functions in the data plane.

   = Ron

=

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Adrian Farrel
Sent: Friday, September 13, = 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; = nsc@ietf.org
Subject: Re: = [nsc] New NSC WG Charter

 

Hi = Linda,

I think it is important = to be very clear when we mean service and when we mean service = function.

IMHO, service functions = are not delivered. Service functions are executed to deliver = services.

Perhaps rather than a = global search and replace, you could suggest specific instances to be = replaced?

Thanks,

Adrian

 

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black;m= so-ansi-language:EN-US'>From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Linda Dunbar
Sent: 13 September 2013 = 15:42
To: Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: = [nsc] New NSC WG Charter

 

I like the new name! =

“Service Function = Chaining” is much more clear in describing the intent of the = proposed work.

IMHO, it would be even = more clear to replace the “Services” across the charter with = “Service Functions”, like “..Service functions = delivery...”, to differentiate from the today’s = connectivity/VPN “services”.

 

Linda

 

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black;m= so-ansi-language:EN-US'>From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Jim Guichard (jguichar)
Sent: Friday, = September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] = New NSC WG Charter
Importance: High

 

=

Greetings,<= /span>

 

We have = been working with the routing area AD's and our IAB shepherd Joel = Halpern over the last few days to refine the NSC WG charter. The = following is our proposal to the community for review and comment. = Please note that as an outcome of the various discussions on the list we = are proposing that the WG name change from "Network Service = Chaining (NSC)" to "Service Function Chaining = (SFC)". 

 

<= u>Proposed = Service Function Chaining (SFC) WG Charter

 

Networks, = servers, storage technologies, and applications, have all undergone = significant change in recent years with the introduction of = virtualization, network overlays, and orchestration. The process of = service delivery is changing from the physical insertion of equipment on = the path into a mechanism for causing the path or data to transit = specific physical or virtual nodes on which the service functions are = performed. Services are typically implemented by the ordered combination = of a number of service functions that may be implemented at different = points within the network.Service delivery is currently both a technical = and organisational challenge that involves significant modification to = the network configuration.

For a given = service, the abstracted view of the required service functions and the = order in which they are to be invoked is called a Service Function Chain = (SFC). Since a given service function may be available on more than one = node within a network, a ServiceFunction Chain is instantiated via the = selection of specific service function instances and the network nodes = on which they are provided, thereby forming a servicetopology: this is = called a Service Function Path. The service functions may be applied at = a specific layer within the network protocol stack (network layer, = application layer, etc.).

The Service = Function Chaining (SFC) working group will develop new approaches to = service delivery and deployment, 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.  The working group will also examine = what information needs to be gathered from the network and service = functions in support of service function chaining and how that = information may be made available to nodes that implement the service = functions.

Specifically, = the SFC WG is chartered to deliver the following: 

1) Problem = Statement: This document will provide a summary of the problem space to = be addressed by the WG including example high-level use cases. =  Additionally, the WG will normalize nomenclature and definitions = for service function chaining.

2) Architecture: = This document will provide a description of the architectural building = blocks and their relationships including interconnection, placement of = capabilities, management, diagnostics, and security models, as well as = requirements on the protocol mechanisms.

3) Generic = Service Function Chaining Encapsulation: A document will describe the = single service-level encapsulation protocol for conveying the service = function chain and the service function path, and for communicating = information between nodes that implement service functions. It is = intended that the encapsulation be agnostic to thenetwork layer at which = it is applied and the service that is being constructed. That is, the = same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation = willapply for the construction of service function paths regardless of = the actual service.

4) Control Plane = Mechanisms: A set of documents will be developed to describe = requirements and protocols necessary to convey information to service = function implementation points. Where possible, existing IETF protocols = will be used and extended. All protocol = extensions work should be carried out in the working groups responsible = for the protocols being modified in coordination with this working = group, but may be done in this working group after agreement with all = the relevant WG chairs and responsible ADs.

5) = Manageability: This document will address the management of service = function chaining includingrelevant MIBs and YANG data modules, and = service function chaining diagnostics.

Proposed = Milestones (all dates TBD):

Request the IESG = for publication of an Informational document defining the problem = statement and core use cases for Service Function Chaining

Request the IESG = for publication of Informational documents defining the architecture for = SFC and describing the framework and requirements for a generic service = function chaining encapsulation protocol.

Request the IESG = for publication of a Standards Track document specifying the generic = service function chaining encapsulation protocol.

Request the IESG = for publication of Informational documents specifying control plane = requirements in support of specific SFC use cases.

Request the IESG = for publication of an Informational document defining SFC manageability = including diagnostics, and MIB and YANG data models to = IESG 

Request the IESG = for publication of Informational applicability documents defining how = the protocol elements developed by the WG may be combined with other = IETF protocols to satisfy the use cases.

 

 

------=_NextPart_000_0290_01CEB0A3.D227E1F0-- From andre.beliveau@ericsson.com Fri Sep 13 09:08: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 DC2F921F9D9A for ; Fri, 13 Sep 2013 09:08:38 -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 e0MXav7IoX2i for ; Fri, 13 Sep 2013 09:08:32 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6A58221F9DA0 for ; Fri, 13 Sep 2013 09:08:31 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-ec-5233387e0844 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 31.30.03458.E7833325; Fri, 13 Sep 2013 18:08:30 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Fri, 13 Sep 2013 12:08:27 -0400 From: Andre Beliveau To: "Jim Guichard (jguichar)" , Lucy yong , Ron Parker , "adrian@olddog.co.uk" , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnDu0AQgABKgACAAAD8gP//vR2QgABK9AD//76bIIAARvaAgAABywD//7744A== Date: Fri, 13 Sep 2013 16:08:27 +0000 Message-ID: <3049626EAC5C3E43866CD2692A7E19AC1C232107@eusaamb103.ericsson.se> References: <2691CE0099834E4A9C5044EEC662BB9D452C6830@dfweml509-mbb.china.huawei.com> <68B171751455884590F8E38E96416F363F68E06F@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F68E06F@xmb-rcd-x01.cisco.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.135] Content-Type: multipart/alternative; boundary="_000_3049626EAC5C3E43866CD2692A7E19AC1C232107eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLrHT7fOwjjIYP5VHYsfPTeYLZbOU7e4 2zKRyWLjr0VsFsf37WezuPB0KrMDm8eLK8+YPab83sjq0XLkLavHkiU/mTxWbF7JGMAaxWWT kpqTWZZapG+XwJWxf90RxoKXO5kqPmw5xtrA2D2FqYuRk0NCwETi8/dWRghbTOLCvfVsXYxc HEICRxklel4cZodwljNKzD0wnQ2kik3ASOL9lUmMIAkRgT+MEnPevGQHSQgLqErc3z+dGcQW EVCT6Dq1gBHCzpJY82QDC4jNAlTz8+JssEG8Ar4Sfx+uYYbYMINR4uG8w2CDOIESDzYdARvE KCArsWHiN7BmZgFxiVtP5kPdLSCxZM95ZghbVOLl43+sELayxPc5j6Dq8yUe7j/GBLFMUOLk zCcsExhFZiEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqR 4SZGYCwek2Bz3MG44JPlIUZpDhYlcd4NemcChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDq d1YluOx5cGn9o4YTmd9vrtzm16CxfNYJse32J6RjPlbbsAiqmYU/Fepj2nlv6dLKR5/X7gt5 ElC15NzJynlrVr7cvVZjzaay9RX7xObYN05Z75eUHzFriefuBscT2oduuc16YBaZeH/lwfj2 gHcqW+xbnsa2yhVqfPcO5F2jYclW5KYkfeCzEktxRqKhFnNRcSIAytuyG5MCAAA= Subject: Re: [nsc] New NSC 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, 13 Sep 2013 16:08:39 -0000 --_000_3049626EAC5C3E43866CD2692A7E19AC1C232107eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Right. The IETF 87 BoF presentations gave a few examples from different pr= oviders of what those Composite Services are. Those can be used as exampl= es. /AB From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: September-13-13 11:59 AM To: Lucy yong; Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunba= r; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Are we really having this discussion again? From where I am sitting Andre's= email is very clear - a composite service is something constructed from on= e or more service functions and a consumer of said service has no knowledge= (or frankly concern) of what particular service functions are used in its = construction. Please let's not overcomplicate this!! From: Lucy yong > Date: Friday, September 13, 2013 11:52 AM To: Andre Beliveau >, Ron Parker >, "adrian@olddog.co.uk" >, Linda Dunbar >, Microsoft Office User >, "nsc@ietf.org= " > Subject: RE: [nsc] New NSC WG Charter Andre, You mean the order of the service functions, right? What this abstract vie= w means to the customer then? Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 10:44 AM To: Lucy yong; Ron Parker; adrian@olddog.co.uk;= Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Lucy, Think of the Composite Service customer as a person or organization which w= ill subscribe or use the Composite Service but does not need to know of the= internals (e.g. what is the order of the services). In other word, this i= s the simple or abstract view of the Service Function Chain as seen from th= e outside world. I can give you a few examples if needed. /AB From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: September-13-13 11:32 AM To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Andre, Who will be a customer for this service? Is service provider self or third = party? If it is the third party, what is the motivation for the third party= to use it? Lucy From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 10:08 AM To: Ron Parker; adrian@olddog.co.uk; Linda Dunb= ar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Some suggestion for the new name for "The resulting service that a service = provider can offer to its customers as a result of forming Service Function= Chains" : Delivered Service Network Service (which could be confused with earlier usage of the name) Composite Service Resulting Service My preference goes for Composite Service. /AB From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Ron Parker Sent: September-13-13 11:03 AM To: adrian@olddog.co.uk; 'Linda Dunbar'; 'Jim G= uichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I tend to agree. A service is something that a service provider could des= cribe as an offering to its customers and perhaps charge for it. A good = many of these service offerings are realized by the application of a sequen= ce of one or more service functions in the data plane. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Adrian Farrel Sent: Friday, September 13, 2013 11:00 AM To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of = the proposed work. IMHO, it would be even more clear to replace the "Services" across the char= ter with "Service Functions", like "..Service functions delivery...", to di= fferentiate from the today's connectivity/VPN "services". Linda From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network.Service delivery= is currently both a technical and organisational challenge that involves s= ignificant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_3049626EAC5C3E43866CD2692A7E19AC1C232107eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Right.  The IETF = 87 BoF presentations gave a few examples from different providers of what t= hose Composite Services are.   Those can be used as examples.

/AB<= /p>

From: Jim Guichard (jguichar) [mailto= :jguichar@cisco.com]
Sent: September-13-13 11:59 AM
To: Lucy yong; Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Lind= a Dunbar; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Are we really having this discussion again? From where I am sitti= ng Andre's email is very clear – a composite service is something constructed= from one or more service functions and a consumer of said service has no k= nowledge (or frankly concern) of what particular service functions are used= in its construction. Please let's not overcomplicate this!!

 

From: Lucy yong <lucy.yong@huawei.com>
Date: Friday, September 13, 2013 11:52 AM
To: Andre Beliveau <andre.beliveau@ericsson.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, &quo= t;adrian@olddog.co.uk" <adrian@olddog.co.uk>, Li= nda Dunbar <linda.dunbar@huaw= ei.com>, Microsoft Office User <jguichar@cisco.com>, "nsc@= ietf.org" <nsc@ietf.org>
Subject: RE: [nsc] New NSC WG Charter

 

Andre,

You mean the order of = the service functions, right?  What this abstract view means to the cu= stomer then?

Lucy

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:44 AM
To: Lucy yong; Ron Parker; ad= rian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 =

Hi Lucy,

Think of the Composite= Service customer as a person or organization which will subscribe or use t= he Composite Service but does not need to know of the internals (e.g. what = is the order of the services).  In other word, this is the simple or abstract view of the Service Function Chain as= seen from the outside world.  I can give you a few examples if needed= .

/AB

From: Lucy yo= ng [mailto:lucy.yong@huawei.com= ]
Sent: September-13-13 11:32 AM
To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

 =

Andre,

Who will be a customer= for this service? Is service provider self or third party? If it is the th= ird party, what is the motivation for the third party to use it?

Lucy

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:08 AM
To: Ron Parker; adrian@olddog= .co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 =

Some suggestion for th= e new name for “The resulting service that a service provider can off= er to its customers as a result of forming Service Function Chains” :=

Delivered Service
Network Service (which could be confused with earlier usage of the name) Composite Service
Resulting Service

My preference goes for= Composite Service.

/AB

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker
Sent: September-13-13 11:03 AM
To: adrian@olddog.co.uk; = 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 =

I tend to agree. =   A service is something that a service provider could describe as an = offering to its customers and perhaps charge for it.    A go= od many of these service offerings are realized by the application of a sequence of one or more service functions in the data plane.

   Ron

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 =

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= /span>

 <= /span>

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 

I like = the new name!

“= Service Function Chaining” is much more clear in describing the inten= t of the proposed work.

IMHO, i= t would be even more clear to replace the “Services” across the= charter with “Service Functions”, like “..Service functi= ons delivery...”, to differentiate from the today’s connectivit= y/VPN “services”.

 <= /span>

Linda

 <= /span>

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter<= /o:p>

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge= that involves significant modification to the network configuration.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG =

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_3049626EAC5C3E43866CD2692A7E19AC1C232107eusaamb103erics_-- From jguichar@cisco.com Fri Sep 13 09:11: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 5B3E421F9A43 for ; Fri, 13 Sep 2013 09:11:06 -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=[AWL=-0.000, 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 hsBCJs2Mwtev for ; Fri, 13 Sep 2013 09:11:00 -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 1743321F9D92 for ; Fri, 13 Sep 2013 09:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=68351; q=dns/txt; s=iport; t=1379088660; x=1380298260; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=W/w5fbPocQJovv9R6tDIS/4gBP4wh0hie3B92IrcoBg=; b=MzUWcaTfV/hemJhnw+ZUQE/JS0s9CCBQrEqLri9tZ/dScHeyIQXIfsKJ XFA//e1StU+3x26vxo0Ke5XLT6ycW8PoMbUd+LR7uwrjPuFmOLD4FwBkA pwFX7d3gKVRN2aNfoArsYxjfhVYWwC5570klBsTgsQRNBWBSDIKWmUGkQ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFALU3M1KtJV2Y/2dsb2JhbABbgkNEOFLAdIEbFnSCJQEBAQQaEzoLGQEIEQECAQEBCwIUAQYtDBQDBggCBAERAQgMh2+6BY4oFoECDRMXAQKDHIEAA5NdQZVQgySBaQgXIg X-IronPort-AV: E=Sophos;i="4.90,899,1371081600"; d="scan'208,217";a="256414564" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 13 Sep 2013 16:10:59 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8DGAwgA002702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 16:10:58 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 13 Sep 2013 11:10:58 -0500 From: "Jim Guichard (jguichar)" To: "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnDu0AQgABbRACAAAD7gIAAAUmAgAAGyQCAAANggIAAAjGA//++ugCAAEW/AP//vbmA Date: Fri, 13 Sep 2013 16:10:58 +0000 Message-ID: <68B171751455884590F8E38E96416F363F68E0E3@xmb-rcd-x01.cisco.com> In-Reply-To: <028f01ceb09b$705ee610$511cb230$@olddog.co.uk> 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.86.254.92] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F68E0E3xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] New NSC 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, 13 Sep 2013 16:11:06 -0000 --_000_68B171751455884590F8E38E96416F363F68E0E3xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I would argue Adrian that a "composite service" is no different to a "servi= ce" as regardless of how a service is constructed, said construction is tra= nsparent to the consumer of that service. From: Adrian Farrel > Reply-To: "adrian@olddog.co.uk" > Date: Friday, September 13, 2013 12:08 PM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: RE: [nsc] New NSC WG Charter Well, I agree :-) But I would observe that a "composite service" as defined here is a composi= tion of one or more service functions. How is that difference from a "service"? Simplicity seems to say don't use additional words if they aren't needed. A From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: 13 September 2013 16:59 To: Lucy yong; Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Are we really having this discussion again? From where I am sitting Andre's= email is very clear =96 a composite service is something constructed from = one or more service functions and a consumer of said service has no knowled= ge (or frankly concern) of what particular service functions are used in it= s construction. Please let's not overcomplicate this!! From: Lucy yong > Date: Friday, September 13, 2013 11:52 AM To: Andre Beliveau >, Ron Parker >, "adrian@olddog.co.uk" >, Linda Dunbar >, Microsoft Office User >, "nsc@ietf.org= " > Subject: RE: [nsc] New NSC WG Charter Andre, You mean the order of the service functions, right? What this abstract vie= w means to the customer then? Lucy From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 10:44 AM To: Lucy yong; Ron Parker; adrian@olddog.co.uk;= Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Lucy, Think of the Composite Service customer as a person or organization which w= ill subscribe or use the Composite Service but does not need to know of the= internals (e.g. what is the order of the services). In other word, this i= s the simple or abstract view of the Service Function Chain as seen from th= e outside world. I can give you a few examples if needed. /AB From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: September-13-13 11:32 AM To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Andre, Who will be a customer for this service? Is service provider self or third = party? If it is the third party, what is the motivation for the third party= to use it? Lucy From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 10:08 AM To: Ron Parker; adrian@olddog.co.uk; Linda Dunb= ar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Some suggestion for the new name for =93The resulting service that a servic= e provider can offer to its customers as a result of forming Service Functi= on Chains=94 : Delivered Service Network Service (which could be confused with earlier usage of the name) Composite Service Resulting Service My preference goes for Composite Service. /AB From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Ron Parker Sent: September-13-13 11:03 AM To: adrian@olddog.co.uk; 'Linda Dunbar'; 'Jim G= uichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I tend to agree. A service is something that a service provider could des= cribe as an offering to its customers and perhaps charge for it. A good = many of these service offerings are realized by the application of a sequen= ce of one or more service functions in the data plane. Ron From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Adrian Farrel Sent: Friday, September 13, 2013 11:00 AM To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! =93Service Function Chaining=94 is much more clear in describing the intent= of the proposed work. IMHO, it would be even more clear to replace the =93Services=94 across the = charter with =93Service Functions=94, like =93..Service functions delivery.= ..=94, to differentiate from the today=92s connectivity/VPN =93services=94. Linda From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network.Service delivery= is currently both a technical and organisational challenge that involves s= ignificant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_68B171751455884590F8E38E96416F363F68E0E3xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0BF8FDD62193DD4793D5A0AB4D2C5196@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I would argue Adrian that a "composite service" is no different to a "service" as regardless of how a se= rvice is constructed, said construction is transparent to the consumer of t= hat service. 

From: Adrian Farrel <adrian@olddog.co.uk>
Reply-To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Date: Friday, September 13, 2013 12= :08 PM
To: Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: [nsc] New NSC WG Chart= er

Well, I agree :-)

But I would observe that a "composite service" as def= ined here is a composition of one or more service functions.

How is that difference from a "service"?

Simplicity seems to say don't use additional words if they aren= 't needed.

A

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: 13 September 2013 16:59
To: Lucy yong; Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; nsc@= ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Are we really= having this discussion again? From where I am sitting Andre's email is very clear =96 a composite service is something constructed fro= m one or more service functions and a consumer of said service has no knowl= edge (or frankly concern) of what particular service functions are used in = its construction. Please let's not overcomplicate this!!

 

From: Lucy yong <lucy.= yong@huawei.com>
Date: Friday, September 13, 2013 11:52 AM
To: Andre Beliveau <andre.beliveau@ericsson.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, &quo= t;adrian@olddog.co.uk" <adrian@olddog.co.uk>, Li= nda Dunbar <linda.dunbar@huaw= ei.com>, Microsoft Office User <jguichar@cisco.com>, "nsc@= ietf.org" <nsc@ietf.org>
Subject: RE: [nsc] New NSC WG Charter

 

Andre,

You mean the order of the service functions, right?  = What this abstract view means to the customer then? <= o:p>

Lucy

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:44 AM
To: Lucy yong; Ron Parker; ad= rian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Lucy, <= o:p>

Think of the Composite Service customer as a person or org= anization which will subscribe or use the Composite Service but does not ne= ed to know of the internals (e.g. what is the order of the services).  In other word, this is the simple or = abstract view of the Service Function Chain as seen from the outside world.=   I can give you a few examples if needed.

/AB

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: September-13-13 11:32 AM
To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

 

Andre,

Who will be a customer for this service? Is service provid= er self or third party? If it is the third party, what is the motivation fo= r the third party to use it? <= o:p>

Lucy

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:08 AM
To: Ron Parker; adrian@olddog= .co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Some suggestion for the new name for =93The resulting serv= ice that a service provider can offer to its customers as a result of formi= ng Service Function Chains=94 :

Delivered Service
Network Service (which could be confused with earlier usage of the name) Composite Service
Resulting Service

My preference goes for Composite Service. <= o:p>

/AB

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Ron Parker
Sent: September-13-13 11:03 AM
To: adrian@olddog.co.uk; = 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

I tend to agree.   A service is something that a= service provider could describe as an offering to its customers and perhap= s charge for it.    A good many of these service offerings are realized by the application of a sequence of one or more ser= vice functions in the data plane.

   Ron

 

From:nsc-bounc= es@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Linda,

I think it is importan= t to be very clear when we mean service and when we mean service function.<= /span>

IMHO, service function= s are not delivered. Service functions are executed to deliver services.

Perhaps rather than a = global search and replace, you could suggest specific instances to be repla= ced?

Thanks,

Adrian

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 =

I like the new name! <= /span>

=93Service Function Ch= aining=94 is much more clear in describing the intent of the proposed work. <= o:p>

IMHO, it would be even= more clear to replace the =93Services=94 across the charter with =93Servic= e Functions=94, like =93..Service functions delivery...=94, to differentiat= e from the today=92s connectivity/VPN =93services=94. <= o:p>

 

Linda=

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 =

Greetings,

 

We have been working with the routing area AD's and our IAB shepher= d Joel Halpern over the last few days to refine the NSC WG charter. The fol= lowing is our proposal to the community for review and comment. Please note that as an outcome of the various disc= ussions on the list we are proposing that the WG name change from "Net= work Service Chaining (NSC)" to "Service Function Chaining (SFC)&= quot;. 

 

Proposed Service Function Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and applications, have a= ll undergone significant change in recent years with the introduction of vi= rtualization, network overlays, and orchestration. The process of service delivery is changing from the physic= al insertion of equipment on the path into a mechanism for causing the path= or data to transit specific physical or virtual nodes on which the service= functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge= that involves significant modification to the network configuration.

For a given service, the abstracted view of the required service = functions and the order in which they are to be invoked is called a Service= Function Chain (SFC). Since a given service function may be available on more than one node within a network, = a ServiceFunction Chain is instantiated via the selection of specific servi= ce function instances and the network nodes on which they are provided, the= reby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group will develop ne= w approaches to service delivery and deployment, by providing a framework f= or service function chaining and the necessary protocols or protocol extensions to convey the service path and = for communication between nodes that implement service functions.  The= working group will also examine what information needs to be gathered from= the network and service functions in support of service function chaining and how that information may be made = available to nodes that implement the service functions.=

Specifically, the SFC WG is chartered to deliver the following:&n= bsp;

1) Problem Statement: This document will provide a summary of the= problem space to be addressed by the WG including example high-level use c= ases.  Additionally, the WG will normalize nomenclature and definitions for service function chaining.

2) Architecture: This document will provide a description of the = architectural building blocks and their relationships including interconnec= tion, placement of capabilities, management, diagnostics, and security models, as well as requirements on the protocol = mechanisms.

3) Generic Service Function Chaining Encapsulation: A document wi= ll describe the single service-level encapsulation protocol for conveying t= he service function chain and the service function path, and for communicating information between nodes that implem= ent service functions. It is intended that the encapsulation be agnostic to= thenetwork layer at which it is applied and the service that is being cons= tructed. That is, the same encapsulation may be used on a service function path realised at the network layer or at= any other layer, and the same encapsulation willapply for the construction= of service function paths regardless of the actual service.

4) Control Plane Mechanisms: A set of documents will be developed= to describe requirements and protocols necessary to convey information to = service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol e= xtensions work should be carried out in the working groups responsible for = the protocols being modified in coordination with this working group, but may be done in this working group after agree= ment with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the management of se= rvice function chaining includingrelevant MIBs and YANG data modules, and s= ervice function chaining diagnostics.

Proposed Milestones (all dates TBD):

Request the IESG for publication of an Informational document def= ining the problem statement and core use cases for Service Function Chainin= g=

Request the IESG for publication of Informational documents defin= ing the architecture for SFC and describing the framework and requirements = for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Track document sp= ecifying the generic service function chaining encapsulation protocol.<= /o:p>

Request the IESG for publication of Informational documents speci= fying control plane requirements in support of specific SFC use cases.<= /o:p>

Request the IESG for publication of an Informational document def= ining SFC manageability including diagnostics, and MIB and YANG data models= to IESG 

Request the IESG for publication of Informational applicability d= ocuments defining how the protocol elements developed by the WG may be comb= ined with other IETF protocols to satisfy the use cases.

 

 

 --_000_68B171751455884590F8E38E96416F363F68E0E3xmbrcdx01ciscoc_-- From adrian@olddog.co.uk Fri Sep 13 09:11: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 5D0CF21E80B7 for ; Fri, 13 Sep 2013 09:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.071, 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 3cf2UFOnW1SP for ; Fri, 13 Sep 2013 09:11:10 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 46CFA21E80AE for ; Fri, 13 Sep 2013 09:11:09 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8DGAxWm030998; Fri, 13 Sep 2013 17:10:59 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8DGAvOx030987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Sep 2013 17:10:58 +0100 From: "Adrian Farrel" To: "'Linda Dunbar'" , References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BBCB43@dfweml509-mbb.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BBCB43@dfweml509-mbb.china.huawei.com> Date: Fri, 13 Sep 2013 17:10:59 +0100 Message-ID: <029401ceb09b$d64e7ad0$82eb7070$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0295_01CEB0A4.38283F90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEu6VdITONGxYVPfqNTPZVA4U3NIgGSN51QApWSKoUCRSOTk5rP/JQQ Content-Language: en-gb Subject: Re: [nsc] New NSC WG Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:11:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0295_01CEB0A4.38283F90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Lucy, I think that is circular. Why would one apply service functions to a data flow except to provide a service. Lucy asked to whom the service is provided, and I answer "Why, to the service consumer, of course." I don't know what you mean by "applications" in your mail. A service function is instantiated by a combination of hardware and software. In some cases, the service function will be instantiated purely by an "application" (i.e. by a piece of software running on a processor). In other cases it won't. Let's not complicate things by trying to give examples of everything. A From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 13 September 2013 16:44 To: adrian@olddog.co.uk; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Adrian, My interpretation of "Service function Chaining" is about network services that require a sequence of service functions to be applied to a selective data flows. So it is less about "service delivery", but more about "the mechanism of applying service functions to data flows". So I would suggest the sentence "The process of service delivery is.." in the first paragraph to "The process of applying service functions to selective data flows is changing from the physical insertion of equipment on the path into a mechanism for causing the path or ..." The wording of the charter: "Services are typically implemented by the ordered combination of a number of service functions that may be implemented at different points within the network", gives me the impression that the charter is about chaining a sequence of applications, like chaining WebServer <->AppServer<->DBserver. If that is the intent of the charter, it is fine with me. Linda From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, September 13, 2013 10:00 AM To: Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we mean service function. IMHO, service functions are not delivered. Service functions are executed to deliver services. Perhaps rather than a global search and replace, you could suggest specific instances to be replaced? Thanks, Adrian From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of the proposed work. IMHO, it would be even more clear to replace the "Services" across the charter with "Service Functions", like "..Service functions delivery...", to differentiate from the today's connectivity/VPN "services". Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel Halpern over the last few days to refine the NSC WG charter. The following is our proposal to the community for review and comment. Please note that as an outcome of the various discussions on the list we are proposing that the WG name change from "Network Service Chaining (NSC)" to "Service Function Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergone significant change in recent years with the introduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the physical insertion of equipment on the path into a mechanism for causing the path or data to transit specific physical or virtual nodes on which the service functions are performed. Services are typically implemented by the ordered combination of a number of service functions that may be implemented at different points within the network. Service delivery is currently both a technical and organisational challenge that involves significant modification to the network configuration. For a given service, the abstracted view of the required service functions and the order in which they are to be invoked is called a Service Function Chain (SFC). Since a given service function may be available on more than one node within a network, a ServiceFunction Chain is instantiated via the selection of specific service function instances and the network nodes on which they are provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be applied at a specific layer within the network protocol stack (network layer, application layer, etc.). The Service Function Chaining (SFC) working group will develop new approaches to service delivery and deployment, 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. The working group will also examine what information needs to be gathered from the network and service functions in support of service function chaining and how that information may be made available to nodes that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high-level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining. 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level encapsulation protocol for conveying the service function chain and the service function path, and for communicating information between nodes that implement service functions. It is intended that the encapsulation be agnostic to thenetwork layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realised at the network layer or at any other layer, and the same encapsulation willapply for the construction of service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service function chaining includingrelevant MIBs and YANG data modules, and service function chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the architecture for SFC and describing the framework and requirements for a generic service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying the generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying control plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents defining how the protocol elements developed by the WG may be combined with other IETF protocols to satisfy the use cases. ------=_NextPart_000_0295_01CEB0A4.38283F90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lucy,

I think that is = circular. Why would one apply service functions to a data flow except to = provide a service.

Lucy asked to whom the = service is provided, and I answer "Why, to the service consumer, of = course."

I don't know what you = mean by "applications" in your mail. A service function is = instantiated by a combination of hardware and software. In some cases, = the service function will be instantiated purely by an = "application" (i.e. by a piece of software running on a = processor). In other cases it won't. Let's not complicate things by = trying to give examples of everything.

 

A

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f= ont-family:"Times New = Roman";mso-ansi-language:EN-US'>From: Linda Dunbar = [mailto:linda.dunbar@huawei.com]
Sent: 13 September 2013 = 16:44
To: adrian@olddog.co.uk; 'Jim Guichard (jguichar)'; = nsc@ietf.org
Subject: RE: [nsc] New NSC WG = Charter

 

 <= /p>

Adrian, =

My interpretation of = “Service function Chaining” is about network services that = require a sequence of service functions to be applied to a selective = data flows. So it is less about “service delivery”, but more = about “the mechanism of applying service functions to data = flows”.

So I would = suggest the sentence “The process of = service delivery is..”  in the first paragraph = to
    “The process of = applying service functions to selective data flows is changing from the = physical insertion of equipment on the path into a mechanism for causing = the path or ...”

 <= /p>

The wording of the = charter: “Services are = typically implemented by the ordered combination of a number of service = functions that may be implemented at different points within the = network”,  gives me the impression = that the charter is about chaining a sequence of applications, like = chaining WebServer <->AppServer<->DBserver.  If that is = the intent of the charter, it is fine with me.

Linda

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-ansi-lang= uage:EN-US'>From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: = Friday, September 13, 2013 10:00 AM
To: Linda Dunbar; 'Jim = Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC = WG Charter

 

Hi = Linda,

I think it is important to be very clear when we = mean service and when we mean service function.

IMHO, service functions = are not delivered. Service functions are executed to deliver = services.

Perhaps rather than a global search and replace, = you could suggest specific instances to be = replaced?

Thanks,

Adrian

 

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-ansi-lang= uage:EN-US'>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On = Behalf Of Linda Dunbar
Sent: 13 September 2013 = 15:42
To: Jim Guichard (jguichar); = nsc@ietf.org
Subject: Re: [nsc] New NSC WG = Charter

 

I like the new name!

“Service Function = Chaining” is much more clear in describing the intent of the = proposed work.

IMHO, it would be even more clear to replace the = “Services” across the charter with “Service = Functions”, like “..Service functions delivery...”, to = differentiate from the today’s connectivity/VPN = “services”.

 

Linda

 

<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-ansi-lang= uage:EN-US'>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On = Behalf Of Jim Guichard (jguichar)
Sent: Friday, September = 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New = NSC WG Charter
Importance: = High

 

Greetings,<= o:p>

 =

We have = been working with the routing area AD's and our IAB shepherd Joel = Halpern over the last few days to refine the NSC WG charter. The = following is our proposal to the community for review and comment. = Please note that as an outcome of the various discussions on the list we = are proposing that the WG name change from "Network Service = Chaining (NSC)" to "Service Function Chaining = (SFC)". 

 =

<= u>Proposed = Service Function Chaining (SFC) WG Charter=

 =

Networks, = servers, storage technologies, and applications, have all undergone = significant change in recent years with the introduction of = virtualization, network overlays, and orchestration. The process of = service delivery is changing from the physical insertion of equipment on = the path into a mechanism for causing the path or data to transit = specific physical or virtual nodes on which the service functions are = performed. Services are typically implemented by the ordered combination = of a number of service functions that may be implemented at different = points within the network. Service delivery = is currently both a technical and organisational challenge that involves = significant modification to the network configuration.=

For a given = service, the abstracted view of the required service functions and the = order in which they are to be invoked is called a Service Function Chain = (SFC). Since a given service function may be available on more than one = node within a network, a ServiceFunction Chain is instantiated via the = selection of specific service function instances and the network nodes = on which they are provided, thereby forming a servicetopology: this is = called a Service Function Path. The service functions may be applied at = a specific layer within the network protocol stack (network layer, = application layer, etc.).=

The Service = Function Chaining (SFC) working group will develop new approaches to = service delivery and deployment, 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.  The working group will also examine = what information needs to be gathered from the network and service = functions in support of service function chaining and how that = information may be made available to nodes that implement the service = functions.=

Specifically, = the SFC WG is chartered to deliver the following: =

1) Problem = Statement: This document will provide a summary of the problem space to = be addressed by the WG including example high-level use cases. =  Additionally, the WG will normalize nomenclature and definitions = for service function chaining.=

2) Architecture: = This document will provide a description of the architectural building = blocks and their relationships including interconnection, placement of = capabilities, management, diagnostics, and security models, as well as = requirements on the protocol mechanisms.=

3) Generic = Service Function Chaining Encapsulation: A document will describe the = single service-level encapsulation protocol for conveying the service = function chain and the service function path, and for communicating = information between nodes that implement service functions. It is = intended that the encapsulation be agnostic to thenetwork layer at which = it is applied and the service that is being constructed. That is, the = same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation = willapply for the construction of service function paths regardless of = the actual service.=

4) Control Plane = Mechanisms: A set of documents will be developed to describe = requirements and protocols necessary to convey information to service = function implementation points. Where possible, existing IETF protocols = will be used and extended. All protocol = extensions work should be carried out in the working groups responsible = for the protocols being modified in coordination with this working = group, but may be done in this working group after agreement with all = the relevant WG chairs and responsible ADs.

5) = Manageability: This document will address the management of service = function chaining includingrelevant MIBs and YANG data modules, and = service function chaining diagnostics.=

Proposed = Milestones (all dates TBD):=

Request the IESG = for publication of an Informational document defining the problem = statement and core use cases for Service Function Chaining=

Request the IESG = for publication of Informational documents defining the architecture for = SFC and describing the framework and requirements for a generic service = function chaining encapsulation protocol.=

Request the IESG = for publication of a Standards Track document specifying the generic = service function chaining encapsulation protocol.=

Request the IESG = for publication of Informational documents specifying control plane = requirements in support of specific SFC use cases.=

Request the IESG = for publication of an Informational document defining SFC manageability = including diagnostics, and MIB and YANG data models to = IESG =

Request the IESG = for publication of Informational applicability documents defining how = the protocol elements developed by the WG may be combined with other = IETF protocols to satisfy the use cases.=

 =

 =

------=_NextPart_000_0295_01CEB0A4.38283F90-- From smkumar@cisco.com Fri Sep 13 09:23: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 02FF421F9DB4 for ; Fri, 13 Sep 2013 09:23:20 -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 R36+NOmMQewt for ; Fri, 13 Sep 2013 09:23:14 -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 807AE21E80A7 for ; Fri, 13 Sep 2013 09:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=68214; q=dns/txt; s=iport; t=1379089393; x=1380298993; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=oTA23k8zjyUcKx7iNHXnBwOsTlD9T/ccCfpdh8DNglk=; b=JX9Tj5KRiqpSPfdoW5oGyOqZKCP0LEyrr5zM/GIBMwbMxt2ZErGIa7+a EEQwWQGnOFmMR4PZjPOv4nKemB87EqVqjYz/v8S5f+pcLvJhkKiwdwMLh ZiI9MZ/ogwjC8/aiKLlpLyHEzk7jkSDVYafbZHzBZ5Dockx6GVTNbYLWe A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFALk7M1KtJV2Y/2dsb2JhbABbgkNEOFLAdIEcFnSCJQEBAQQaEzoLGQEIEQECAQEBCwIUAQYtDBQDBggCBAERAQgMh2+5cY4oFoECDRMXAQKDHIEAA5NdQZVQgySBaQgXIg X-IronPort-AV: E=Sophos;i="4.90,899,1371081600"; d="scan'208,217";a="259391203" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 13 Sep 2013 16:23:12 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8DGNCVR025930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 16:23:12 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.152]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 13 Sep 2013 11:23:11 -0500 From: "Surendra Kumar (smkumar)" To: "adrian@olddog.co.uk" , "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnDu0AQgABbRACAAAD7gIAAAUmAgAAGyQCAAANggIAAAjGA//++ugCAAEW/AP//jtgA Date: Fri, 13 Sep 2013 16:23:11 +0000 Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C9211235B5@xmb-aln-x09.cisco.com> In-Reply-To: <028f01ceb09b$705ee610$511cb230$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.65.81] Content-Type: multipart/alternative; boundary="_000_8E86B6E7C6FB9F40A00B0E269045A7C9211235B5xmbalnx09ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] New NSC 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, 13 Sep 2013 16:23:20 -0000 --_000_8E86B6E7C6FB9F40A00B0E269045A7C9211235B5xmbalnx09ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I complete agree with Adrian! Service already implies "composite" meaning. We do not need to complicate i= t. Surendra. From: Adrian Farrel > Reply-To: "adrian@olddog.co.uk" > Date: Friday, September 13, 2013 9:08 AM To: "Jim Guichard (jguichar)" >, "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter Well, I agree :-) But I would observe that a "composite service" as defined here is a composi= tion of one or more service functions. How is that difference from a "service"? Simplicity seems to say don't use additional words if they aren't needed. A From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: 13 September 2013 16:59 To: Lucy yong; Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Are we really having this discussion again? From where I am sitting Andre's= email is very clear =96 a composite service is something constructed from = one or more service functions and a consumer of said service has no knowled= ge (or frankly concern) of what particular service functions are used in it= s construction. Please let's not overcomplicate this!! From: Lucy yong > Date: Friday, September 13, 2013 11:52 AM To: Andre Beliveau >, Ron Parker >, "adrian@olddog.co.uk" >, Linda Dunbar >, Microsoft Office User >, "nsc@ietf.org= " > Subject: RE: [nsc] New NSC WG Charter Andre, You mean the order of the service functions, right? What this abstract vie= w means to the customer then? Lucy From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 10:44 AM To: Lucy yong; Ron Parker; adrian@olddog.co.uk;= Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Lucy, Think of the Composite Service customer as a person or organization which w= ill subscribe or use the Composite Service but does not need to know of the= internals (e.g. what is the order of the services). In other word, this i= s the simple or abstract view of the Service Function Chain as seen from th= e outside world. I can give you a few examples if needed. /AB From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: September-13-13 11:32 AM To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Andre, Who will be a customer for this service? Is service provider self or third = party? If it is the third party, what is the motivation for the third party= to use it? Lucy From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Andre Beliveau Sent: Friday, September 13, 2013 10:08 AM To: Ron Parker; adrian@olddog.co.uk; Linda Dunb= ar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Some suggestion for the new name for =93The resulting service that a servic= e provider can offer to its customers as a result of forming Service Functi= on Chains=94 : Delivered Service Network Service (which could be confused with earlier usage of the name) Composite Service Resulting Service My preference goes for Composite Service. /AB From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Ron Parker Sent: September-13-13 11:03 AM To: adrian@olddog.co.uk; 'Linda Dunbar'; 'Jim G= uichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I tend to agree. A service is something that a service provider could des= cribe as an offering to its customers and perhaps charge for it. A good = many of these service offerings are realized by the application of a sequen= ce of one or more service functions in the data plane. Ron From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Adrian Farrel Sent: Friday, September 13, 2013 11:00 AM To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! =93Service Function Chaining=94 is much more clear in describing the intent= of the proposed work. IMHO, it would be even more clear to replace the =93Services=94 across the = charter with =93Service Functions=94, like =93..Service functions delivery.= ..=94, to differentiate from the today=92s connectivity/VPN =93services=94. Linda From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network.Service delivery= is currently both a technical and organisational challenge that involves s= ignificant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_8E86B6E7C6FB9F40A00B0E269045A7C9211235B5xmbalnx09ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <226F29A6038CBE48BBC78601F17A7261@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

I complete agree with Adrian!
Service already implies "composite" meaning. We do not need = to complicate it.

Surendra.

From: Adrian Farrel <adrian@olddog.co.uk>
Reply-To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Date: Friday, September 13, 2013 9:= 08 AM
To: "Jim Guichard (jguichar)&q= uot; <jguichar@cisco.com>, = "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] New NSC WG Chart= er

Well, I agree :-)

But I would observe that a "composite service" as def= ined here is a composition of one or more service functions.

How is that difference from a "service"?

Simplicity seems to say don't use additional words if they aren= 't needed.

A

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: 13 September 2013 16:59
To: Lucy yong; Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; nsc@= ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Are we really= having this discussion again? From where I am sitting Andre's email is very clear =96 a composite service is something constructed fro= m one or more service functions and a consumer of said service has no knowl= edge (or frankly concern) of what particular service functions are used in = its construction. Please let's not overcomplicate this!!

 

From: Lucy yong <lucy.= yong@huawei.com>
Date: Friday, September 13, 2013 11:52 AM
To: Andre Beliveau <andre.beliveau@ericsson.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, &quo= t;adrian@olddog.co.uk" <adrian@olddog.co.uk>, Li= nda Dunbar <linda.dunbar@huaw= ei.com>, Microsoft Office User <jguichar@cisco.com>, "nsc@= ietf.org" <nsc@ietf.org>
Subject: RE: [nsc] New NSC WG Charter

 

Andre,

You mean the order of the service functions, right?  = What this abstract view means to the customer then? <= o:p>

Lucy

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:44 AM
To: Lucy yong; Ron Parker; ad= rian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Lucy, <= o:p>

Think of the Composite Service customer as a person or org= anization which will subscribe or use the Composite Service but does not ne= ed to know of the internals (e.g. what is the order of the services).  In other word, this is the simple or = abstract view of the Service Function Chain as seen from the outside world.=   I can give you a few examples if needed.

/AB

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: September-13-13 11:32 AM
To: Andre Beliveau; Ron Parker; adrian@olddog.co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

 

Andre,

Who will be a customer for this service? Is service provid= er self or third party? If it is the third party, what is the motivation fo= r the third party to use it? <= o:p>

Lucy

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:08 AM
To: Ron Parker; adrian@olddog= .co.uk; Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Some suggestion for the new name for =93The resulting serv= ice that a service provider can offer to its customers as a result of formi= ng Service Function Chains=94 :

Delivered Service
Network Service (which could be confused with earlier usage of the name) Composite Service
Resulting Service

My preference goes for Composite Service. <= o:p>

/AB

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Ron Parker
Sent: September-13-13 11:03 AM
To: adrian@olddog.co.uk; = 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

I tend to agree.   A service is something that a= service provider could describe as an offering to its customers and perhap= s charge for it.    A good many of these service offerings are realized by the application of a sequence of one or more ser= vice functions in the data plane.

   Ron

 

From:nsc-bounc= es@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Hi Linda,

I think it is importan= t to be very clear when we mean service and when we mean service function.<= /span>

IMHO, service function= s are not delivered. Service functions are executed to deliver services.

Perhaps rather than a = global search and replace, you could suggest specific instances to be repla= ced?

Thanks,

Adrian

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 =

I like the new name! <= /span>

=93Service Function Ch= aining=94 is much more clear in describing the intent of the proposed work. <= o:p>

IMHO, it would be even= more clear to replace the =93Services=94 across the charter with =93Servic= e Functions=94, like =93..Service functions delivery...=94, to differentiat= e from the today=92s connectivity/VPN =93services=94. <= o:p>

 

Linda=

 

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] = On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 =

Greetings,

 

We have been working with the routing area AD's and our IAB shepher= d Joel Halpern over the last few days to refine the NSC WG charter. The fol= lowing is our proposal to the community for review and comment. Please note that as an outcome of the various disc= ussions on the list we are proposing that the WG name change from "Net= work Service Chaining (NSC)" to "Service Function Chaining (SFC)&= quot;. 

 

Proposed Service Function Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and applications, have a= ll undergone significant change in recent years with the introduction of vi= rtualization, network overlays, and orchestration. The process of service delivery is changing from the physic= al insertion of equipment on the path into a mechanism for causing the path= or data to transit specific physical or virtual nodes on which the service= functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge= that involves significant modification to the network configuration.

For a given service, the abstracted view of the required service = functions and the order in which they are to be invoked is called a Service= Function Chain (SFC). Since a given service function may be available on more than one node within a network, = a ServiceFunction Chain is instantiated via the selection of specific servi= ce function instances and the network nodes on which they are provided, the= reby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group will develop ne= w approaches to service delivery and deployment, by providing a framework f= or service function chaining and the necessary protocols or protocol extensions to convey the service path and = for communication between nodes that implement service functions.  The= working group will also examine what information needs to be gathered from= the network and service functions in support of service function chaining and how that information may be made = available to nodes that implement the service functions.=

Specifically, the SFC WG is chartered to deliver the following:&n= bsp;

1) Problem Statement: This document will provide a summary of the= problem space to be addressed by the WG including example high-level use c= ases.  Additionally, the WG will normalize nomenclature and definitions for service function chaining.

2) Architecture: This document will provide a description of the = architectural building blocks and their relationships including interconnec= tion, placement of capabilities, management, diagnostics, and security models, as well as requirements on the protocol = mechanisms.

3) Generic Service Function Chaining Encapsulation: A document wi= ll describe the single service-level encapsulation protocol for conveying t= he service function chain and the service function path, and for communicating information between nodes that implem= ent service functions. It is intended that the encapsulation be agnostic to= thenetwork layer at which it is applied and the service that is being cons= tructed. That is, the same encapsulation may be used on a service function path realised at the network layer or at= any other layer, and the same encapsulation willapply for the construction= of service function paths regardless of the actual service.

4) Control Plane Mechanisms: A set of documents will be developed= to describe requirements and protocols necessary to convey information to = service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol e= xtensions work should be carried out in the working groups responsible for = the protocols being modified in coordination with this working group, but may be done in this working group after agree= ment with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the management of se= rvice function chaining includingrelevant MIBs and YANG data modules, and s= ervice function chaining diagnostics.

Proposed Milestones (all dates TBD):

Request the IESG for publication of an Informational document def= ining the problem statement and core use cases for Service Function Chainin= g=

Request the IESG for publication of Informational documents defin= ing the architecture for SFC and describing the framework and requirements = for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Track document sp= ecifying the generic service function chaining encapsulation protocol.<= /o:p>

Request the IESG for publication of Informational documents speci= fying control plane requirements in support of specific SFC use cases.<= /o:p>

Request the IESG for publication of an Informational document def= ining SFC manageability including diagnostics, and MIB and YANG data models= to IESG 

Request the IESG for publication of Informational applicability d= ocuments defining how the protocol elements developed by the WG may be comb= ined with other IETF protocols to satisfy the use cases.

 

 

 --_000_8E86B6E7C6FB9F40A00B0E269045A7C9211235B5xmbalnx09ciscoc_-- From lucy.yong@huawei.com Fri Sep 13 10:44: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 A834321F9D92 for ; Fri, 13 Sep 2013 10:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.162, 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 sjxYhYkjdtFO for ; Fri, 13 Sep 2013 10:44:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 73F1721F9FAE for ; Fri, 13 Sep 2013 10:44:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AXH44038; Fri, 13 Sep 2013 17:44:06 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 18:40:34 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 18:40:50 +0100 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.225]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 10:40:38 -0700 From: Lucy yong To: "adrian@olddog.co.uk" , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQEu6VdITONGxYVPfqNTPZVA4U3NIgGSN51QApWSKoUCRSOTk5rP/JQQgAAR3oA= Date: Fri, 13 Sep 2013 17:40:38 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452C695C@dfweml509-mbb.china.huawei.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BBCB43@dfweml509-mbb.china.huawei.com> <029401ceb09b$d64e7ad0$82eb7070$@olddog.co.uk> In-Reply-To: <029401ceb09b$d64e7ad0$82eb7070$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.99.205.1] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452C695Cdfweml509mbbchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] New NSC 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, 13 Sep 2013 17:44:14 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452C695Cdfweml509mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian, Clarify that your reply is to Linda, not me. My understand is that the SFC addresses the environment that service functi= ons may be only available on the nodes that are not the path and some packe= t flows on the path need to be treated by some of service functions. The S= FC results these packet flows (need service functions) traverse a new path = called service function path in order to be served. This is a clear problem= and need to be solved. To me, term "service delivery" in the charter means the ability to redirect= the packet flows to the nodes where they can be served by the service func= tions. Thanks, Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Adria= n Farrel Sent: Friday, September 13, 2013 11:11 AM To: Linda Dunbar; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Lucy, I think that is circular. Why would one apply service functions to a data f= low except to provide a service. Lucy asked to whom the service is provided, and I answer "Why, to the servi= ce consumer, of course." I don't know what you mean by "applications" in your mail. A service functi= on is instantiated by a combination of hardware and software. In some cases= , the service function will be instantiated purely by an "application" (i.e= . by a piece of software running on a processor). In other cases it won't. = Let's not complicate things by trying to give examples of everything. A From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 13 September 2013 16:44 To: adrian@olddog.co.uk; 'Jim Guichard (jguicha= r)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Adrian, My interpretation of "Service function Chaining" is about network services = that require a sequence of service functions to be applied to a selective d= ata flows. So it is less about "service delivery", but more about "the mech= anism of applying service functions to data flows". So I would suggest the sentence "The process of service delivery is.." in = the first paragraph to "The process of applying service functions to selective data flows is c= hanging from the physical insertion of equipment on the path into a mechani= sm for causing the path or ..." The wording of the charter: "Services are typically implemented by the orde= red combination of a number of service functions that may be implemented at= different points within the network", gives me the impression that the ch= arter is about chaining a sequence of applications, like chaining WebServer= <->AppServer<->DBserver. If that is the intent of the charter, it is fine= with me. Linda From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, September 13, 2013 10:00 AM To: Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of = the proposed work. IMHO, it would be even more clear to replace the "Services" across the char= ter with "Service Functions", like "..Service functions delivery...", to di= fferentiate from the today's connectivity/VPN "services". Linda From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network. Service deliver= y is currently both a technical and organisational challenge that involves = significant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_2691CE0099834E4A9C5044EEC662BB9D452C695Cdfweml509mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adrian,

Clarify that your repl= y is to Linda, not me.

My understand is that = the SFC addresses the environment that service functions may be only availa= ble on the nodes that are not the path and some packet flows on the path ne= ed to be treated by some of service functions.  The SFC results these packet flows (need service function= s) traverse a new path called service function path in order to be served. = This is a clear problem and need to be solved.

To me, term “ser= vice delivery” in the charter means the ability to redirect the packe= t flows to the nodes where they can be served by the service functions. &nb= sp;

Thanks,

Lucy=

 

From: nsc-bounces@ietf.org [mailto:ns= c-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:11 AM
To: Linda Dunbar; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

Lucy,

I think= that is circular. Why would one apply service functions to a data flow exc= ept to provide a service.

Lucy as= ked to whom the service is provided, and I answer "Why, to the service= consumer, of course."

I don't= know what you mean by "applications" in your mail. A service fun= ction is instantiated by a combination of hardware and software. In some ca= ses, the service function will be instantiated purely by an "application" (i.e. by a piece of software running on a pr= ocessor). In other cases it won't. Let's not complicate things by trying to= give examples of everything.

&n= bsp;

A<= /o:p>

From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
Sent: 13 September 2013 16:44
To: adrian@olddog.co.uk; = 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

 

 

Adrian,

My interpretation of &= #8220;Service function Chaining” is about network services that requi= re a sequence of service functions to be applied to a selective data flows.= So it is less about “service delivery”, but more about “the mechanism of applying service functions to data flowsR= 21;.

So I would suggest the= sentence “The process of service delivery is..R= 21;  in the first paragraph to     “The process of applying service function= s to selective data flows is changing from the physical insertion of equipm= ent on the path into a mechanism for causing the path or ...”

 

The wording of the cha= rter: “Services are typically implemented by the ordered com= bination of a number of service functions that may be implemented at different points within the network”,  gives me the impression that the charter= is about chaining a sequence of applications, like chaining WebServer <= ->AppServer<->DBserver.  If that is the intent of the charter, it is fine with me.

Linda

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Friday, September 13, 2013 10:00 AM
To: Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

 

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= o:p>

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 

I like = the new name!

“= Service Function Chaining” is much more clear in describing the inten= t of the proposed work.

IMHO, i= t would be even more clear to replace the “Services” across the= charter with “Service Functions”, like “..Service functi= ons delivery...”, to differentiate from the today’s connectivit= y/VPN “services”.

&n= bsp;

Linda

&n= bsp;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational = challenge that involves significant modification to the network configurati= on.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):<= /o:p>

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D452C695Cdfweml509mbbchi_-- From kgray@juniper.net Fri Sep 13 12:17: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 EFFC911E8112 for ; Fri, 13 Sep 2013 12:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[AWL=1.750, 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 DpAe2nAHOhye for ; Fri, 13 Sep 2013 12:17:00 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF9811E80FF for ; Fri, 13 Sep 2013 12:17:00 -0700 (PDT) Received: from mail35-co9-R.bigfish.com (10.236.132.231) by CO9EHSOBE022.bigfish.com (10.236.130.85) with Microsoft SMTP Server id 14.1.225.22; Fri, 13 Sep 2013 19:16:54 +0000 Received: from mail35-co9 (localhost [127.0.0.1]) by mail35-co9-R.bigfish.com (Postfix) with ESMTP id 0D2E42000B7; Fri, 13 Sep 2013 19:16:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzdb82h9371Ic85eh1418I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de097h186068h8275bh8275dhz2fh2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h1155h) Received-SPF: pass (mail35-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=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(164054003)(51444003)(199002)(189002)(16236675002)(80976001)(69226001)(19580395003)(81542001)(19580405001)(4396001)(47736001)(47976001)(50986001)(83322001)(561944002)(49866001)(65816001)(54316002)(83506001)(46102001)(81342001)(15975445006)(18717965001)(54356001)(59766001)(56816003)(79102001)(76482001)(74502001)(74876001)(74706001)(74366001)(81816001)(47446002)(15202345003)(31966008)(63696002)(36756003)(74662001)(76176001)(56776001)(80022001)(76786001)(76796001)(53806001)(77982001)(77096001)(81686001)(51856001)(19300405004)(83072001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB082; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail35-co9 (localhost.localdomain [127.0.0.1]) by mail35-co9 (MessageSwitch) id 1379099810646111_31849; Fri, 13 Sep 2013 19:16:50 +0000 (UTC) Received: from CO9EHSMHS015.bigfish.com (unknown [10.236.132.251]) by mail35-co9.bigfish.com (Postfix) with ESMTP id 8E08E1200AD; Fri, 13 Sep 2013 19:16:50 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS015.bigfish.com (10.236.130.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 13 Sep 2013 19:16:50 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.353.4; Fri, 13 Sep 2013 19:16:50 +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.775.9; Fri, 13 Sep 2013 19:16:49 +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.0775.005; Fri, 13 Sep 2013 19:16:49 +0000 From: Ken Gray To: Lucy yong , "adrian@olddog.co.uk" , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnDu0AQgAAHcgCAAAxKgIAAB5mAgAAZDQD//9e5gA== Date: Fri, 13 Sep 2013 19:16:49 +0000 Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452C695C@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: 0968D37274 Content-Type: multipart/alternative; boundary="_000_CE58DBD316B8DCkgrayjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [nsc] New NSC 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, 13 Sep 2013 19:17:08 -0000 --_000_CE58DBD316B8DCkgrayjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It doesn't appear to me as if any of this has to do with the charter, per s= e =85 but once again attempts to explore/define how SFC will be achieved/em= bodied/communicated =85 which would be in other documents that are yet to b= e developed. Cart -> Horse From: Lucy yong > Date: Fri, 13 Sep 2013 17:40:38 +0000 To: "adrian@olddog.co.uk" >, Linda Dunbar >, "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter Adrian, Clarify that your reply is to Linda, not me. My understand is that the SFC addresses the environment that service functi= ons may be only available on the nodes that are not the path and some packe= t flows on the path need to be treated by some of service functions. The S= FC results these packet flows (need service functions) traverse a new path = called service function path in order to be served. This is a clear problem= and need to be solved. To me, term =93service delivery=94 in the charter means the ability to redi= rect the packet flows to the nodes where they can be served by the service = functions. Thanks, Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Adrian Farrel Sent: Friday, September 13, 2013 11:11 AM To: Linda Dunbar; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Lucy, I think that is circular. Why would one apply service functions to a data f= low except to provide a service. Lucy asked to whom the service is provided, and I answer "Why, to the servi= ce consumer, of course." I don't know what you mean by "applications" in your mail. A service functi= on is instantiated by a combination of hardware and software. In some cases= , the service function will be instantiated purely by an "application" (i.e= . by a piece of software running on a processor). In other cases it won't. = Let's not complicate things by trying to give examples of everything. A From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 13 September 2013 16:44 To: adrian@olddog.co.uk; 'Jim Guichard (jguicha= r)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Adrian, My interpretation of =93Service function Chaining=94 is about network servi= ces that require a sequence of service functions to be applied to a selecti= ve data flows. So it is less about =93service delivery=94, but more about = =93the mechanism of applying service functions to data flows=94. So I would suggest the sentence =93The process of service delivery is..=94 = in the first paragraph to =93The process of applying service functions to selective data flows is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or ...=94 The wording of the charter: =93Services are typically implemented by the or= dered combination of a number of service functions that may be implemented = at different points within the network=94, gives me the impression that th= e charter is about chaining a sequence of applications, like chaining WebSe= rver <->AppServer<->DBserver. If that is the intent of the charter, it is = fine with me. Linda From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, September 13, 2013 10:00 AM To: Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! =93Service Function Chaining=94 is much more clear in describing the intent= of the proposed work. IMHO, it would be even more clear to replace the =93Services=94 across the = charter with =93Service Functions=94, like =93..Service functions delivery.= ..=94, to differentiate from the today=92s connectivity/VPN =93services=94. Linda From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network.Service delivery= is currently both a technical and organisational challenge that involves s= ignificant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. _______________________________________________ nsc mailing list nsc@ietf.o= rg https://www.ietf.org/mailman/listinfo/nsc --_000_CE58DBD316B8DCkgrayjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9AF22501C118F8429E50581D12430CF8@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
It doesn't appear to me as if any of this has to do with the charter, = per se =85 but once again attempts to explore/define how SFC will be achiev= ed/embodied/communicated =85 which would be in other documents that are yet= to be developed.  Cart -> Horse

From: Lucy yong <lucy.yong@huawei.com>
Date: Fri, 13 Sep 2013 17:40:38 = 3;0000
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Linda Dunbar <linda.dunbar@huawei.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] New NSC WG Chart= er

Adrian,

Clarify that your repl= y is to Linda, not me.

My understand is that = the SFC addresses the environment that service functions may be only availa= ble on the nodes that are not the path and some packet flows on the path ne= ed to be treated by some of service functions.  The SFC results these packet flows (need service function= s) traverse a new path called service function path in order to be served. = This is a clear problem and need to be solved.

To me, term =93service= delivery=94 in the charter means the ability to redirect the packet flows = to the nodes where they can be served by the service functions.  =

Thanks,

Lucy=

 

From:= nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:11 AM
To: Linda Dunbar; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter

 

Lucy,

I think= that is circular. Why would one apply service functions to a data flow exc= ept to provide a service.

Lucy as= ked to whom the service is provided, and I answer "Why, to the service= consumer, of course."

I don't= know what you mean by "applications" in your mail. A service fun= ction is instantiated by a combination of hardware and software. In some ca= ses, the service function will be instantiated purely by an "application" (i.e. by a piece of software running on a pr= ocessor). In other cases it won't. Let's not complicate things by trying to= give examples of everything.

&n= bsp;

A<= /o:p>

From:= mailto:linda.d= unbar@huawei.com]
Sent: 13 September 2013 16:44
To: adrian@olddog.co.uk; = 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

 

 

Adrian,

My interpretation of = =93Service function Chaining=94 is about network services that require a se= quence of service functions to be applied to a selective data flows. So it = is less about =93service delivery=94, but more about =93the mechanism of applying service functions to data flows=94.

So I would suggest the= sentence =93The process of service delivery is..=94 &nbs= p;in the first paragraph to
    =93The process of applying service functions to= selective data flows is changing from the physical insertion of equipment = on the path into a mechanism for causing the path or ...=94

 

The wording of the cha= rter: =93Services are typically implemented by the ordered combina= tion of a number of service functions that may be implemented at different points within the network=94,  gives me the impression that the charter is = about chaining a sequence of applications, like chaining WebServer <->= ;AppServer<->DBserver.  If that is the intent of the charter, it is fine with me.

Linda

From:= mailto:adrian@old= dog.co.uk]
Sent: Friday, September 13, 2013 10:00 AM
To: Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

 

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= o:p>

&n= bsp;

From:= nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 

I like = the new name!

=93Serv= ice Function Chaining=94 is much more clear in describing the intent of the= proposed work.

IMHO, i= t would be even more clear to replace the =93Services=94 across the charter= with =93Service Functions=94, like =93..Service functions delivery...=94, = to differentiate from the today=92s connectivity/VPN =93services=94.

&n= bsp;

Linda

&n= bsp;

From:= nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge that i= nvolves significant modification to the network configuration.=

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):<= /o:p>

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

_______________________________________________ nsc mailing list nsc@ietf.org http= s://www.ietf.org/mailman/listinfo/nsc --_000_CE58DBD316B8DCkgrayjunipernet_-- From adrian@olddog.co.uk Fri Sep 13 12:18: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 5F28F11E8112 for ; Fri, 13 Sep 2013 12:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 DuhVyYW6DPkE for ; Fri, 13 Sep 2013 12:18:13 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBD011E80FF for ; Fri, 13 Sep 2013 12:18:12 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8DJI7CP006673; Fri, 13 Sep 2013 20:18:07 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8DJI6tt006647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Sep 2013 20:18:06 +0100 From: "Adrian Farrel" To: "'Lucy yong'" , "'Linda Dunbar'" , References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645BBCA42@dfweml509-mbb.china.huawei.com> <021401ceb091$e48b3d40$ada1b7c0$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BBCB43@dfweml509-mbb.china.huawei.com> <029401ceb09b$d64e7ad0$82eb7070$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D452C695C@dfweml509-mbb.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452C695C@dfweml509-mbb.china.huawei.com> Date: Fri, 13 Sep 2013 20:18:07 +0100 Message-ID: <039401ceb0b5$fb0e7180$f12b5480$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEu6VdITONGxYVPfqNTPZVA4U3NIgGSN51QApWSKoUCRSOTkwJZQZH1AlhRNBGaqqTWUA== Content-Language: en-gb Subject: Re: [nsc] New NSC WG Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 19:18:19 -0000 Hi Lucy > Clarify that your reply is to Linda, not me. Sorry. Too many equally nice ladies working in the same company with two syllable names beginning with L. As to the rest, I think we are close enough to converged. Adrian From lucy.yong@huawei.com Fri Sep 13 12:29: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 3235E11E8129 for ; Fri, 13 Sep 2013 12:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.151, 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 yFdLk1pxlqvS for ; Fri, 13 Sep 2013 12:29:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 176CC11E80D3 for ; Fri, 13 Sep 2013 12:29:11 -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.5-GA FastPath queued) with ESMTP id AVJ60703; Fri, 13 Sep 2013 19:29:10 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 20:28:53 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 20:29:08 +0100 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.225]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 12:28:58 -0700 From: Lucy yong To: Ken Gray , "adrian@olddog.co.uk" , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQEu6VdITONGxYVPfqNTPZVA4U3NIgGSN51QApWSKoUCRSOTk5rP/JQQgAAR3oCAAJhkgP//i7BQ Date: Fri, 13 Sep 2013 19:28:57 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452C73F5@dfweml509-mbb.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452C695C@dfweml509-mbb.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.99.205.1] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452C73F5dfweml509mbbchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] New NSC 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, 13 Sep 2013 19:29:25 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452C73F5dfweml509mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ken Gray [mailto:kgray@juniper.net] Sent: Friday, September 13, 2013 2:17 PM To: Lucy yong; adrian@olddog.co.uk; Linda Dunbar; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter It doesn't appear to me as if any of this has to do with the charter, per s= e ... but once again attempts to explore/define how SFC will be achieved/em= bodied/communicated ... which would be in other documents that are yet to b= e developed. Cart -> Horse [Lucy] that is not my attempt. Lucy From: Lucy yong > Date: Fri, 13 Sep 2013 17:40:38 +0000 To: "adrian@olddog.co.uk" >, Linda Dunbar >, "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter Adrian, Clarify that your reply is to Linda, not me. My understand is that the SFC addresses the environment that service functi= ons may be only available on the nodes that are not the path and some packe= t flows on the path need to be treated by some of service functions. The S= FC results these packet flows (need service functions) traverse a new path = called service function path in order to be served. This is a clear problem= and need to be solved. To me, term "service delivery" in the charter means the ability to redirect= the packet flows to the nodes where they can be served by the service func= tions. Thanks, Lucy From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Adrian Farrel Sent: Friday, September 13, 2013 11:11 AM To: Linda Dunbar; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter Lucy, I think that is circular. Why would one apply service functions to a data f= low except to provide a service. Lucy asked to whom the service is provided, and I answer "Why, to the servi= ce consumer, of course." I don't know what you mean by "applications" in your mail. A service functi= on is instantiated by a combination of hardware and software. In some cases= , the service function will be instantiated purely by an "application" (i.e= . by a piece of software running on a processor). In other cases it won't. = Let's not complicate things by trying to give examples of everything. A From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 13 September 2013 16:44 To: adrian@olddog.co.uk; 'Jim Guichard (jguicha= r)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Adrian, My interpretation of "Service function Chaining" is about network services = that require a sequence of service functions to be applied to a selective d= ata flows. So it is less about "service delivery", but more about "the mech= anism of applying service functions to data flows". So I would suggest the sentence "The process of service delivery is.." in = the first paragraph to "The process of applying service functions to selective data flows is c= hanging from the physical insertion of equipment on the path into a mechani= sm for causing the path or ..." The wording of the charter: "Services are typically implemented by the orde= red combination of a number of service functions that may be implemented at= different points within the network", gives me the impression that the ch= arter is about chaining a sequence of applications, like chaining WebServer= <->AppServer<->DBserver. If that is the intent of the charter, it is fine= with me. Linda From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, September 13, 2013 10:00 AM To: Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org Subject: RE: [nsc] New NSC WG Charter Hi Linda, I think it is important to be very clear when we mean service and when we m= ean service function. IMHO, service functions are not delivered. Service functions are executed t= o deliver services. Perhaps rather than a global search and replace, you could suggest specific= instances to be replaced? Thanks, Adrian From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Linda Dunbar Sent: 13 September 2013 15:42 To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter I like the new name! "Service Function Chaining" is much more clear in describing the intent of = the proposed work. IMHO, it would be even more clear to replace the "Services" across the char= ter with "Service Functions", like "..Service functions delivery...", to di= fferentiate from the today's connectivity/VPN "services". Linda From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 9:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network.Service delivery= is currently both a technical and organisational challenge that involves s= ignificant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. _______________________________________________ nsc mailing list nsc@ietf.o= rg https://www.ietf.org/mailman/listinfo/nsc --_000_2691CE0099834E4A9C5044EEC662BB9D452C73F5dfweml509mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: Ken Gray [mailto:kgray@juniper.= net]
Sent: Friday, September 13, 2013 2:17 PM
To: Lucy yong; adrian@olddog.co.uk; Linda Dunbar; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

 

It doesn't appear to me as if any of this has to do with the char= ter, per se … but once again attempts to explore/define how SFC will = be achieved/embodied/communicated … which would be in other documents that are yet to be developed.  Cart ->= Horse

[Lucy] that is n= ot my attempt.

Lucy  =

 

 

From: Lucy yong <lucy.yong@huawei.com>
Date: Fri, 13 Sep 2013 17:40:38 +0000
To: "adrian@olddog.co.uk= " <adrian@olddog.co.uk>, Linda Dunbar <linda.d= unbar@huawei.com>, "nsc@ietf.or= g" <nsc@ietf.org>
Subject: Re: [nsc] New NSC WG Charter

 

Adrian,

Clarify that your repl= y is to Linda, not me.=

My understand is that = the SFC addresses the environment that service functions may be only availa= ble on the nodes that are not the path and some packet flows on the path ne= ed to be treated by some of service functions.  The SFC results these packet flows (need service function= s) traverse a new path called service function path in order to be served. = This is a clear problem and need to be solved.

To me, term “ser= vice delivery” in the charter means the ability to redirect the packe= t flows to the nodes where they can be served by the service functions. &nb= sp;

Thanks,

Lucy

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:11 AM
To: Linda Dunbar; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter

 =

Lucy,

I think= that is circular. Why would one apply service functions to a data flow exc= ept to provide a service.

Lucy as= ked to whom the service is provided, and I answer "Why, to the service= consumer, of course."

I don't= know what you mean by "applications" in your mail. A service fun= ction is instantiated by a combination of hardware and software. In some ca= ses, the service function will be instantiated purely by an "application" (i.e. by a piece of software running on a pr= ocessor). In other cases it won't. Let's not complicate things by trying to= give examples of everything.=

 <= /span>

A

From: Linda D= unbar [mailto:linda.dunbar@huawe= i.com]
Sent: 13 September 2013 16:44
To: adrian@olddog.co.uk; = 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

 

 

Adrian,

My interpretation of &= #8220;Service function Chaining” is about network services that requi= re a sequence of service functions to be applied to a selective data flows.= So it is less about “service delivery”, but more about “the mechanism of applying service functions to data flowsR= 21;.

So I would suggest the= sentence “The process of service delivery is..R= 21;  in the first paragraph to     “The process of applying service function= s to selective data flows is changing from the physical insertion of equipm= ent on the path into a mechanism for causing the path or ...”

 

The wording of the cha= rter: “Services are typically implemented by the ordered com= bination of a number of service functions that may be implemented at different points within the network”,  gives me the impression that the charter= is about chaining a sequence of applications, like chaining WebServer <= ->AppServer<->DBserver.  If that is the intent of the charter, it is fine with me. <= /o:p>

Linda

 =

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= /span>

 <= /span>

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] New NSC WG Charter

 

I like = the new name!

“= Service Function Chaining” is much more clear in describing the inten= t of the proposed work.

IMHO, i= t would be even more clear to replace the “Services” across the= charter with “Service Functions”, like “..Service functi= ons delivery...”, to differentiate from the today’s connectivit= y/VPN “services”.

 <= /span>

Linda

 <= /span>

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the r= outing area AD's and our IAB shepherd Joel Halpern over the last few days t= o refine the NSC WG charter. The following is our proposal to the community= for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Function= Chaining (SFC) WG Charter<= /o:p>

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge= that involves significant modification to the network configuration.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups respo= nsible for the protocols being modified in coordination with this working g= roup, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG =

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

______________________________= _________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc

--_000_2691CE0099834E4A9C5044EEC662BB9D452C73F5dfweml509mbbchi_-- From linda.dunbar@huawei.com Mon Sep 16 14:25: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 16CFA11E81D3 for ; Mon, 16 Sep 2013 14:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.41 X-Spam-Level: X-Spam-Status: No, score=-5.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 fpwWbGoOwSH2 for ; Mon, 16 Sep 2013 14:25:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 94E2311E81D6 for ; Mon, 16 Sep 2013 14:25:23 -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.5-GA FastPath queued) with ESMTP id AVN31898; Mon, 16 Sep 2013 21:25:19 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 16 Sep 2013 22:24:53 +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.146.0; Mon, 16 Sep 2013 22:25:01 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Mon, 16 Sep 2013 14:24:56 -0700 From: Linda Dunbar To: "mohamed.boucadair@orange.com OLNC/OLN" , Ron Parker , JACQUENET Christian OLNC/OLN Thread-Topic: Questions to "draft-boucadair-service-chaining-framework-00" Thread-Index: Ac6zIzV4YecyP+l0TLOCgmb29TQbGw== Date: Mon, 16 Sep 2013 21:24:55 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BC7C23@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.99.193.171] Content-Type: multipart/related; boundary="_006_4A95BA014132FF49AE685FAB4B9F17F645BC7C23dfweml509mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" Subject: [nsc] Questions to "draft-boucadair-service-chaining-framework-00" 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, 16 Sep 2013 21:25:34 -0000 --_006_4A95BA014132FF49AE685FAB4B9F17F645BC7C23dfweml509mbxchi_ Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645BC7C23dfweml509mbxchi_" --_000_4A95BA014132FF49AE685FAB4B9F17F645BC7C23dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mohamed, et al, What does the first bullet in the Objective section mean? [cid:image005.png@01CEB2F9.4CA055A0] Is it about the "forwarding planes" among "Service Functions"? or is it abo= ut creating a forwarding plane in the "underlying network? Is the "differentiated packet forwarding" referring to the "underlying netw= ork"? [cid:image006.png@01CEB2F9.4CA055A0] In Section 1.5, you stated that "SFs are handled as black boxes", [cid:image008.png@01CEB2F9.4CA055A0] Is it intended for chaining together existing Service Functions? Does it mean that the Service Functions don't see the "Chain Marking inform= ation" (the Section 6 in draft-boucadair-chaining-design-analysis-00)? Then, is it the underlying nodes that need to interpret the "Chain Marking = Information"? Thanks, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645BC7C23dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mohamed, et al,

 

What does the first bullet in the Objective section = mean?

Is it about the “forwarding planes” amon= g “Service Functions”? or is it about creating a forwarding pla= ne in the “underlying network?  

 

 

Is the “differentiated packet forwarding”= ; referring to the “underlying network”?

 

In Section 1.5, you stated that “SFs are handl= ed as black boxes”,

Is it intended for chaining together  existing = Service Functions?

Does it mean that the Service Functions don’t = see the “Chain Marking information” (the Section 6 in draft-bou= cadair-chaining-design-analysis-00)?  

Then, is it the underlying nodes that need to interp= ret the “Chain Marking Information”?

 

Thanks,

Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645BC7C23dfweml509mbxchi_-- --_006_4A95BA014132FF49AE685FAB4B9F17F645BC7C23dfweml509mbxchi_ Content-Type: image/png; name="image005.png" Content-Description: image005.png Content-Disposition: inline; filename="image005.png"; size=2500; creation-date="Mon, 16 Sep 2013 21:24:52 GMT"; modification-date="Mon, 16 Sep 2013 21:24:52 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAQ8AAAALCAYAAABhyQicAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAlESURBVGje 7Zp3jJRlEMYn2Sj/GBMkEhICRiOCJUAUKSoI2BA1BKQElBbEQldpgmIBCyCghKI0FQu9HAgW8Oi9 qMCBCocCCtI8FJAT5cbvt3Pjfrfc3kHgFmL2ksnuvt9bnmnPzPuBqGrtQF5KSUpSkpKzEcn9EveX EciMQNJyZXbu7/16Zn87A5kWWp+SlKQkuUK+Ltai/MuHPLYHUi73USQk/G4UyPFCttwXyB3R+SdP RjQzM6J79kT02LGI5uRE4vb8/8ihQxFNS4voqVPnd9/09IhmZJzZ3Oxss/dPP51/HPmdxTlZWYXP xf/g+v33C+Obv/46HeuiRRHdvLlozyXeDxyI6N69kWguJFdv8vXyQCYlkzw65Q4nkikFbJcTyJDo vMOHRUePFn30UdH27UVr1RL95hspZO/CZdMm0aVLz32f8y1//CE6dKgESXt+9500SXTJksLnHT8u 2r27aJcuos88I/rnn0Wr75Ejor16id51l+i+fYnnTZki2rq1aMeOol99deF889xzonXriv7ySwzX okVFe+7ff4u++67orbeKjht3oWKzxlncGM6JPOgqro4O79ljBu/USXTevHBSNC9guxOB1IrO69s3 ZrDsbNE+fSwJunYVHTtW9LPPLPgyMyWoSKKDB4v27i26fr2t+fln0QEDbGzqVBv77TfR228Xvf56 w/XppzEjzZxpc8eMSZzAOTmiCxbYucx9/XUbQ0hSxiZOjAVc5862H1hfCm54c+eKduhgepEwJOnw 4YaZxIUsw+d9/73oiy8aVvY+ccLGZ8+23wRWIqwE3ocf2r7ffWdjv/4q+uqrds7TT4u+8ILh+Ocf 0UaNREuXtvnp6TY/K0t0yBA7a+1aG/vhB9P/k09EJ082bDyDdD74QHTOHPP7jz/a/LQ0W8+ZjhV7 MH/gQNFKlUzP/HSYPl30yitFGzcWfftts6nrz7n4Fz+zLzHx/PNWGHg2bZro+++LPvusrVmxwsaJ S76DCT38bHwDJtaDC78xjr8d6803S9BtGC7stHWrzdm/X/S110xHfAqO3bvzYuV5v36ia9acrieY XnnFdGRu//55CZXY57n//vZbOwM7850xzu7WTXTECNvDfUgRGDXK9HWyI47eesvGevYU/frrgsjj skAWJIM8NgVyRbS6oyzJCWCIgEC36ZUL2O5IICWj8x54QHThwryKYAgStnhxS9bly0U3brQEw3A4 hy5l3TrrXJhLgjRtKrp6tZEQFaxhQ8PlDiaZ27Sxfe680wIlP0MeOiT68ssWdDgOIoA4IIDHHrP1 t90m+s47ErS6tg9YSTQC1hOP4CDo69UzJxN848dbhWE/J4527USXLTM7cBZOJ0GpxJxVu7bpyPyM DNMJAScJtW2baJ06lljeXXBmq1ZGxAQOgcWZb75plXXxYgladNuDMyBrPrHrypVGKCQWBIx/P//c SAk7lyxpScveEHUYKzgGDTLiGDnSzvnoI9EKFUR37Mjf3tu3i1arZv7ZsMH8N2GCYUZPzm7b1hJt yxbRqlUtIb780jpMiBwdiT2Ihu/4HF+AiVhATp4U3blT9IYbLFbwCTHEWSQlWPEhWLEpuOiY8LPH 5YMPij7yiOlOsqMjumIr1r/3nmipUvl3z0ePWmdNDKLXjBlWDLGrF1LIx+dDQOB/8knRJk1sjHVl y5pNvvjC/EYMQRKQCfOJJ/CRMx6v6MuagruPcckgj7WBFI9Wn8cfjx2OkQFqvysUsF1W7j3LKjUG 9z0OHrRPWlc3mAcYCUGVhzz4xEEEGISCI0uUMOc7UZC8nkwkDkatWdPWY2ifGy8kObhIFCoagcc4 lfHee209DqXaMk4Q8iyeAMFEQLzxRmycoL7nnthvkqV587zVic8nnrDuybFCoowT6BAMQiL5On6H 7UjQfPyxfeeaREJ58IXPI6Hr1zcd/SzImmfsj83DetG5QUrhMbBCpu4XKja2oxrznCvATTeZDxMF LhjC5EJc0SX4b+wL2fl3r7ielA8/LFqsmOhVVxnZQWr4CEzEUZkyRvTMZ274akT8kMjetYHVuzj0 cVJ2XSFLvlP9e/Qw4iAXnNzpsvbuzV9PrudetIhL8EFo3nl4kQAH3SB2pFuEdLzThfx9P8gMEmVf fM5++JLOCj9C6ow1a2YdqnfWu3ZZ4ciLb0QyyONwIKWiTE67B0DYmGSNBXT9ArY7ntuZ2FWEikFA t2xpgYfjGzQQvfFGMwoMSjLC7FR0HApRcZ+GPJiD0ek0eIZxqByOi6rCeqrUU0/FCMgTNV7oHHAW gYKQfIyvWmVBzXp0pes5dkz0oYdiWP065e8hICt30vz5ple5cqItWliFJxjQBVxg9cCMx4qzE71T oLWtWNEwQ94k6333WeKTsNi2ShUjW75TeTlr1iyzC0HmdsWe4MUGBFz58jYXH5Ckd99tZ6ErieLt tWMl2LEruPAJayGkypVjusULncN111kiQLbYFSHJWE91hQhJNro/uiF08+KAkMR0ieCgg8MvdFFg Yh86GzoRCJ/O4v77bT1XObBC8I6VzpCrBd0nRIAPsTF2ZR3kj12J11tusesciUnSggNdE5EHHRTd NsRGMaNTJo+wFT6qXt2uT5yFLSgKYCNmeC2A/tdea3kHkWM3ulmuJE7ew4ZZ54gv6QQZwxbkDxgg UWzKuhi2SwKZnqwXpg3zVFOqht/VTYYXsN2pQHr+NxdleKcBAxMgOJQApE1lX8biz6I78Ls1FYn5 BHeYTelimIshfS7PGWM+7wsSvfNgrWOK70pY73dwJIyVoI1P7vB33hFQVZgL3ni9wusdK88SYXVb Eax8ggt7spbv+ARdCEbsyKdjhaTDHU/YrqzjXMcKrni/hF+2kuyOlWTwjoAx9sAHYVuEBXzMcT+6 rr4ePXwu8xDI1F9qxtsD8e6P9WDjfHRA5/B6vz7yjLnoRkFjDee6XZFEdmVPug+IEwLj6hH2bdhG NWoYgXPdCePnO8Le3mGxBzHomNGBM/ERRcfH/Sywug7YALzsx5h39OH4Rs8YPm4Kmckij5XRq0v+ bWiVQA4WsuW2QK7Ri+1fQ1KSkrMVf+FMh4D4O7Z4Iam5TvNOiJfQF48OlwYyUIvqL8F/EpsaSJdA uoeE3xvPcNuFgXSMW5+SlKQkeUK+Dgoku8jI41+ekRNqvayhNwAAAABJRU5ErkJggg== --_006_4A95BA014132FF49AE685FAB4B9F17F645BC7C23dfweml509mbxchi_ Content-Type: image/png; name="image006.png" Content-Description: image006.png Content-Disposition: inline; filename="image006.png"; size=5590; creation-date="Mon, 16 Sep 2013 21:24:53 GMT"; modification-date="Mon, 16 Sep 2013 21:24:53 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAaYAAAAbCAYAAAA3UiscAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABVWSURBVHja 7d0LtJVVtQfw7zbGbVwaN8cNR43Ry16jkfaO7GFRGVqWPaRMs+jhAxDKwkyspGyjkFnaS4kQihKx fBQRFRiZRZAoCBEqoUSWWoEQgaIi2rrfby8m+zuns48HBD0HvjXGHGfvb6/HXHPNNf9zrm+tdYqU 0sElNXozbdy4sTFo0KDGeeed19iyZcv252PHjm1Mnz69sXTp0sb+++/fuPTSSxuTJ09uHHrooY3N mzc35s6d2zjwwAMby5Yta5xxxhmNq6++urFixYrG7NmzG7fddluThg4d2nx2zTXXNP8q5+/AgQMb 559/fmPNmjWNlStXNsaPH99YsGBB87fhw4c3Jk2a1CwzYMCAxvr16xuHH354Y+LEiY1FixY1Bg8e 3Gzzqquuaj5/8MEHm/wqj7/eLu+aaqqppkeTim0fenUqDXoaMmRIOv7449O6deu2P7/11lvTcccd l0aPHp3GjBmTSuBq5hk2bFgqASSNGzeuWW758uVp9erVacSIEc3v06ZNS1u3bm3WMXXq1Oazs88+ u1n3zTff3PwedMkllzTz3Xjjjc16PZszZ07zmTZLYEuzZs1Kp512Who5cmS65ZZb0qhRo5r58LZk yZLt/Cp35pln9nZx16lOdarTo5r6BDDVqU51qlOd9p5UA1Od6lSnOtWpV6U+AEz3lXRtSdeVtKim mmqqqaZHha7bRltqYEppbEn/V9ITSuq/19CKFf3TunV9g9dVq/qn22/fe8amr9NNN/Ud3XokiQ7T 5VoW7egJ22j83g5My5qg9JvfFGnw4CK95S1FWras2MZ2kT7zmSK97W1F+u53W8/+9Kec96ij8ud4 vivo+98v0gc/mNv9xz92Xb2rVxfpuOOK9LGPFen++/OzM88smv2u5luwoEgf+ECRhgwp0vz5redf +UqRPvzhIn30o63yu4OWLu36+Te/WaQf/GDny7cj4/eudxVpypTd05/Nm7M8v/OdnuXfsKFIN97Y 8/p//ONc//vfX6Rbbtl949IdrVpVpGOPLdKoUUXaujU/azQ66s/DJfWddNIj05/ly4v03vdmMn47 U0fVhnQer699bdfyS1/uuaf1/ec/zzq9bt0jIy/tb9r08OqgK2wO+t3vPNu3pBv2DGCaN29euuKK K5o75HqeGk0WDSxDTRlPOaUlsL/9rUjnn1+ko49uPbvvvmzo3/zmrGjx/O9/L8r2i/STnxRpy5ai jEiK9NOftn7//e+LNGtW/q2rwfn1r4v07nfnSThzZmuSL1yY673++vz9zjuL9LOfZeD6wx+KNGdO ke6+u/2g42PatGzcX/7yXO6aa4p06aVFWru2lY9CvPjFGbymTs1GUl9PP71IL31pkb785SL98pc5 L95+8Ysi/fCHLQD1F1+33ponN57xde+9ud8zZhTpgQdyndrXH89++9tc/i9/KdKrXlWkCy/MZcnT 8yVLMq/qDV7VedVVuf1rr22BzCtfWaRvfzuXrwK7NuT98587TqhLLsmTuJ3R+9e/8kRXHq/ajN9u uCHXOW9ekR58sPUcv9o3hjffnJ2MU08t0saNWV+C3ypft9/eckze8IaOetRuXC+/vEgHHFCkz342 y4dcPV+0KJf3N3R77tysf7fdltsjK3wHeDCk+qk9+eSZPbulg3SDftIJz+ldVbcmTCjSgQdmfZIX P/RUnvXrs8OjDXxxhqJeMvSMHOi5+dYOLOimvMbg3/8u0j//mXmOMfU8dKkrok/6ZU5WdYMMPDen Q7c4OC97Wcf5QXdD58khnpMjvtQrP9m84hXZbpBV5P3jH4t02WW5z75z8IzR4sW5rLq14beVK1t9 9Ts5d9UnfT/44KwD9E0f6ZmxuPjizCvHIfJrz7ObbuoeKOiBuSyvcQ/g0z/PyD10y/z59Kczv+0A OSjmgDpCP+hG2B0BAH3J+c/p28C0ZcuWcuLNTSeffHJpYE4qgeWUclAu7mHpI7YLeNy4rKQMSdUI Mqrve99/Chm6M1Y+MzYAjYEbOTIL/6yzcgRmshhIhh2YtQMRwPGUpxRp+PBsdDy74IIijR6d6/3U p/LAU7SDDirSa15TpHPOKdKYMR35rZLJ8PnPF+njH8/1UgCTUoTwnOdkgxV5GfQnP7lIJ5xQpIkT s3LedVeR3vrWIu2/f5E++ck8CclKf047LfP2rW9lg2Ly8N5f//rc1498JBvpSZMyjyNGZBmr8+1v L9KgQUX6xCdyJKZfJuMznpG9b/2NyEGk9KIXFWny5BavJoi+k8mJJ+a25d9vvyIdf3wub/KZ/HgG rvKK/PRfv+XRJ/zqR1fyu+OODOYIrxwUhthvjK86Rc4+e8aImKTq1scjj8yyHDYs911eoC/vj35U pM99Ltfhd2MosnrmM3N58u3OY2eMnvrUPLYAjVFjeEJfgKFxBq6crhe+MMuMfho/cveZnPBx6KHZ WKgLTyJsBkRbZP+4x2Ud1z8yABacKO3j/yUvKdKaNdmxeNazivSrX7WMp9/MIXyRCWNnvLXr2Yc+ lPtCfu0cBHXQIfmvvjo7Mhymk0/OeV7wgiKNH991eXNOf/XrTW9qOZTmZlU3ApzoKP0MYDIXjBuZ kytdoBv48BlPr3511nlgZB6JYs29cDoAz2tfm9sLm0PX6RaZys9Iy0cvQwfMifPO67pfnACyPvzw PO4xZ4AVmRpfdRkX44Ufff3iF9uDHQKg5KWv9JhuAr0vfSmXxzd7BXTNHzYCv3S6OwcZj/gxjpwZ 8iVX8ho6NNuSls4P6dvAtGzZsjR48ODSCN3f/L548eJScMf2sPTA7QaFIopYDjmkSGPHtgRK0Qxy Z0FbcrvyytZS17nntn4zgYXsDDJDb9LzCB5qecOyYTUqYMgiJDcRKYnPDI7oLvKGB1olXuUxx2Rw 8N1Sj0lg0vnOgIu2qmUoeHjeQYy4Jbwq2L3uddlwUVx9i3qAJkWtRg+UjvFQx/Oel5+TLyMZUYIJ 47O6upILA2YixHeRiDIUXZT11a/m54xOtRzFJzOAYpJzDEQinIoAGMB39tntxwRYxPKLyQXgTR6T SPsMEidE1HTEER2Xd0UBjPpzn5sBtAo0vGrjg69nPzvrhvz0qifLHwzbO97RMSLwPaIOhpP+0APf RWLAoBrBM5IAi45qm6Hh6eNJX975zlZ+5cNTRuqOyIlO8NKjf4xaRNcIKIXRMlbkyXkJ3WRQRbt0 vh0wVeVC9xl87TOyIo7ulnrxZU4aL/0KwNY//dBfuhNOAyCiixEpAGyOnLGn8/RYe/oVc4/sYmnc PO7KAf3e93Jb8Z3TEtE6kPEb2U2f3spjroWd6Yo4g50BXV+Mr89AwLgBTXNBGxzmdmAX0TjwASKc DrIyxzlNyrOHQDbar9q10LeuXlNUV6PMOc5a2J3/fEUwqG8D09q1a0tQOLcczOnNyGnChAnlhDu9 h6UPawqdZ2GNnOcunDTBGSGDK4JiRHgzFNZ6Kq/GRAQ8JjuhK8+I88ZMFp6oAbQkQCme/vSWR9YV Wd5ioITgJipDhy/KrF4RjejDEoaJycPi8XW3jBfLLMozOLxS0Z22gBT+Y8nH8gXviyH2zISjLCaz CE0dPCcACRQoFeXmIXuOLwAtuuEtAwUAAqiAkN8oPOBjkAEj0AVwvGiy5Tky5CaBicqg4OWww3K+ mADaZqi+8Y0iDRiQPytv0pCT8vopOtI2IMQrcPvrX/P46LulEnyYsK0lhI6Eb8Amr8iDV05+xlT7 jIB3jvoPrES5ZMWYACkeNcPPiGpLv8iAUeOs4IuBolfkZcxF6foQyz7t3lcwloCWN0wPjDXjqn1j Tydj2ZNuWW4BIsrzokXoz39+roe+0nHgjSfgDVAZXLzLQ8+Dp4suaunW179epKc9LY8V2dB5OkKn OEJABxCZa4CA7vLKo/wXvpAjnna6TJ+0b27QIe2Rdzg5eLZM1E5W9AAP9MYY8vo5avop6vMXL+Yd uQBRRlgkbM7imw6KmOQlW/NABMFexHibBwyzMcSrZ2RgHpEhYw8URFrkwvADMcCHD2BojmvDmJG3 VQDOcbu+0WM6Kv911+XlWiscol1OiqjS3Dcvzjgj1+07R6RdnZwoEYy8QMOYG1eRmGeci3BS6DuZ 6is5xLh0Jvyp01haJjQHrWaQC7tDjgC2tXx9ZN8GJmnTpk2l13pW81aGKVOmlJPx3h6WHN1UPIYj loosM/CMeHwG0G+8BgpA+Rk2BsYzv1Ee5eT3nMEKz9Rgmkg8Q+8zuts4YGKoUx3huTEKFMEzChDR ggFGvC2ecXeeNaBRnoFmLHhj/gb/FEQ+ABPP5OUtmjw8ruArIiOT0iQVBalfPn1maCNveMMMsXyI R2mSM+7yUXiyFnF4zmjGUpxyDBXPSl79ZVCifZ8DyJRn2BkW5avRKfDTR+0Dknh3hW8TUB3qbrfu rgxwtWSlTWMIMMkQEDIkysdaPvDDA57wQ5YhN/0gN301gRkmfJF9TEjgoTxDVX0/0JnUH7JWnkFE ohHP/MUnHWK8I29448CRcWE4GWJy8ozRxxPgEVEx4GQVulHdKOJzZ91i/CKvuhhK/eTgAGrziLw4 LowZ4Gbg3/Oeji/xq0T3ldGWvlRBiJGLZcN2RI+0r1/mp3nZlW5wTuhtVec5CfHeR1l5gWrUyyjL BxxidYPDqP/a5OAaF86HPqiXfpNLzHkOsUiMfnkOYHwGJoCr8yalzpsP8AUMvbcN/tkNc0D9ojsy 0x7+jVd3G7fok/rkNabxDpUT5Jm5EA4tmeGdDLTTecWlSpxFvMqrj55x5kLW+GqN7Zi+D0w7nxaU 9D89Wjqpae8jToj3cqLjXbnLrKYcXTBInAgRNACobiJ5KLKUZxnJEiPPe0+RC0cTKAEv8uF4Pdxd b32P/rekhXszMEknlfT4kvapqaYOtHnzPqUHuk8ZVexTGsLexBt97den6a67+pWRS7+0YEG/tHBh vzIS3bHymzf3K6PqfqXn3q+MQPu2LDr36/rrW3LZtGnP6VvPadRut/p9AJg2lnRRSdNKurimmno5 0dPLS5qx7W9NNe0pdNk2Wl8DU0qzSzq6ppr6CB1V0vCS1vXuaVWnOvXi1MuB6c6SDkixpdQLcC8r d+WpaS+wvdDe1euwdg/ZPNDdTr9dQdb9vSTfkRsJHg2ymcDuqx15T9EVeanb3fbcHSEbJWzUiC36 O9IXemiTRPt8p9bWpU512snUy4HpwpL+q2kAvGS0jdX2356eJenpS97YUberyI4a26ftKrMraFfU aeeQnYNd/eZUeezC2V3UXfs9ITuGHDru6kzXjpDdgHHG6eGSHUu2MjcaO1bOMQW71GzZbp/vSSXd UVuYOtVpJ1IvB6Zjmizajmmba1ybESf5nQGJg5TOHnhm669dM84BOJth+y9Qk0f0Yquo7ZN2ccVp 5+rVRXFQ07ZZ50zicKhdRg6S2qLb3VZOvzmD5CS8tkVktkDbVm2rqZP2tjEDRFuGnd2wbVdbcSDS FmJnRzyzXZchdF5q333zTiDbNoG1KNLvtujGCfbYZmu7svJxnsEWd3JhhG3/jfMMcRsB6u7OODw4 C2PbqHqdzQlgV6dn3W2btdXYYdvIG/fmGUNbuLXvKEB3gOCshXNrsQPP1ldjy7EwNuq2rdsZEVug bTu2Pdd4k4PzKA5aax+Yq4Ps1WnMHTQm5858hW7FNnYHEemjHWft+f3vkmbVFqZOddqJ1MuB6eAm i7ZjMhIO1tqC6qyQ54w348/QvvGNeVuqJS0HKp0vsETnHBMj5JCmpTX7/h36dP4DYDBgDtWFQbF/ X6QDrJwXEJ0BF8ACAERADGD1XrcqMX4OKSLtO0QHTB0CVifQcHsFg4oXBwWdjHeOgrHDF0PrjIRz Bw7rOoPiDISDeco5QMwoM8LObDjHg9cAUGDqDIvygNRZHoBsWzV5OEfhuqa4g1CeuKqnXUQD1B3O xSfHgOyMg8gQD9riCFSvUep8ut/WbjKU16FYQCz6AQzGEGB3t+0beNi67AxH3KgBmDkC+kN+DgIC I4cN6QOZayvOvzlYqX3nWgCO/tAN5zeAVpyh4TAAO3y5dQQoOk/krIn+20Y9cGB3wPSYkibUFqZO ddrzgOmQJotAgMEGUIxsXNrKUFpSAS5OZYfHLhKJa3SCHNRjhPyNyAQ5PFddkrHkxOhUl3sAAWBh vHjVwDEihnYHDjvfUuxAn3p8ZkwBDHBxyWLk0S9GvnqdkfcgIi1548qj8OjjM2ABZD6LDBjvan/i rjnXvcR1I+TIsAN3QOVQnv61u3ZG+9UrduKgotPy8R3QOqTYVXkg6nqgiDYtyeqr/uuvMdT/h3rf ZzkxDvLGYcO4RkaUHGMpEgQqIkdl8M9ZiHIAMA4gO30PMKuXlLqAFT/4witQUne8V/KeizNUjQg7 HtAGTBfUFqZOddqJ1MuB6YQUQMM7ZTwYvrj3jlG1tMWztaQnMonIwLKRaCDuBwMwIqOq0XeViOt2 XCvCuANAtxtY6tEWA8iwM6aARHTGK+d1t7six9KWtvEgb4BgXMzJUPLwgQCD6toZmzoYzyc+Medz GwWDiCd994KeYQeKlqX0W1SABwDsuhgRAk+eDEQE6lbeXxEjnvv3z6fwgYFlKNGlv+q1dGmZrt1h QZeQijLIn7wtmZIX0Iuoq7vLJ12no3+iFnlFZyJR8hWBqhOgRzTc1Tsu/cKv++O0KWojRw6KcQOS ZAFggARnhRMBlACudrXlr9stLE/6XbTopgNjZmmPDIA3XvEF/Dzj+IRcjSW9if4COX1p8fzYkubU FqZOddrzgMm5kMc0gcGSDwPh/UFcROivpSnLVq4cEgGIgHjuyLJONQJglKvvYnjY8jB46g6P2fsX V74Ao7gZ3C47z7RluafdvzxgLIGA9kUxESHYjSYa8JslJKRdUYM2AGrc/SWvfuKp+m8IRI144r3z 3BlLHj9QI5/4tw94A27KBzBaYtOWJUFykF+flFGHfrX7twbVZUp9Iof4/0KA3xhoq3oJaWcCHK6n QfJqOyIxBl371X9D0BUw4RXf+mvcLIsCPN+BN5mpq3qxbvXOMeAaS7RASZ2i2ABD/SC3cGbUi6/4 Vw4hR+XJkBOhjXByOvZ/v5LW1BamTnXa84Dp7pIOSvUVMTX1Pdq9/6+mTnXak1MfOGDrf82fWNN2 GlHLoNeTCy431NalTnXaydQHgKlOdapTneq0N6UamPpQ2rBhQ5o5c2Z64IEHamHsYWn16tXpyiuv 3Onyq1atav6/szo9dLrnnnvSjBkzduDf7/QsLVmyJM2fP78W8C5I/w/Ipy7oMcwoSwAAAABJRU5E rkJggg== --_006_4A95BA014132FF49AE685FAB4B9F17F645BC7C23dfweml509mbxchi_ Content-Type: image/png; name="image008.png" Content-Description: image008.png Content-Disposition: inline; filename="image008.png"; size=4570; creation-date="Mon, 16 Sep 2013 21:24:54 GMT"; modification-date="Mon, 16 Sep 2013 21:24:54 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAYYAAAAWCAYAAADEkTsSAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABFaSURBVHja 7dx5kF1FFQbwtvzHKitVKIUgIDtEFhVlE2UVWWQXENSIAQRUEkEMu4JhE9k3ZY8oSwKCApFdRECI hEWRXZF9DWETSEIgSXt/aQ/vZpg3mUzyCCP3Vp2aeff17T7dfc73ne57+qWc8zqVDG+ke5k0adLw ESNGDB87dmwzHo000sj7QtL//mmu5mqu5mqu5pp+NcTQXM3VXM3VXDNcHSSGqZVcX8mFlVzcSCON NNJIx+WiSi6p5Pn3KjFcWsk8/2uikUYaeTflP/9J+bnnmnHojbz1VspPPZXy1Klztt4XXywyd/q1 ayVT3mvE8Eolm06v/vnnUz7kkJR32CHlHXdM+ZVXUr7zzvL/Tjul/J3vpHz88XPfOK67LuUf/CDl l1+e/bouvzzlnXdO+eGHU37jjZR/9rPS33/9q3fP//vfRZcjj0x5ypTO9PeYY4pe9XuTJ6f8y18W XW+9ddbrfPTR8uyYMTMve/XVKR944HsTKJ58MuU332x9/uMfU95995RffbXvdarv8cf79izA2muv lH/9694/M3Zsyscd17f2br65+OvRR/ft+cMP7/uzfRF2NzvPwyT+NmnSnG3ffJ155rszBtdem/KQ ISl/97spP/usex+p5MbOEcP48ePzLbfcUoH5nbNQ7S3TVwuAhnFefHHK999fSODBB1N+4YWUv/jF Ak5nnZXyV79aOgdEAdJttxVC6clRHnggVXqlfM89rfv/+EfKjzyS8uuvF8coA1QAWlkO367OZ55J +VOfSvmqq0pZ9bg/cWLKd91V7r30Urmn3rvvbtUbZQl9Lrww5U9+MuXLLivATq/VVkv5d7+bsc14 /umnW/dELn/4Q8rHHpvyZz7TnqgmTEj59tvL856J++PHl3vGsSeHueGG0t+//KX0xb1p08q4brJJ ab9eJ7A3L3XANEfa8l2MO0D56U9L2+5zuu7av/felFdYoZRRh7mvf1efL+MUbZuDv/61BdKCDHWw tXj+oYfK88aH7rPiYOZ2yy1T/sUvig1pz/wsv3zKV15Z6h037p1t1eegO/ntb1P+yldKWb4QhK8f 7ulHlAVQ2nbfWBibESNSXmONUs5Y8wFjjGzYpzGxSvC8OURm7K6uwxNPtGyDvbsnWHFPHVFO/wQI fHRm46Uff/tbqw7+AqRWXLHMGV2iLF2Vc1+UHnMbffS8oMh3oVdXMg3bMA7sTbn11y++FffClsM2 oi3YY+yVcV/b/AgR8vtYMXg22tc3euknWzYvxjpIxJjzFz6vfODWY4+lfMUVM/afsCfl7rijtKdO bUV7M7NXK5Dof+g7enTKK6+c8vDhhYz0qZQ/qDPEMG7cuIr5j86DBw/OQ4cOrSLYI6uOvdSLai9+ e4l2xhkpH3poyqefXiYgHGK33VLefvuU99yzGIN7P/lJyt/7XspbbZXySSe1HxwTe8IJKe+xRyEb hub+vvumvMACJRJW/+9/n/I//1naV1YU0xNYfvnLZRUzeHARk8tJDjoo5R/+MOXvf7848p/+lPKi i5bPyvkLPBgHxv7Rj1IeOLAYW9Str/SJz5wTgNLLMwxWW6JofbLiAJzh7F2FUe+3X4lk99mnGBTC FbGr89vfLhJO0VX049OfLmV22aUQRMzN3nuX8Y2yvjNP+oDMAzysaPR/u+1SXmaZoiuiRw7m8Vvf Kv1qR2yIadCgooOx4DTGJcZVlHz99Sn/5jcpr7deyueeW+aWfdx3XyFeYyBSsipFDsp/4xtlDDhs 6MvZr7mmgFZPjmduF1ww5S99qdhQkOY665T+kx//uBA2Z4451A7gbVevOf7Yx0q/jC1gsdXDzmO+ Ro4swHreeWUelV1kkeL47Is9GBPjCjD3378AgvnfdtuUjzii9PPEE1PedNOif91e6K1O44Jk2ID5 0r45EyxEef3eeOOex0of6MZW1bvkkqVt3332s6XebbZJ+e9/b5Fj9FWw6N4556Q833zFZ4YNK+Nh bE85pZT95jdbc8AO9Ulb6ufvCGHeeUtwaRwEE+zggguKbSjPZl57rZAdmweg5vHkk0t5+qy5Zivo 0T4bM2crrVRsz7zQw/jDiOHDW8S6+OIlmKBXrJb1dZVVShsxXsiAzsoZ7whCl122+As91NtuZQrn 9NHz7APx8G96wj19Na5soDyzUy7veucwMQwZMiSPGjXq7c+DBg2qOndHL6q94O3IXmTCeESgX/ta KwLQCYAydGir4waFgTB8YNxuzw8r235i6KIw4BhEJFLB6BHtG8AttihlOURPS1zEEM/Sw8AjB7qY kCWWaEVawAfQ+P+oo4o+665bwNk9S1MgVScGEWd83nrrlDffvOjFWIPoRCix+mGU7YzE90CJoX3u c8XIghjUyVg4fbutKCBsnGOe/I9EgxhOPbX1nXE44IAC4htuWO4DY0QY9V16aSHss89Oef75U/7V r2a+fF911db2mrGnr3GKaOzGGwvohLMCmdNOa31eaqkWMS68cCHHP/+5Bd7G4KabWm2ao5//fOZR 8Ne/3go2QoBDzA0ntvVoDABI2GGdTLubL3ZYvwfUBBCeBwrA3LgBtChDf+QqUma/7iFOIGXOAVL4 BP+qR9abbdbyC75mBRXfI1XkDoC1rx62UyeGeL6dXHJJCWLis8gasZsb4+Uewj7//AJWiF1b5ie+ JxttVFZo9VUbokV8xse2I2JDfrGyBOju+3+DDVorhVh1L730jLYRpK3tsO0QOKGOOuHxe2OgrLGl P+Kk0667lh2AKG/FErsJdYE1hx3W+mwsjHd8No/GEKlZzbiHdOrzVBdBY31rim8IdGBE2MGMsl0l b855Yhg5cmQVAZw4fStpzJgxFcvtUHXgwV5Ue0UlH5g+wdiNk4nwAKetFg4sYrEXicljScoQReYi UU5tmd5u7w6oAmR1rr12iUABMfYVWSAgEQBC4mjqtK3lu3ZLNM8iMZGvCBFAmlzGDFBEfIyRQwFt kR0n4PCMkJNgbP1dffVi3AxWxPT5z6d88MGtrS/gAmjpBbD0FSiYeFEEAxK5Blh3FUaFVIGRctpi XAxWnUCLzu1WDABHfxmmdyKe1y/OAICMPyC0FDYnolGGuNxyxSlFt9qhq7oAH6e1+qAX0PN916V0 CF3pHStJRKke400n9frOHNBJNIkUOIc54rjmyCqTHQQJAhjkpW1Ah7DCvtTfm/c8wAQgiP7MnWhd vwUCMfdWwtpCmGFbEVR0J8AdKOkX8gI2gN12jef1G9loUx+1Fdt0gIptWB0AvS98oegnuo5ghF1a tQFAtsQubEWKUvkYXUXM6kS45tAK1qpA+0hJgMFeBT/qt32mfAQ73W0H8g1bn8rxLSClHwDduCFO c4g0gK+2gJ+553Pm0UqIT4etIBD+RGd9EgDRgf+IxKMP6mff7NI8B4kao7XWKuPINmzDAX9zLxgx 1rEKMZ8XXVTaoXe8sDe/MAaBKm8c4QigFzTaMQjfdJ/9aZ8NwCJ4J8Cw4oEH7I89Ixb6my8rGVt+ glk2AS+NhT52N97mz3jH83ZCzLW+s09+hEBbK4Y9KpnWmXcMo0ePnr6VNGzYsMoQ7u1ltfdXssR0 gI1tAUunYHhRhXuYN4iBMACAaTUBWNqtGBiusgDIpIuaGTojiG2g2M8Pp1AnoGwHDACAjsgKaNEb uHJeOplUqwBEwwC0AcQZmP8toW1T0YtRA1bbLwgqlvAkXvhyIIZLL4YX4wD8lKOH521ttHu5GMtk OmmfoXIS9+ncDpQJ4ABUIlUrIu1zMoYfujJ4YM/o1Qmc3AcEETH6bJzseXJUYGws6YL42kXRnNA4 AXZ1xMtuKwnj4p7VByfnAFY0Agq60Nk8mid6kSAANgZ43LMCjXGlGyJsF43VBYghOHOoX0CBbSDP mPtRo0pQYKtAW2yPU/a0F89WPWu+4j2FQMLzVovaifb5RtixZ9k4+7N6Q1x0Y9cxdvTxP9KMdggQ i3dY7NU9z9u+pT/Cj7m1TQKokVI8T0Kvdi9ezaNy6uCz7NkcsBNz4H86aF9b5hVZCCaAYLQTL8vp wP+QCPv2HTvkM2EvykbGDx8xP/QHyOHPYRv0ECQC+2hL9B4BUn372KoAsBr/2GY11tpCIKG/srY4 452O9pUF9IjcHEedxgcxqTd8BnbBLIGiz+xIP8K22tkQe4k6Y/cltqcIgm3tEpzUmXcMfb8sX/ac pZd+jTTSSUEIwKjdCqqRRv6/ZNlKnnyvEYPriUq2qmTVRt7Xskoly1cycK7K668PrKK2gXNdj0Ya 6bysUMl5s4XeHSQG112VXFXJdY28L+XaXHKpX8vN1VzN1X+uDhLDDZUsVsmHKhnQJ5k2bUCePHnW npk0aUCeMKE86/OUKUXcmzhx5s8/++yAfOutA/qsc3+Sl18ekG++efbqmDq1jGuM94zy4Uo+WslR jac1V3P1o6tDxDAhl22k2dsn87JJplJvT0bLVJAFIUtItocXUV4ayyd2T1qYjJv6Yaiu4kWSF7+d 3gOUvTAnTlnPjsiMmd3Tx3FqVLpc+0OJC1RyT+NtzdVc/eTqEDHcXsl8OQ4yeXsvOyVOsvorQ0Em TRxuI050KueNvoMvMkqk1AF55b3x7wmklIvDNN7US13zTORjS6eTPSBDoF1KIZ3q5w+IVDJ6yRxA Pu3al75KT5lF0tziRafMGs/ql3RCGRbyuGXwuFc/WNRVlJWZ4sCOTBzl6eM75yLoVf8JCnnNysjS oYPxk6Uiz1q5yAyT+YFwI8OISAmkpywUWU/6Eel7UuG0JbW1nsklG0c5KXeREdK9nNZ4W3M1Vz+5 OkQMl2TnGKRtSRGVsiYl0gEVQIMApCBKh5TrK8VNeqMUtMjplloYx/flb0s1c6isp9+bAepWDFI1 A/CAoZOJ0jidnQCIrTzfdxKDFLX6QSTti4blUANymS3t2pdaByCdQdAv9UlHk85JN9/7675c+/g9 mp7IBjFIk/MTG3KgpRcCd4fL5NDTi77SP4G5z+qUuifXGqlYMUmTQxTOU0SaoUhfTnz9py/MkQNB UiHlyUszVLcUR3U7b4CkpIqaKymc5tfhv57PCOxWyVuNxzVXc/WDq0PEMDLH4REHWeQEA1QABTxE tYAGMPpZhDj1XP9RNznhtlpEx8DaPaDV7icWkAuwcq7AX9tGInGHtIAwgFZ//YRku/MM8vvrv31E z9C36+8d1QXpIa84gCbKFtU7jxBlEKVIXd56/XTtzNIonfqtH85zuMu2GL0c8JO/jLhiBWaVggjj FDZyca7EoZ36CqHriUn6Guf6PaSKULTleSsS+fHx8xJWYA59Rdvm4p1nUAZV8kbjcc3VXP3g6hAx jK7kg9O3gpwGBiKiTZGmw2lWCrZ6gOQ885RtDysGwB0HtkS3tqEcGnGaF4gutlhZeXQHnN4bOMWJ YGxtxG+0eMfgeDxgbLeFFIJIkJDffIlDSLZinOKMFUMcaulOHG6zOqEroEQODvEAZls0+qtepIdg HJwRcTtF3N2R+lgxiPY/8Ymy8ghisnJAVPQS2SMlKw+frbyQkdWLsr4H7lYYH/940Q/h0WuhhVo6 eacD+P0OjZVNbP0hHT+poG5bR1Z8tpus+jzrUJzfqzHGyjs1S4cZV2Z75GbF0FzN1T+uDhHD3ZUs nuOnJuxNA4rYMhHVi5ptidgiin1r2xuAhijjtCKQRyi2SQCUdw/tgBloetZWSpxw1aY6nMqc2c8m W50AROXVgRi8UA2go2v9V0C7CtKgI13pHL/JggzViwTqv9pq7187Tl+2WzFoDznRyZgF+EZ79HIv 9HJqVTvK+2Ew23kI1s8MaA9R0i/mwGc6BDEgMFth6qj/Gi3y1pZTn0Fittk8a1uLDvGuwzsaesxI DCMbb2uu5uonV4eIwS/67ZSb04dzR5CAVc+AAeUHzOa+Tg7dPNR4W3M1Vz+5/guiRFtkzCyCTQAA AABJRU5ErkJggg== --_006_4A95BA014132FF49AE685FAB4B9F17F645BC7C23dfweml509mbxchi_-- From schalikar@gmail.com Tue Sep 17 01:07: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 B278A11E80EC for ; Tue, 17 Sep 2013 01:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 X7mup5BInsX3 for ; Tue, 17 Sep 2013 01:06:54 -0700 (PDT) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9046621F849C for ; Tue, 17 Sep 2013 01:06:41 -0700 (PDT) Received: by mail-bk0-f50.google.com with SMTP id mz11so2021782bkb.9 for ; Tue, 17 Sep 2013 01:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=+mPnqJ3FzaWYdRZmSeOYbz0UZz/eMx+uzTLqc7Mg7uY=; b=U27U5oswDsCbV0eh7un7RKDuMb9n7PkWThFdDmEFOR+fHtZb4yQQahmr5gIRqOltN2 Y7mAfEAmy4t47Ng6aoh5hoaaCadjXJ/dUdbESZOdWPh59tZz8ZQ44ZFa35MrmNI0BHzi LQSoW1YQimj0n+bTzDB8rndswx56Y3+Ug4VezvfnND/OrTLGRcrgoOG0BLC2HpW+5WmV DAK5X8ToojehqJ7Ok2kZm//L6UJcPZ6Ag9ZpgjGyEXiHHuNskFwiBP8o+8xAXknVoLSE Z8tywbqwekicC/sq0jrXRJ+oYjslXy9V6t+7a4B4YXmPRnArnEmnab2KCHI3PkvbmCJo S+Mw== X-Received: by 10.205.78.5 with SMTP id zk5mr9890605bkb.25.1379405189091; Tue, 17 Sep 2013 01:06:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.68.71 with HTTP; Tue, 17 Sep 2013 01:05:48 -0700 (PDT) In-Reply-To: References: From: Sanjay Chalikar Date: Tue, 17 Sep 2013 13:35:48 +0530 Message-ID: To: nsc@ietf.org Content-Type: multipart/alternative; boundary=f46d041038a74c722004e68fcc1c Subject: Re: [nsc] nsc Digest, Vol 4, Issue 85 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, 17 Sep 2013 08:07:10 -0000 --f46d041038a74c722004e68fcc1c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello All, Sorry, out the box discussion. Can we add a sub-layer into the OSI model as session initiated and session terminated binary calculation. As this would give us the time to include time calculating bit, for me transaction. Do you all really get my concerns. cheers, Sanjay Chalikar Skype id: sanjay.chalikare +91 - 9637 436287/ schalikar@gmail.com, sanjay.chalikar@mail.com http://lnkd.in/sJm_yE http://www.linkedin.com/pub/sanjay-chalikar/2b/7a3/13a On Sat, Sep 14, 2013 at 12:59 AM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/nsc > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send nsc mailing list submissions to > nsc@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/nsc > or, via email, send a message with subject or body 'help' to > nsc-request@ietf.org > > You can reach the person managing the list at > nsc-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of nsc digest..." > > Today's Topics: > > 1. Re: New NSC WG Charter (Adrian Farrel) > 2. Re: New NSC WG Charter (Lucy yong) > > > ---------- Forwarded message ---------- > From: "Adrian Farrel" > To: "'Lucy yong'" , "'Linda Dunbar'" < > linda.dunbar@huawei.com>, > Cc: > Date: Fri, 13 Sep 2013 20:18:07 +0100 > Subject: Re: [nsc] New NSC WG Charter > Hi Lucy > > > Clarify that your reply is to Linda, not me. > > Sorry. Too many equally nice ladies working in the same company with two > syllable names beginning with L. > > As to the rest, I think we are close enough to converged. > > Adrian > > > > > ---------- Forwarded message ---------- > From: Lucy yong > To: Ken Gray , "adrian@olddog.co.uk" < > adrian@olddog.co.uk>, Linda Dunbar , " > nsc@ietf.org" > Cc: > Date: Fri, 13 Sep 2013 19:28:57 +0000 > Subject: Re: [nsc] New NSC WG Charter > > ** ** > > *From:* Ken Gray [mailto:kgray@juniper.net] > *Sent:* Friday, September 13, 2013 2:17 PM > *To:* Lucy yong; adrian@olddog.co.uk; Linda Dunbar; nsc@ietf.org > *Subject:* Re: [nsc] New NSC WG Charter**** > > ** ** > > It doesn't appear to me as if any of this has to do with the charter, per > se =85 but once again attempts to explore/define how SFC will be > achieved/embodied/communicated =85 which would be in other documents that= are > yet to be developed. Cart -> Horse**** > > *[Lucy] that is not my attempt.* > > *Lucy * > > ** ** > > ** ** > > *From: *Lucy yong > *Date: *Fri, 13 Sep 2013 17:40:38 +0000 > *To: *"adrian@olddog.co.uk" , Linda Dunbar < > linda.dunbar@huawei.com>, "nsc@ietf.org" > *Subject: *Re: [nsc] New NSC WG Charter**** > > ** ** > > Adrian,**** > > Clarify that your reply is to Linda, not me.**** > > My understand is that the SFC addresses the environment that service > functions may be only available on the nodes that are not the path and so= me > packet flows on the path need to be treated by some of service functions. > The SFC results these packet flows (need service functions) traverse a n= ew > path called service function path in order to be served. This is a clear > problem and need to be solved.**** > > To me, term =93service delivery=94 in the charter means the ability to > redirect the packet flows to the nodes where they can be served by the > service functions. **** > > Thanks,**** > > Lucy**** > > **** > > *From:* nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] > *On Behalf Of *Adrian Farrel > *Sent:* Friday, September 13, 2013 11:11 AM > *To:* Linda Dunbar; nsc@ietf.org > *Subject:* Re: [nsc] New NSC WG Charter**** > > **** > > Lucy,**** > > I think that is circular. Why would one apply service functions to a data > flow except to provide a service.**** > > Lucy asked to whom the service is provided, and I answer "Why, to the > service consumer, of course."**** > > I don't know what you mean by "applications" in your mail. A service > function is instantiated by a combination of hardware and software. In so= me > cases, the service function will be instantiated purely by an "applicatio= n" > (i.e. by a piece of software running on a processor). In other cases it > won't. Let's not complicate things by trying to give examples of everythi= ng. > **** > > **** > > A**** > > *From:* Linda Dunbar [mailto:linda.dunbar@huawei.com] > > *Sent:* 13 September 2013 16:44 > *To:* adrian@olddog.co.uk; 'Jim Guichard (jguichar)'; nsc@ietf.org > *Subject:* RE: [nsc] New NSC WG Charter**** > > **** > > **** > > Adrian, **** > > My interpretation of =93Service function Chaining=94 is about network ser= vices > that require a sequence of service functions to be applied to a selective > data flows. So it is less about =93service delivery=94, but more about = =93the > mechanism of applying service functions to data flows=94. **** > > So I would suggest the sentence =93The process of service delivery is..= =94 in > the first paragraph to > =93The process of applying service functions to selective data flows = is > changing from the physical insertion of equipment on the path into a > mechanism for causing the path or ...=94**** > > **** > > The wording of the charter: =93Services are typically implemented by the > ordered combination of a number of service functions that may be > implemented at different points within the network=94, gives me the > impression that the charter is about chaining a sequence of applications, > like chaining WebServer <->AppServer<->DBserver. If that is the intent o= f > the charter, it is fine with me. **** > > Linda**** > > *From:* Adrian Farrel [mailto:adrian@olddog.co.uk ] > *Sent:* Friday, September 13, 2013 10:00 AM > *To:* Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org > *Subject:* RE: [nsc] New NSC WG Charter**** > > **** > > Hi Linda,**** > > I think it is important to be very clear when we mean service and when we > mean service function.**** > > IMHO, service functions are not delivered. Service functions are executed > to deliver services.**** > > Perhaps rather than a global search and replace, you could suggest > specific instances to be replaced?**** > > Thanks,**** > > Adrian**** > > **** > > *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] > *On Behalf Of *Linda Dunbar > *Sent:* 13 September 2013 15:42 > *To:* Jim Guichard (jguichar); nsc@ietf.org > *Subject:* Re: [nsc] New NSC WG Charter**** > > **** > > I like the new name! **** > > =93Service Function Chaining=94 is much more clear in describing the inte= nt of > the proposed work. **** > > IMHO, it would be even more clear to replace the =93Services=94 across th= e > charter with =93Service Functions=94, like =93..Service functions deliver= y...=94, > to differentiate from the today=92s connectivity/VPN =93services=94. **** > > **** > > Linda**** > > **** > > *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] > *On Behalf Of *Jim Guichard (jguichar) > *Sent:* Friday, September 13, 2013 9:08 AM > *To:* nsc@ietf.org > *Subject:* [nsc] New NSC WG Charter > *Importance:* High**** > > **** > > Greetings,**** > > **** > > We have been working with the routing area AD's and our IAB shepherd Joel > Halpern over the last few days to refine the NSC WG charter. The followin= g > is our proposal to the community for review and comment. Please note that > as an outcome of the various discussions on the list we are proposing tha= t > the WG name change from "Network Service Chaining (NSC)" to "Service > Function Chaining (SFC)". **** > > **** > > *Proposed Service Function Chaining (SFC) WG Charter***** > > **** > > Networks, servers, storage technologies, and applications, have all > undergone significant change in recent years with the introduction of > virtualization, network overlays, and orchestration. The process of servi= ce > delivery is changing from the physical insertion of equipment on the path > into a mechanism for causing the path or data to transit specific physica= l > or virtual nodes on which the service functions are performed. Services a= re > typically implemented by the ordered combination of a number of service > functions that may be implemented at different points within the > network.Service delivery is currently both a technical and organisational > challenge that involves significant modification to the network > configuration.**** > > For a given service, the abstracted view of the required service function= s > and the order in which they are to be invoked is called a Service Functio= n > Chain (SFC). Since a given service function may be available on more than > one node within a network, a ServiceFunction Chain is instantiated via th= e > selection of specific service function instances and the network nodes on > which they are provided, thereby forming a servicetopology: this is calle= d > a Service Function Path. The service functions may be applied at a specif= ic > layer within the network protocol stack (network layer, application layer= , > etc.).**** > > The Service Function Chaining (SFC) working group will develop new > approaches to service delivery and deployment, by providing a framework f= or > service function chaining and the necessary protocols or protocol > extensions to convey the service path and for communication between nodes > that implement service functions. The working group will also examine wh= at > information needs to be gathered from the network and service functions i= n > support of service function chaining and how that information may be made > available to nodes that implement the service functions.**** > > Specifically, the SFC WG is chartered to deliver the following: **** > > 1) Problem Statement: This document will provide a summary of the problem > space to be addressed by the WG including example high-level use cases. > Additionally, the WG will normalize nomenclature and definitions for > service function chaining.**** > > 2) Architecture: This document will provide a description of the > architectural building blocks and their relationships including > interconnection, placement of capabilities, management, diagnostics, and > security models, as well as requirements on the protocol mechanisms.**** > > 3) Generic Service Function Chaining Encapsulation: A document will > describe the single service-level encapsulation protocol for conveying th= e > service function chain and the service function path, and for communicati= ng > information between nodes that implement service functions. It is intende= d > that the encapsulation be agnostic to thenetwork layer at which it is > applied and the service that is being constructed. That is, the same > encapsulation may be used on a service function path realised at the > network layer or at any other layer, and the same encapsulation willapply > for the construction of service function paths regardless of the actual > service.**** > > 4) Control Plane Mechanisms: A set of documents will be developed to > describe requirements and protocols necessary to convey information to > service function implementation points. Where possible, existing IETF > protocols will be used and extended. All protocol extensions work should > be carried out in the working groups responsible for the protocols being > modified in coordination with this working group, but may be done in this > working group after agreement with all the relevant WG chairs and > responsible ADs.**** > > 5) Manageability: This document will address the management of service > function chaining includingrelevant MIBs and YANG data modules, and servi= ce > function chaining diagnostics.**** > > Proposed Milestones (all dates TBD):**** > > Request the IESG for publication of an Informational document defining th= e > problem statement and core use cases for Service Function Chaining**** > > Request the IESG for publication of Informational documents defining the > architecture for SFC and describing the framework and requirements for a > generic service function chaining encapsulation protocol.**** > > Request the IESG for publication of a Standards Track document specifying > the generic service function chaining encapsulation protocol.**** > > Request the IESG for publication of Informational documents specifying > control plane requirements in support of specific SFC use cases.**** > > Request the IESG for publication of an Informational document defining SF= C > manageability including diagnostics, and MIB and YANG data models to IESG > **** > > Request the IESG for publication of Informational applicability documents > defining how the protocol elements developed by the WG may be combined wi= th > other IETF protocols to satisfy the use cases.**** > > **** > > **** > > _______________________________________________ nsc mailing list > nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc **** > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > > --f46d041038a74c722004e68fcc1c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello All,
<= font color=3D"#0000ff">
Sorry, out = the box discussion. Can we add a sub-layer into the OSI model as session in= itiated and session terminated binary calculation. As this would give us th= e time to include time calculating bit, for me transaction. Do you all real= ly get my concerns.


cheers,
Sanjay=A0Chali= kar
Skype id: sanjay.chalikare


On Sat, Sep 14, 2013 at 12:59 AM, <= nsc-request@ietf.org> wrote:
htt= ps://www.ietf.org/mailman/listinfo/nsc

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send nsc mailing list submissions to
=A0 =A0 =A0 =A0 nsc@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/nsc
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0 nsc-request@ietf.or= g

You can reach the person managing the list at
=A0 =A0 =A0 =A0 nsc-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of nsc digest..."

Today's Topics:

=A0 =A01. Re: New NSC WG Charter (Adrian Farrel)
=A0 =A02. Re: New NSC WG Charter (Lucy yong)


---------- Forwarded message ----------
From:=A0"Adrian Far= rel" <adrian@olddog.co.uk>
To:=A0"'Lucy yong'" <lucy.yong@huawei.com>, "'Linda Dunbar'&= quot; <linda.dunbar@huawei.co= m>, <nsc@ietf.org>
Cc:=A0
Date:=A0Fri, 13 Sep 2013 20:18:07 +0100
Subject:=A0Re: [nsc] N= ew NSC WG Charter
Hi Lucy

> Clarify that your reply is to Linda, not me.

Sorry. Too many equally nice ladies working in the same company with two syllable names beginning with L.

As to the rest, I think we are close enough to converged.

Adrian




---------- Forwarded message ----------
From:=A0Lucy yong <lucy.yong@huawei.com>
To:= =A0Ken Gray <kgray@juniper.net&= gt;, "adrian@olddog.co.uk&q= uot; <adrian@olddog.co.uk>= , Linda Dunbar <linda.dunbar@= huawei.com>, "nsc@ietf.org&= quot; <nsc@ietf.org>
Cc:=A0
Date:=A0Fri, 13 Sep 2013 19:28:57 +0000
Subject:=A0Re: [nsc] N= ew NSC WG Charter

=A0

From: Ken Gray [mailto:kgray@juniper.net]
Sent: Friday, September 13, 2013 2:17 PM
To: Lucy yong; adrian@olddog.co.uk; Linda Dunbar; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

=A0

It= doesn't appear to me as if any of this has to do with the charter, per= se =85 but once again attempts to explore/define how SFC will be achieved/= embodied/communicated =85 which would be in other documents that are yet to be developed. =A0Cart -> Ho= rse

[Lucy] that is n= ot my attempt.

Lucy=A0 <= u>

=A0

=A0

From: Lucy yon= g <lucy.yong@h= uawei.com>
Date: Fri, 13 Sep 2013 17:40:38 +0000
To: "a= drian@olddog.co.uk" <adrian@olddog.co.uk>, Linda Dunbar <linda.dunbar@huawei.com&= gt;, "nsc@ietf.org" <nsc@ietf.org>=
Subject: Re: [nsc] New NSC WG Charter

=A0

Adrian,

Clarify that your repl= y is to Linda, not me.

My understand is that = the SFC addresses the environment that service functions may be only availa= ble on the nodes that are not the path and some packet flows on the path ne= ed to be treated by some of service functions. =A0The SFC results these packet flows (need service functions) = traverse a new path called service function path in order to be served. Thi= s is a clear problem and need to be solved.

To me, term =93service= delivery=94 in the charter means the ability to redirect the packet flows = to the nodes where they can be served by the service functions. =A0<= span style>

Thanks,

Lucy

=A0=

From: nsc-bounces@ietf.= org [mailto:n= sc-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:11 AM
To: Linda Dunbar; = nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

=A0

Lucy,

I think= that is circular. Why would one apply service functions to a data flow exc= ept to provide a service.

Lucy as= ked to whom the service is provided, and I answer "Why, to the service= consumer, of course."

I don&#= 39;t know what you mean by "applications" in your mail. A service= function is instantiated by a combination of hardware and software. In som= e cases, the service function will be instantiated purely by an "application" (i.e. by a piece of software running on a pr= ocessor). In other cases it won't. Let's not complicate things by t= rying to give examples of everything.

=A0

A

From: Linda Dunbar [mailto:linda.dunbar@huawei.com<= /a>]
Sent: 13 September 2013 16:44
To: adrian@= olddog.co.uk; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

=A0=

=A0=

Adrian,

My interpretation of = =93Service function Chaining=94 is about network services that require a se= quence of service functions to be applied to a selective data flows. So it = is less about =93service delivery=94, but more about =93the mechanism of applying service functions to data flows=94.

So I would suggest the= sentence =93The process of service delivery is..=94 =A0in the first paragraph to
=A0=A0=A0 =93The process of applying service functions to selective data flows= is changing from the physical insertion of equipment on the path into a me= chanism for causing the path or ...=94

=A0=

The wording of the cha= rter: =93Services are typically implemented by the ordered combination of a nu= mber of service functions that may be implemented at different points within the network=94, =A0gives me the impression that the charter is abo= ut chaining a sequence of applications, like chaining WebServer <->Ap= pServer<->DBserver. =A0If that is the intent of the charter, it is fine with me. <= /p>

Linda

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Friday, September 13, 2013 10:00 AM
To: Linda Dunbar; 'Jim Guichard (jguichar)'; nsc@ietf.org
Subject: RE: [nsc] New NSC WG Charter

=A0

Hi Lind= a,

I think= it is important to be very clear when we mean service and when we mean ser= vice function.

IMHO, s= ervice functions are not delivered. Service functions are executed to deliv= er services.

Perhaps= rather than a global search and replace, you could suggest specific instan= ces to be replaced?

Thanks,=

Adrian<= /span>

=A0

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter

=A0=

I like = the new name!

=93Serv= ice Function Chaining=94 is much more clear in describing the intent of the= proposed work.

IMHO, i= t would be even more clear to replace the =93Services=94 across the charter= with =93Service Functions=94, like =93..Service functions delivery...=94, = to differentiate from the today=92s connectivity/VPN =93services=94.

=A0

Linda

=A0

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

=A0=

Greetings,=

=A0=

We have been working with the routing area = AD's and our IAB shepherd Joel Halpern over the last few days to refine= the NSC WG charter. The following is our proposal to the community for rev= iew and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)".=A0<= u>

=A0=

Proposed Service Function Chaining (S= FC) WG Charter

=A0=

Networks, servers, storage technologies, and applications, hav= e all undergone significant change in recent years with the introduction of= virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge= that involves significant modification to the network configuration.

For a given service, the abstracted view of the required servi= ce functions and the order in which they are to be invoked is called a Serv= ice Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group will develop= new approaches to service delivery and deployment, by providing a framewor= k for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.= =A0 The working group will also examine what information needs to be gather= ed from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver the following= :=A0

1) Problem Statement: This document will provide a summary of = the problem space to be addressed by the WG including example high-level us= e cases. =A0Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a description of t= he architectural building blocks and their relationships including intercon= nection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation: A document= will describe the single service-level encapsulation protocol for conveyin= g the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents will be develo= ped to describe requirements and protocols necessary to convey information = to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol ex= tensions work should be carried out in the working groups responsible for t= he protocols being modified in coordination with this working group, but ma= y be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=

5) Manageability: This document will address the management of= service function chaining includingrelevant MIBs and YANG data modules, an= d service function chaining diagnostics.

Proposed Milestones (all dates TBD):=

Request the IESG for publication of an Informational document = defining the problem statement and core use cases for Service Function Chai= ning

Request the IESG for publication of Informational documents de= fining the architecture for SFC and describing the framework and requiremen= ts for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Track document= specifying the generic service function chaining encapsulation protocol.

Request the IESG for publication of Informational documents sp= ecifying control plane requirements in support of specific SFC use cases.

Request the IESG for publication of an Informational document = defining SFC manageability including diagnostics, and MIB and YANG data mod= els to IESG=A0

Request the IESG for publication of Informational applicabilit= y documents defining how the protocol elements developed by the WG may be c= ombined with other IETF protocols to satisfy the use cases.

=A0=

=A0=

__________________________________________= _____ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc


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


--f46d041038a74c722004e68fcc1c-- From uri.elzur@intel.com Tue Sep 17 04:09:16 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 B020921F9AE3 for ; Tue, 17 Sep 2013 04:09:16 -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 Mujh31umdrPk for ; Tue, 17 Sep 2013 04:09:11 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDB121F9DF0 for ; Tue, 17 Sep 2013 04:09:11 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 17 Sep 2013 04:09:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.90,922,1371106800"; d="scan'208,217";a="396915996" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga001.fm.intel.com with ESMTP; 17 Sep 2013 04:09:09 -0700 Received: from orsmsx105.amr.corp.intel.com ([169.254.4.128]) by ORSMSX104.amr.corp.intel.com ([169.254.3.146]) with mapi id 14.03.0123.003; Tue, 17 Sep 2013 04:09:09 -0700 From: "Elzur, Uri" To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVA== Date: Tue, 17 Sep 2013 11:09:08 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B8995856FDF35F0@ORSMSX105.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: multipart/alternative; boundary="_000_7E05C330D7FD6D4FAD0728C46B8995856FDF35F0ORSMSX105amrcor_" MIME-Version: 1.0 Subject: Re: [nsc] 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, 17 Sep 2013 11:09:16 -0000 --_000_7E05C330D7FD6D4FAD0728C46B8995856FDF35F0ORSMSX105amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bullet 3 below suggests "it is intended that the encapsulation be agnostic = to the network layer at which it is applied and the service that is being c= onstructed. That is, the same encapsulation may be used on a service functi= on path realised at the network layer or at any other layer, and the same e= ncapsulation will apply for the construction of service function paths rega= rdless of the actual service" This makes me wonder. I assume the intention of the nsc WG is to provide se= rvices to some network nodes that reside in some domain e.g. an overlay, or= in some (single?) admin domain. Would it not be simpler and more natural t= o provide the service at that layer? It seems like the number of cases wher= e a service is centralized or offered across different admin domain than th= at of the consuming nodes, may be dwarfed by the cases where they co-reside= , maybe in the same row, maybe in the same rack or even on the same server.= The incentive may be to localize the service close to its consumer to redu= ce the network burden of carrying traffic unnecessarily over some distance.= Virtualization and Virtual appliances may enable such phenomenon. It seems like a by-product of creating an independent Service layer with fu= ll encapsulation (i.e. header with some routing info as well as other info = related to the service graph and potentially service index number as propos= ed on the list) may cause a need for gateways everywhere an overlay is used= or everywhere the traffic needs to traverse those separate domains to get = into the "service layer" . The WG can achieve the same goal by defining the structure of the SFC heade= rs to be added and make that format universal across any network layer. i.e= . let's suggest some headers containing meta-data and service graph. The sa= me structure can be applied to any network layer, in essence extending its = functionality, by the IETF WG that owns that layer, prime candidates will b= e overlays used in the context of Network Virtualization e.g. added to VXLA= N, NVGRE, GRE or any other layer. It can also allow creation of a dedicated= Service layer OUTSIDE of such Transports or Overlays for those who wish it= , but does nothing to restrict the WG to such Service layer ONLY. while I'd like to refrain judgement which approach is advantageous, I'd exp= ect the WG will at least discuss it. The above text in the proposed charter= seems to stand against reviewing/discussing this point. Is this discussion= not warranted? Has the pre-WG participants already determine a separate la= yer is a MUST? Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Friday, September 13, 2013 7:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network. Service deliver= y is currently both a technical and organisational challenge that involves = significant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_7E05C330D7FD6D4FAD0728C46B8995856FDF35F0ORSMSX105amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bullet 3 below suggests “it is intended that= the encapsulation be agnostic to the network layer at which it is applied = and the service that is being constructed. That is, the same encapsulation may be used on a service function path realised= at the network layer or at any other layer, and the same encapsulation wil= l apply for the construction of service function paths regardless of the ac= tual service”

This makes me wonder. I assume the intention of = the nsc WG is to provide services to some network nodes that reside in some= domain e.g. an overlay, or in some (single?) admin domain. Would it not be simpler and more natural to provide the serv= ice at that layer? It seems like the number of cases where a service is cen= tralized or offered across different admin domain than that of the consumin= g nodes, may be dwarfed by the cases where they co-reside, maybe in the sam= e row, maybe in the same rack or even on the same server. The incentive may be to localize the service clos= e to its consumer to reduce the network burden of carrying traffic unnecess= arily over some distance. Virtualization and Virtual appliances may enable = such phenomenon.

It seems like a by-product of creating an indepe= ndent Service layer with full encapsulation (i.e. header with some routing = info as well as other info related to the service graph and potentially service index number as proposed on the = list) may cause a need for gateways everywhere an overlay is used or everyw= here the traffic needs to traverse those separate domains to get into the &= #8220;service layer” .

The WG = can achieve the same goal by defining the structure of the SFC headers to b= e added and make that format universal across any network layer. i.e. let&#= 8217;s suggest some headers containing meta-data and service graph. The same structure can be applied to any network= layer, in essence extending its functionality, by the IETF WG that owns th= at layer, prime candidates will be overlays used in the context of Network = Virtualization e.g. added to VXLAN, NVGRE, GRE or any other layer. It can also allow creation of a dedicated S= ervice layer OUTSIDE of such Transports or Overlays for those who wish it, = but does nothing to restrict the WG to such Service layer ONLY.

while I= ’d like to refrain judgement which approach is advantageous, I’= d expect the WG will at least discuss it. The above text in the proposed ch= arter seems to stand against reviewing/discussing this point. Is this discussion not warranted? Has the pre-WG participants = already determine a separate layer is a MUST?

 

Thx

 

Uri ("Oo-Ree")

O: (949)-567-4519

C: (949)-3= 78-7568

From: nsc-bounces@ietf.org [mailto:ns= c-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 7:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the = routing area AD's and our IAB shepherd Joel Halpern over the last few days = to refine the NSC WG charter. The following is our proposal to the communit= y for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Functio= n Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational = challenge that involves significant modification to the network configurati= on.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups r= esponsible for the protocols being modified in coordination with this worki= ng group, but may be done in this working group after agreement with all the relevant WG chairs and responsi= ble ADs.

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_7E05C330D7FD6D4FAD0728C46B8995856FDF35F0ORSMSX105amrcor_-- From melinda.shore@gmail.com Tue Sep 17 05:38: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 2B6E511E8418 for ; Tue, 17 Sep 2013 05:38:51 -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 XND7oRb1oZub for ; Tue, 17 Sep 2013 05:38:50 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C252F11E8237 for ; Tue, 17 Sep 2013 05:38:50 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id p10so5515621pdj.18 for ; Tue, 17 Sep 2013 05:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bbxJjluVclREFbcFPUxv/Brsp0LVFGlYK2pIaljCnnw=; b=cYjdW20kqXr7N+Bqn32gpCxM03Qv8NSfnJ5A9NglUPeMrH+gcQhl1lNj0Ck6bpWCyw 5cVLxLBj1E90OG5WMbPp7esmbYLn4OHG4mAwECeIWi7aAVYwAcg2pTe0EdosjVJMfDgk 5f16SDOqQpVxo1cByRuIDOMf0GwQj1kvnEZgc+hKjRJKSXfE1GxC2UAX8IMm98gia/66 IQcvzyRKrwfqMV8odZtPs1598Z5iaezwRDFJlO0XjuxB8mngqBn8vtls0RTkwwXjXNQs +d8ef/s8yqU98vfLBYudn0K65vJJhslsmq6K8heVppwvL+xD0kpeoqARtLUxZs0k/4UA XURA== X-Received: by 10.66.144.73 with SMTP id sk9mr3121175pab.172.1379421530429; Tue, 17 Sep 2013 05:38:50 -0700 (PDT) Received: from spandex.local (66-230-85-52-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.85.52]) by mx.google.com with ESMTPSA id wp8sm38001015pbc.26.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 05:38:49 -0700 (PDT) Message-ID: <52384D56.60100@gmail.com> Date: Tue, 17 Sep 2013 04:38:46 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: nsc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [nsc] nsc Digest, Vol 4, Issue 85 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, 17 Sep 2013 12:38:51 -0000 On 9/17/13 12:05 AM, Sanjay Chalikar wrote: > Sorry, out the box discussion. Can we add a sub-layer into the OSI > model as session initiated and session terminated binary calculation. > As this would give us the time to include time calculating bit, for > me transaction. Do you all really get my concerns. I'm afraid I don't. Could you explain the problem in more detail? Melinda From jguichar@cisco.com Tue Sep 17 10:48: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 285F211E812B for ; Tue, 17 Sep 2013 10:48:55 -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=[AWL=-0.000, 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 DiBnddNA13Is for ; Tue, 17 Sep 2013 10:48:49 -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 0F16D11E82D1 for ; Tue, 17 Sep 2013 10:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34968; q=dns/txt; s=iport; t=1379440129; x=1380649729; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=7IHlw6QgwkX4K7buzV58npcfgze3TsKgTFk0liaNtDg=; b=dgQdjvtcRSQ/ic3Z/EgP8MqOw+wx8fJK9+ZLCcdrM3Hb5bMwFdy1tBjq HujFktlP7AyOD0TWu+LF3FYCQ4cM9tCT2/MybpJmhtl/4WhgNMSPfCWUI tOu3u56TtvYk+vOyDTi/AkxOY/dN8o9NQCle6ZXXefw4mc21Owug6niff U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAKCVOFKtJXG+/2dsb2JhbABXA4JDRDhSwSKBHhZ0giUBAQEELToLGQEIEQECAQEBCxYBBjkUAwYIAQEEARIIDIdvujmONIECDRMBFgECD4MNgQADlB+VUIMkgWlB X-IronPort-AV: E=Sophos;i="4.90,925,1371081600"; d="scan'208,217";a="260765043" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 17 Sep 2013 17:48:37 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8HHmagP020156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Sep 2013 17:48:36 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 17 Sep 2013 12:48:36 -0500 From: "Jim Guichard (jguichar)" To: "Elzur, Uri" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiA Date: Tue, 17 Sep 2013 17:48:36 +0000 Message-ID: <68B171751455884590F8E38E96416F363F691BB7@xmb-rcd-x01.cisco.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B8995856FDF35F0@ORSMSX105.amr.corp.intel.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.131.36.146] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F691BB7xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] 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, 17 Sep 2013 17:48:55 -0000 --_000_68B171751455884590F8E38E96416F363F691BB7xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Uri, Inline .. From: , Uri > Date: Tuesday, September 17, 2013 7:09 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Bullet 3 below suggests =93it is intended that the encapsulation be agnosti= c to the network layer at which it is applied and the service that is being= constructed. That is, the same encapsulation may be used on a service func= tion path realised at the network layer or at any other layer, and the same= encapsulation will apply for the construction of service function paths re= gardless of the actual service=94 This makes me wonder. I assume the intention of the nsc WG is to provide se= rvices to some network nodes that reside in some domain e.g. an overlay, or= in some (single?) admin domain. Would it not be simpler and more natural t= o provide the service at that layer? It seems like the number of cases wher= e a service is centralized or offered across different admin domain than th= at of the consuming nodes, may be dwarfed by the cases where they co-reside= , maybe in the same row, maybe in the same rack or even on the same server.= The incentive may be to localize the service close to its consumer to redu= ce the network burden of carrying traffic unnecessarily over some distance.= Virtualization and Virtual appliances may enable such phenomenon. Jim> it is certainly true that different administrative domains may be pre= sent within a particular operators network and indeed those domains may be = separately managed and therefore services may need to span multiple domains= . However, I am confused by your use of the term "layer". Within the charte= r when we refer to a layer we mean a layer of the protocol stack and not a = layer of the network. We certainly don't mean to imply any form of network = boundary or delineation. In addition, nothing in the above prevents the ser= vice functions to be co-resident with workloads. It just makes it general e= nough to address the broad range of deployment scenarios. Given that "migra= tion" is a killer-app of virtualization, service-overlay becomes critical. It seems like a by-product of creating an independent Service layer with fu= ll encapsulation (i.e. header with some routing info as well as other info = related to the service graph and potentially service index number as propos= ed on the list) may cause a need for gateways everywhere an overlay is used= or everywhere the traffic needs to traverse those separate domains to get = into the =93service layer=94 . Jim> again I think this may simply be a terminology mismatch. The overlay i= s simply the transport used to get packets to/from service functions and th= is overlay may or may not span administrative domains. Gateways may be nece= ssary if translation at the service encapsulation layer is needed between d= omains. It is worth noting that the initial task of the WG will be to work = on single domain use cases only before tackling any inter-domain dependenci= es. The WG can achieve the same goal by defining the structure of the SFC heade= rs to be added and make that format universal across any network layer. i.e= . let=92s suggest some headers containing meta-data and service graph. The = same structure can be applied to any network layer, in essence extending it= s functionality, by the IETF WG that owns that layer, prime candidates will= be overlays used in the context of Network Virtualization e.g. added to VX= LAN, NVGRE, GRE or any other layer. It can also allow creation of a dedicat= ed Service layer OUTSIDE of such Transports or Overlays for those who wish = it, but does nothing to restrict the WG to such Service layer ONLY. Jim> I think we are talking the same language and indeed draft-quinn-nsh ta= kes this exact approach. while I=92d like to refrain judgement which approach is advantageous, I=92d= expect the WG will at least discuss it. The above text in the proposed cha= rter seems to stand against reviewing/discussing this point. Is this discus= sion not warranted? Has the pre-WG participants already determine a separat= e layer is a MUST? Jim> there seems to general consensus to postpone discussion beyond the cha= rter until after the WG is formed. Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 7:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network.Service delivery= is currently both a technical and organisational challenge that involves s= ignificant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_68B171751455884590F8E38E96416F363F691BB7xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <794EA1390D9E094893527BCCD52186DB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Uri,

Inline ..

From: <Elzur>, Uri <uri.elzur@intel.com>
Date: Tuesday, September 17, 2013 7= :09 AM
To: Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] New NSC WG Chart= er - charter bullet #3

Bullet 3 below suggests =93it is intended that the= encapsulation be agnostic to the network layer at which it is applied and = the service that is being constructed. That is, the same encapsulation may be used on a service function path realised= at the network layer or at any other layer, and the same encapsulation wil= l apply for the construction of service function paths regardless of the ac= tual service=94

This makes me wonder. I assume the intention of = the nsc WG is to provide services to some network nodes that reside in some= domain e.g. an overlay, or in some (single?) admin domain. Would it not be simpler and more natural to provide the serv= ice at that layer? It seems like the number of cases where a service is cen= tralized or offered across different admin domain than that of the consumin= g nodes, may be dwarfed by the cases where they co-reside, maybe in the sam= e row, maybe in the same rack or even on the same server. The incentive may be to localize the service clos= e to its consumer to reduce the network burden of carrying traffic unnecessarily over some distance. Virtualization and Virtual appliances may enable such = phenomenon.
Jim>  it is certainly true that di= fferent administrative domains may be present within a particular operators network and indeed those domains may be separately ma= naged and therefore services may need to span multiple domains. However, I = am confused by your use of the term "layer". Within the charter w= hen we refer to a layer we mean a layer of the protocol stack and not a layer of the network. We certainly don't m= ean to imply any form of network boundary or delineation. In addition, nothing in the above prevents the service functions to be co-resident with workloa= ds. It just makes it general enough to address the broad range of deploymen= t scenarios. Given that "migration" is a killer-app of virtualiza= tion, service-overlay becomes critical.

It seems like a by-product of creating an independent Service layer with f= ull encapsulation (i.e. header with some routing info as well as other info related to the service graph and potent= ially service index number as proposed on the list) may cause a need = for gateways everywhere an overlay is used or everywhere the traffic needs to traverse those separate domains to get = into the =93service layer=94 .
Jim> again I = think this may simply be a terminology mismatch. The overlay is simply the = transport used to get packets to/from service functions and this overlay may or may not span administrative domains. Gat= eways may be necessary if translation at the service encapsulation layer is= needed between domains. It is worth noting that the initial task of the WG= will be to work on single domain use cases only before tackling any inter-domain dependencies.

The WG can achieve the same goal = by defining the structure of the SFC headers to be added and make that form= at universal across any network layer. i.e. let=92s suggest some headers containing meta-data and service graph. The s= ame structure can be applied to any network layer, in essence extending its functionality, by the IE= TF WG that owns that layer, prime candidates will be overlays used in the c= ontext of Network Virtualization e.g. added to VXLAN, NVGRE, GRE or any oth= er layer. It can also allow creation of a dedicated Service layer OUTSIDE of such Transports or Overlays for th= ose who wish it, but does nothing to restrict the WG to such Service layer = ONLY.

Jim> I think we = are talking the same language and indeed draft-quinn-nsh takes this exact a= pproach. 

while I=92d like to refrain ju= dgement which approach is advantageous, I=92d expect the WG will at least d= iscuss it. The above text in the proposed charter seems to stand against re= viewing/discussing this point. Is this discussion not warranted? Has the pre-WG participants already determine a separate la= yer is a MUST?

Jim> there seems to g= eneral consensus to postpone discussion beyond the charter until after the WG is formed. 

Thx

 

Uri ("Oo-Ree")=

O: (949)-567-4519<= /span>

C: (949)-378-7568

From:= nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 7:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the = routing area AD's and our IAB shepherd Joel Halpern over the last few days = to refine the NSC WG charter. The following is our proposal to the communit= y for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Functio= n Chaining (SFC) WG Charter

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge that i= nvolves significant modification to the network configuration.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups r= esponsible for the protocols being modified in coordination with this worki= ng group, but may be done in this working group after agreement with all the relevant WG chairs and responsi= ble ADs.

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG 

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

 --_000_68B171751455884590F8E38E96416F363F691BB7xmbrcdx01ciscoc_-- From jguichar@cisco.com Tue Sep 17 10:51: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 B404511E8560 for ; Tue, 17 Sep 2013 10:51:21 -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=[AWL=0.000, 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 GAcvigIF-nxt for ; Tue, 17 Sep 2013 10:51:16 -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 3E24111E82AC for ; Tue, 17 Sep 2013 10:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=609; q=dns/txt; s=iport; t=1379440276; x=1380649876; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=PfQzaDbPEFRAswtkLAvurgWYy1giuWBM6dN7HJMfcp0=; b=WA9QPSB5zu8rBFdU/8ftpRbu2jpy/on/3J9L1uod5npcapkzoiXkFyU2 cKlhknB10vaeFtr9C+uH4L7GMMLqLdAwGszqFAWuf6eMhw8Fj9hhF3va7 PT69JzT89hyKJ4L9VQe2BsAxfXEzazkWCj5oIutbE3mDv2K8V3HTjdva7 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAB2WOFKtJXG9/2dsb2JhbABagwc4UoJjvj+BHhZ0giUBAQEEAQEBNzQdAQgYChQxBgslAgQBEgiHaQMPDLB+DYkfBIx7gjs4gx6BAAOWEo4qhTODJIIq X-IronPort-AV: E=Sophos;i="4.90,925,1371081600"; d="scan'208";a="260978495" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 17 Sep 2013 17:51:14 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8HHpEnH000997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Sep 2013 17:51:14 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 17 Sep 2013 12:51:13 -0500 From: "Jim Guichard (jguichar)" To: Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] nsc Digest, Vol 4, Issue 85 Thread-Index: AQHOs3zws2Z71Iq9UUecoZrHutqXhJnKMosAgAAUO4A= Date: Tue, 17 Sep 2013 17:51:13 +0000 Message-ID: <68B171751455884590F8E38E96416F363F691BFC@xmb-rcd-x01.cisco.com> In-Reply-To: <52384D56.60100@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.131.36.146] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D9FFF5B63E4DC43A7B5A03B95D22963@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] nsc Digest, Vol 4, Issue 85 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, 17 Sep 2013 17:51:22 -0000 +1 On 9/17/13 8:38 AM, "Melinda Shore" wrote: >On 9/17/13 12:05 AM, Sanjay Chalikar wrote: >> Sorry, out the box discussion. Can we add a sub-layer into the OSI >> model as session initiated and session terminated binary calculation. >> As this would give us the time to include time calculating bit, for >> me transaction. Do you all really get my concerns. > >I'm afraid I don't. Could you explain the problem in more detail? > >Melinda >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From uri.elzur@intel.com Tue Sep 17 13:26:34 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 AD88811E8142 for ; Tue, 17 Sep 2013 13:26:32 -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 Aed8RJKTrAho for ; Tue, 17 Sep 2013 13:26:26 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id 0A90911E8329 for ; Tue, 17 Sep 2013 13:26:22 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by azsmga101.ch.intel.com with ESMTP; 17 Sep 2013 13:26:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.90,926,1371106800"; d="scan'208,217";a="397179672" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by fmsmga001.fm.intel.com with ESMTP; 17 Sep 2013 13:26:11 -0700 Received: from orsmsx154.amr.corp.intel.com (10.22.226.12) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 17 Sep 2013 13:26:10 -0700 Received: from orsmsx105.amr.corp.intel.com ([169.254.4.128]) by ORSMSX154.amr.corp.intel.com ([169.254.11.92]) with mapi id 14.03.0123.003; Tue, 17 Sep 2013 13:26:10 -0700 From: "Elzur, Uri" To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtA= Date: Tue, 17 Sep 2013 20:26:10 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF35F0@ORSMSX105.amr.corp.intel.com> <68B171751455884590F8E38E96416F363F691BB7@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F691BB7@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.22.254.138] Content-Type: multipart/alternative; boundary="_000_7E05C330D7FD6D4FAD0728C46B8995856FDF3C82ORSMSX105amrcor_" MIME-Version: 1.0 Subject: Re: [nsc] 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, 17 Sep 2013 20:26:35 -0000 --_000_7E05C330D7FD6D4FAD0728C46B8995856FDF3C82ORSMSX105amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim Thx for the quick response. Pls see below [UE] Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, September 17, 2013 10:49 AM To: Elzur, Uri; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Hi Uri, Inline .. From: , Uri > Date: Tuesday, September 17, 2013 7:09 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Bullet 3 below suggests "it is intended that the encapsulation be agnostic = to the network layer at which it is applied and the service that is being c= onstructed. That is, the same encapsulation may be used on a service functi= on path realised at the network layer or at any other layer, and the same e= ncapsulation will apply for the construction of service function paths rega= rdless of the actual service" This makes me wonder. I assume the intention of the nsc WG is to provide se= rvices to some network nodes that reside in some domain e.g. an overlay, or= in some (single?) admin domain. Would it not be simpler and more natural t= o provide the service at that layer? It seems like the number of cases wher= e a service is centralized or offered across different admin domain than th= at of the consuming nodes, may be dwarfed by the cases where they co-reside= , maybe in the same row, maybe in the same rack or even on the same server.= The incentive may be to localize the service close to its consumer to redu= ce the network burden of carrying traffic unnecessarily over some distance.= Virtualization and Virtual appliances may enable such phenomenon. Jim> it is certainly true that different administrative domains may be pre= sent within a particular operators network and indeed those domains may be = separately managed and therefore services may need to span multiple domains= . However, I am confused by your use of the term "layer". Within the charte= r when we refer to a layer we mean a layer of the protocol stack and not a = layer of the network. We certainly don't mean to imply any form of network = boundary or delineation. In addition, nothing in the above prevents the ser= vice functions to be co-resident with workloads. It just makes it general e= nough to address the broad range of deployment scenarios. Given that "migra= tion" is a killer-app of virtualization, service-overlay becomes critical. [UE] let me try to be more specific. I'd like to make sure the Service Func= tion Chain can be integrated within the entity that provides the Network Ov= erlay (for example for the simple case of a single Admin domain and a singl= e Network Overlay deployed here) I'm not trying to imply that the proposed charter presents the SFC as a Ne= twork Layer. I'm concerned about a separate name space for Services (on top= of that used for a Network Overlay or any Transport already in use). Such = use may increase the storage required in the network (Switch, Router, vSwit= ch etc.) and in the Service devices. Another concern relates to the SFC he= ader location. If it is a separate entity, it may mean that more info like = routing info be required, which may be separate from and duplicate of the r= outing info provided by a Tunnel/Overlay). I'd like to suggest the WG chart= er keeps the door open for extending an existing Overly header to include t= he SFC info (which I think, the consensus is that it is needed), as long as= we talk about Service graph, service index etc. It seems like a by-product of creating an independent Service layer with fu= ll encapsulation (i.e. header with some routing info as well as other info = related to the service graph and potentially service index number as propos= ed on the list) may cause a need for gateways everywhere an overlay is used= or everywhere the traffic needs to traverse those separate domains to get = into the "service layer" . Jim> again I think this may simply be a terminology mismatch. The overlay i= s simply the transport used to get packets to/from service functions and th= is overlay may or may not span administrative domains. Gateways may be nece= ssary if translation at the service encapsulation layer is needed between d= omains. It is worth noting that the initial task of the WG will be to work = on single domain use cases only before tackling any inter-domain dependenci= es. [UE] Jim, not sure what "overlay is simply the transport" is referred to in= your comment above (existing Transport or a new one for the Services). Pls= see my comment above, I hope we can include the case where the Transport f= or the SFC may also be a Transport already in use (e.g. extending an overla= y like VXLAN to become VXLAN+ or GRE =3D> GRE+ etc.) vs. a completely new T= ransport The WG can achieve the same goal by defining the structure of the SFC heade= rs to be added and make that format universal across any network layer. i.e= . let's suggest some headers containing meta-data and service graph. The sa= me structure can be applied to any network layer, in essence extending its = functionality, by the IETF WG that owns that layer, prime candidates will b= e overlays used in the context of Network Virtualization e.g. added to VXLA= N, NVGRE, GRE or any other layer. It can also allow creation of a dedicated= Service layer OUTSIDE of such Transports or Overlays for those who wish it= , but does nothing to restrict the WG to such Service layer ONLY. Jim> I think we are talking the same language and indeed draft-quinn-nsh ta= kes this exact approach. [UE] I've looked at rev 01 and was not sure as it is not specific enough. B= etween the definitions of the Service Path, Network Platform Context and Se= rvice Platform Context provided in the draft and the GRE example, I was not= able to tell how close it is to the direction suggested above. If indeed w= e are on the same page, I rest my case (and the associated email thread :)) while I'd like to refrain judgement which approach is advantageous, I'd exp= ect the WG will at least discuss it. The above text in the proposed charter= seems to stand against reviewing/discussing this point. Is this discussion= not warranted? Has the pre-WG participants already determine a separate la= yer is a MUST? Jim> there seems to general consensus to postpone discussion beyond the cha= rter until after the WG is formed. [UE] just trying to ensure the charter ALLOWS for the above outlined option= . The architectural discussion can follow later Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 7:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network.Service delivery= is currently both a technical and organisational challenge that involves s= ignificant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_7E05C330D7FD6D4FAD0728C46B8995856FDF3C82ORSMSX105amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim

 

Thx for the quick resp= onse. Pls see below [UE]

 

Thx

 

Uri ("Oo-Ree")

O: (949)-567-4519

C: (949)-3= 78-7568

From: Jim Guichard (jguichar) [mailto= :jguichar@cisco.com]
Sent: Tuesday, September 17, 2013 10:49 AM
To: Elzur, Uri; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=

 

Hi Uri,

 

Inline ..

 

From: <Elzur>, Uri <uri.elzur@intel.com>
Date: Tuesday, September 17, 2013 7:09 AM
To: Microsoft Office User <= jguichar@cisco.com>, "nsc@ietf.= org" <nsc@ietf.org>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=

 

Bullet 3 below suggests “it is intended that= the encapsulation be agnostic to the network layer at which it is applied = and the service that is being constructed. That is, the same encapsulation may be used on a service function path realised= at the network layer or at any other layer, and the same encapsulation wil= l apply for the construction of service function paths regardless of the ac= tual service”

This makes me wonder. I assume the intention of = the nsc WG is to provide services to some network nodes that reside in some= domain e.g. an overlay, or in some (single?) admin domain. Would it not be simpler and more natural to provide the serv= ice at that layer? It seems like the number of cases where a service is cen= tralized or offered across different admin domain than that of the consumin= g nodes, may be dwarfed by the cases where they co-reside, maybe in the sam= e row, maybe in the same rack or even on the same server. The incentive may be to localize the service clos= e to its consumer to reduce the network burden of carrying traffic unnecessarily over some distance. Virtualization and Virtual appliances may enable such pheno= menon.

Jim>  it is certainly true that different admi= nistrative domains may be present within a particular operators network and indeed those domains may be separately managed and t= herefore services may need to span multiple domains. However, I am confused= by your use of the term "layer". Within the charter when we refe= r to a layer we mean a layer of the protocol stack and not a layer of the network. We certainly don= 't mean to imply any form of network boundary or delineation. In addition, = nothing in the above prevents the service functions to be co-resident with workloa= ds. It just makes it general enough to address the broad range of deploymen= t scenarios. Given that "migration" is a killer-app of virtualiza= tion, service-overlay becomes critical.

 

[UE] let me try to be more specific. I’= d like to make sure the Service Function Chain can be integrated within the= entity that provides the Network Overlay (for example for the simple case = of a single Admin domain and a single Network Overlay deployed here)

I’m not trying to imply that the propos= ed charter presents the SFC as  a Network Layer. I’m concerned a= bout a separate name space for Services (on top of that used for a Network = Overlay or any Transport already in use). Such use may increase the storage required in the network (Switch, Router, vSwitch = etc.) and in the Service devices.  Another concern relates to the SFC = header location. If it is a separate entity, it may mean that more info lik= e routing info be required, which may be separate from and duplicate of the routing info provided by a Tunnel/Ov= erlay). I’d like to suggest the WG charter keeps the door open for ex= tending an existing Overly header to include the SFC info (which I think, t= he consensus is that it is needed), as long as we talk about Service graph, service index etc.<= /p>

 

It seems like a by-product of creating an indepe= ndent Service layer with full encapsulation (i.e. header with some routing = info as well as other info related to the service graph and potentially service index number as proposed on the list) may cause a need for gateways every= where an overlay is used or everywhere the traffic needs to traverse those separate domains to get into the “se= rvice layer” .

Jim> again I think this may simply be a terminology mismatch. The overl= ay is simply the transport used to get packets to/from service functions an= d this overlay may or may not span administrative domains. Gateways may be necessary if translation at the service encapsula= tion layer is needed between domains. It is worth noting that the initial t= ask of the WG will be to work on single domain use cases only before tackli= ng any inter-domain dependencies.

[UE] Jim, not sure what “overla= y is simply the transport”= ; is referred to in your comment above (existing Transport or a new one for the Services). Pls see my comment above, I hope we can in= clude the case where the Transport for the SFC may also be a Transport alre= ady in use (e.g. extending an overlay like VXLAN to become VXLAN+ or GR= E =3D> GRE+ etc.) vs. a completely new Transport

 

 

The WG can achieve the same goal by defining the= structure of the SFC headers to be added and make that format universal ac= ross any network layer. i.e. let’s suggest some headers containing meta-data and service graph. The same structure ca= n be applied to any network layer, in essence extending its functionality, by the IE= TF WG that owns that layer, prime candidates will be overlays used in the c= ontext of Network Virtualization e.g. added to VXLAN, NVGRE, GRE or any oth= er layer. It can also allow creation of a dedicated Service layer OUTSIDE of such Transports or Overlays for th= ose who wish it, but does nothing to restrict the WG to such Service layer = ONLY. <= /o:p>

Jim> I think we are talking t= he same language and indeed draft-quinn-nsh takes this exact approach. = ;

[UE] I’ve looked at rev 01 and was not = sure as it is not specific enough. Between the definitions of the Service P= ath, Network Platform Context and Service Platform Context provided in the = draft and the GRE example, I was not able to tell how close it is to the direction suggested above. If indeed we are= on the same page, I rest my case (and the associated email thread J)

 

while I’d like to refrain judgement which = approach is advantageous, I’d expect the WG will at least discuss it.= The above text in the proposed charter seems to stand against reviewing/discussing this point. Is this discussion not warranted?= Has the pre-WG participants already determine a separate layer is a MUST?<= /span>

Jim> <= span style=3D"font-size:10.5pt;color:red">there seems to general consensus = to postpone discussion beyond the charter until after the WG is formed. <= /span>=

[UE] just trying to ensure the charter ALLOWS= for the above outlined option. The architectural discussion can follow lat= er

 

Thx<= /span>

 

Uri ("Oo-Ree")

O: (949)-567-4519

C: (949)-3= 78-7568

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 7:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the = routing area AD's and our IAB shepherd Joel Halpern over the last few days = to refine the NSC WG charter. The following is our proposal to the communit= y for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Functio= n Chaining (SFC) WG Charter=

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge= that involves significant modification to the network configuration.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups r= esponsible for the protocols being modified in coordination with this worki= ng group, but may be done in this working group after agreement with all the relevant WG chairs and responsi= ble ADs.

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG =

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_7E05C330D7FD6D4FAD0728C46B8995856FDF3C82ORSMSX105amrcor_-- From smkumar@cisco.com Wed Sep 18 12:04: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 603ED11E8119 for ; Wed, 18 Sep 2013 12:04:01 -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 Jhgqqtjc5xTL for ; Wed, 18 Sep 2013 12:03:55 -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 6F5CE11E8164 for ; Wed, 18 Sep 2013 12:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46660; q=dns/txt; s=iport; t=1379531035; x=1380740635; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=MBj+f8bHcKL8EngNIP2gjdaGRMnR5RKMIjdWEmmDl5Y=; b=YGeW0hJNWhNgYAvvFlB6X2zyMk3crvghsKiSNMn8i36UcsIE7wlzSs6F lfxmSUO/mctU6uRCWIU5lHd1WviCWIO8v4xjkp6AfSJ2SOQeXJ0ycNQL8 aBVIsJAyVhzFV0+ZBdJNO3EOWCoJtv814+uvthnrBhtxp0Sb8oU1pooGf s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADr4OVKtJXG8/2dsb2JhbABYA4JDRDhSwSyBHBZ0giUBAQEEGhM6CxkBCBEBAgEBAQsWAQY5FAMGCAEBBAESCAyHb7oHjh4WgQINEwEWAQIPgw2BAAOUH5VQgySBaQgXIg X-IronPort-AV: E=Sophos;i="4.90,930,1371081600"; d="scan'208,217";a="258534618" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 18 Sep 2013 19:03:54 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8IJ3riT016380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Sep 2013 19:03:53 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.195]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 18 Sep 2013 14:03:53 -0500 From: "Surendra Kumar (smkumar)" To: "Elzur, Uri" , "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AA== Date: Wed, 18 Sep 2013 19:03:53 +0000 Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.93.248] Content-Type: multipart/alternative; boundary="_000_8E86B6E7C6FB9F40A00B0E269045A7C9211489D9xmbalnx09ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] 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: Wed, 18 Sep 2013 19:04:01 -0000 --_000_8E86B6E7C6FB9F40A00B0E269045A7C9211489D9xmbalnx09ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Uri, There has been consensus to postpone the discussion that you are bringing (= as I understand it) until after the WG is formed. At the risk of inviting t= he wrath of Jim, comment inline. Surendra. From: , Uri > Date: Tuesday, September 17, 2013 1:26 PM To: "Jim Guichard (jguichar)" >, "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Hi Jim Thx for the quick response. Pls see below [UE] Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, September 17, 2013 10:49 AM To: Elzur, Uri; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Hi Uri, Inline .. From: , Uri > Date: Tuesday, September 17, 2013 7:09 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Bullet 3 below suggests =93it is intended that the encapsulation be agnosti= c to the network layer at which it is applied and the service that is being= constructed. That is, the same encapsulation may be used on a service func= tion path realised at the network layer or at any other layer, and the same= encapsulation will apply for the construction of service function paths re= gardless of the actual service=94 This makes me wonder. I assume the intention of the nsc WG is to provide se= rvices to some network nodes that reside in some domain e.g. an overlay, or= in some (single?) admin domain. Would it not be simpler and more natural t= o provide the service at that layer? It seems like the number of cases wher= e a service is centralized or offered across different admin domain than th= at of the consuming nodes, may be dwarfed by the cases where they co-reside= , maybe in the same row, maybe in the same rack or even on the same server.= The incentive may be to localize the service close to its consumer to redu= ce the network burden of carrying traffic unnecessarily over some distance.= Virtualization and Virtual appliances may enable such phenomenon. Jim> it is certainly true that different administrative domains may be pre= sent within a particular operators network and indeed those domains may be = separately managed and therefore services may need to span multiple domains= . However, I am confused by your use of the term "layer". Within the charte= r when we refer to a layer we mean a layer of the protocol stack and not a = layer of the network. We certainly don't mean to imply any form of network = boundary or delineation. In addition, nothing in the above prevents the ser= vice functions to be co-resident with workloads. It just makes it general e= nough to address the broad range of deployment scenarios. Given that "migra= tion" is a killer-app of virtualization, service-overlay becomes critical. [UE] let me try to be more specific. I=92d like to make sure the Service Fu= nction Chain can be integrated within the entity that provides the Network = Overlay (for example for the simple case of a single Admin domain and a sin= gle Network Overlay deployed here) I=92m not trying to imply that the proposed charter presents the SFC as a = Network Layer. I=92m concerned about a separate name space for Services (on= top of that used for a Network Overlay or any Transport already in use). S= uch use may increase the storage required in the network (Switch, Router, v= Switch etc.) and in the Service devices. Another concern relates to the SF= C header location. If it is a separate entity, it may mean that more info l= ike routing info be required, which may be separate from and duplicate of t= he routing info provided by a Tunnel/Overlay). I=92d like to suggest the WG= charter keeps the door open for extending an existing Overly header to inc= lude the SFC info (which I think, the consensus is that it is needed), as l= ong as we talk about Service graph, service index etc. SK> If you are talking about absorbing the service-specific information (or= service-header to use a term for clarity) into the transports, such as int= egrating all that into VXLAN header, it may be too early to talk about it. = However, it did come up earlier in the discussion as well and it is not the= idea that we should be pursuing as it is fraught with issues and many atte= mpts in the past have not succeeded in similar efforts. It seems like a by-product of creating an independent Service layer with fu= ll encapsulation (i.e. header with some routing info as well as other info = related to the service graph and potentially service index number as propos= ed on the list) may cause a need for gateways everywhere an overlay is used= or everywhere the traffic needs to traverse those separate domains to get = into the =93service layer=94 . Jim> again I think this may simply be a terminology mismatch. The overlay i= s simply the transport used to get packets to/from service functions and th= is overlay may or may not span administrative domains. Gateways may be nece= ssary if translation at the service encapsulation layer is needed between d= omains. It is worth noting that the initial task of the WG will be to work = on single domain use cases only before tackling any inter-domain dependenci= es. [UE] Jim, not sure what =93overlay is simply the transport=94 is referred t= o in your comment above (existing Transport or a new one for the Services).= Pls see my comment above, I hope we can include the case where the Transpo= rt for the SFC may also be a Transport already in use (e.g. extending an ov= erlay like VXLAN to become VXLAN+ or GRE =3D> GRE+ etc.) vs. a completely n= ew Transport The WG can achieve the same goal by defining the structure of the SFC heade= rs to be added and make that format universal across any network layer. i.e= . let=92s suggest some headers containing meta-data and service graph. The = same structure can be applied to any network layer, in essence extending it= s functionality, by the IETF WG that owns that layer, prime candidates will= be overlays used in the context of Network Virtualization e.g. added to VX= LAN, NVGRE, GRE or any other layer. It can also allow creation of a dedicat= ed Service layer OUTSIDE of such Transports or Overlays for those who wish = it, but does nothing to restrict the WG to such Service layer ONLY. Jim> I think we are talking the same language and indeed draft-quinn-nsh ta= kes this exact approach. [UE] I=92ve looked at rev 01 and was not sure as it is not specific enough.= Between the definitions of the Service Path, Network Platform Context and = Service Platform Context provided in the draft and the GRE example, I was n= ot able to tell how close it is to the direction suggested above. If indeed= we are on the same page, I rest my case (and the associated email thread := )) while I=92d like to refrain judgement which approach is advantageous, I=92d= expect the WG will at least discuss it. The above text in the proposed cha= rter seems to stand against reviewing/discussing this point. Is this discus= sion not warranted? Has the pre-WG participants already determine a separat= e layer is a MUST? Jim> there seems to general consensus to postpone discussion beyond the cha= rter until after the WG is formed. [UE] just trying to ensure the charter ALLOWS for the above outlined option= . The architectural discussion can follow later Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 7:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network.Service delivery= is currently both a technical and organisational challenge that involves s= ignificant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_8E86B6E7C6FB9F40A00B0E269045A7C9211489D9xmbalnx09ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Uri,

There has been consensus to postpone the discussion that you are bring= ing (as I understand it) until after the WG is formed. At the risk of = inviting the wrath of Jim, comment inline.

Surendra.

From: <Elzur>, Uri <uri.elzur@intel.com>
Date: Tuesday, September 17, 2013 1= :26 PM
To: "Jim Guichard (jguichar)&q= uot; <jguichar@cisco.com>, = "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] New NSC WG Chart= er - charter bullet #3

Hi Jim

 

Thx for the quick resp= onse. Pls see below [UE]

 

Thx

 

Uri ("Oo-Ree")=

O: (949)-567-4519<= /span>

C: (949)-378-7568=

From:= mailto:j= guichar@cisco.com]
Sent: Tuesday, September 17, 2013 10:49 AM
To: Elzur, Uri; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=

 

Hi Uri,

 

Inline ..

 

From: <Elzur>, Uri <uri.elzur@intel.com>
Date: Tuesday, September 17, 2013 7:09 AM
To: Microsoft Office User <= jguichar@cisco.com>, "nsc@ietf.= org" <nsc@ietf.org>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=

 

Bullet 3 below suggests =93it is intended that the= encapsulation be agnostic to the network layer at which it is applied and = the service that is being constructed. That is, the same encapsulation may be used on a service function path realised= at the network layer or at any other layer, and the same encapsulation wil= l apply for the construction of service function paths regardless of the ac= tual service=94

This makes me wonder. I assume the intention of = the nsc WG is to provide services to some network nodes that reside in some= domain e.g. an overlay, or in some (single?) admin domain. Would it not be simpler and more natural to provide the serv= ice at that layer? It seems like the number of cases where a service is cen= tralized or offered across different admin domain than that of the consumin= g nodes, may be dwarfed by the cases where they co-reside, maybe in the sam= e row, maybe in the same rack or even on the same server. The incentive may be to localize the service clos= e to its consumer to reduce the network burden of carrying traffic unnecessarily over some distance. Virtualization and Virtual appliances may enable such pheno= menon.

Jim>  it is certainly true that different admi= nistrative domains may be present within a particular operators network and indeed those domains may be separately managed and t= herefore services may need to span multiple domains. However, I am confused= by your use of the term "layer". Within the charter when we refe= r to a layer we mean a layer of the protocol stack and not a layer of the network. We certainly don= 't mean to imply any form of network boundary or delineation. In addition, = nothing in the above prevents the service functions to be co-resident with workloa= ds. It just makes it general enough to address the broad range of deploymen= t scenarios. Given that "migration" is a killer-app of virtualiza= tion, service-overlay becomes critical.

 

[UE] let me try to be more specific. I=92d li= ke to make sure the Service Function Chain can be integrated within the ent= ity that provides the Network Overlay (for example for the simple case of a= single Admin domain and a single Network Overlay deployed here)

I=92m not trying to imply that the proposed c= harter presents the SFC as  a Network Layer. I=92m concerned about a s= eparate name space for Services (on top of that used for a Network Overlay = or any Transport already in use). Such use may increase the storage required in the network (Switch, Router, vSwitch = etc.) and in the Service devices.  Another concern relates to the SFC = header location. If it is a separate entity, it may mean that more info lik= e routing info be required, which may be separate from and duplicate of the routing info provided by a Tunnel/Ov= erlay). I=92d like to suggest the WG charter keeps the door open for extend= ing an existing Overly header to include the SFC info (which I think, the c= onsensus is that it is needed), as long as we talk about Service graph, service index etc.
SK> If you are talking about absorbing the service-specific informa= tion (or service-header to use a term for clarity) into the transports, suc= h as integrating all that into VXLAN header, it may be too early to talk ab= out it. However, it did come up earlier in the discussion as well and it is not the idea that we should be pursuin= g as it is fraught with issues and many attempts in the past have not succe= eded in similar efforts.

 

It seems like a by-product of creating an indepe= ndent Service layer with full encapsulation (i.e. header with some routing = info as well as other info related to the service graph and potentially service index number as proposed on the list) may cause a need for gateways every= where an overlay is used or everywhere the traffic needs to traverse those separate domains to get into the =93servic= e layer=94 .

Jim> again I think this may simply be a terminology mismatch. The overl= ay is simply the transport used to get packets to/from service functions an= d this overlay may or may not span administrative domains. Gateways may be necessary if translation at the service encapsula= tion layer is needed between domains. It is worth noting that the initial t= ask of the WG will be to work on single domain use cases only before tackli= ng any inter-domain dependencies.

[UE] Jim, not sure what =93overlay is= simply the transport=94 is ref= erred to in your comment above (existing Transport or a new one for the Services). Pls see my comment above, I hope we can in= clude the case where the Transport for the SFC may also be a Transport alre= ady in use (e.g. extending an overlay like VXLAN to become VXLAN+ or GR= E =3D> GRE+ etc.) vs. a completely new Transport

 

 

The WG can achieve the same goal by defining the= structure of the SFC headers to be added and make that format universal ac= ross any network layer. i.e. let=92s suggest some headers containing meta-data and service graph. The same structure ca= n be applied to any network layer, in essence extending its functionality, by the IE= TF WG that owns that layer, prime candidates will be overlays used in the c= ontext of Network Virtualization e.g. added to VXLAN, NVGRE, GRE or any oth= er layer. It can also allow creation of a dedicated Service layer OUTSIDE of such Transports or Overlays for th= ose who wish it, but does nothing to restrict the WG to such Service layer = ONLY. <= /o:p>

Jim> I think we are talking t= he same language and indeed draft-quinn-nsh takes this exact approach. = ;

[UE] I=92ve looked at rev 01 and was not sure= as it is not specific enough. Between the definitions of the Service Path,= Network Platform Context and Service Platform Context provided in the draf= t and the GRE example, I was not able to tell how close it is to the direction suggested above. If indeed we are= on the same page, I rest my case (and the associated email thread J)

 

while I=92d like to refrain judgement which appr= oach is advantageous, I=92d expect the WG will at least discuss it. The abo= ve text in the proposed charter seems to stand against reviewing/discussing this point. Is this discussion not warranted?= Has the pre-WG participants already determine a separate layer is a MUST?<= /span>

there seems to general consensus to postpone discus= sion beyond the charter until after the WG is formed.&nbs= p;

[UE] just trying to ensure the charter ALLOWS= for the above outlined option. The architectural discussion can follow lat= er

 

Thx

 =

Uri ("Oo-Ree")=

O: (949)-567-4519

C: (949)-378-7568= <= /o:p>

From:nsc-= bounces@ietf.org [mailto:nsc-bo= unces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 7:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the = routing area AD's and our IAB shepherd Joel Halpern over the last few days = to refine the NSC WG charter. The following is our proposal to the communit= y for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Functio= n Chaining (SFC) WG Charter=

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge= that involves significant modification to the network configuration.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups r= esponsible for the protocols being modified in coordination with this worki= ng group, but may be done in this working group after agreement with all the relevant WG chairs and responsi= ble ADs.

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG =

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

 --_000_8E86B6E7C6FB9F40A00B0E269045A7C9211489D9xmbalnx09ciscoc_-- From uri.elzur@intel.com Fri Sep 20 08:20: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 C0D8021F9A71 for ; Fri, 20 Sep 2013 08:20:17 -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 3IRy5gO9IV3a for ; Fri, 20 Sep 2013 08:20:09 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2503C21F9A49 for ; Fri, 20 Sep 2013 08:20:09 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 20 Sep 2013 08:17:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.90,945,1371106800"; d="scan'208,217";a="398692903" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by fmsmga001.fm.intel.com with ESMTP; 20 Sep 2013 08:20:05 -0700 Received: from orsmsx105.amr.corp.intel.com ([169.254.4.17]) by ORSMSX107.amr.corp.intel.com ([169.254.1.201]) with mapi id 14.03.0123.003; Fri, 20 Sep 2013 08:20:05 -0700 From: "Elzur, Uri" To: "Surendra Kumar (smkumar)" , "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0Q Date: Fri, 20 Sep 2013 15:20:05 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> In-Reply-To: <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: multipart/alternative; boundary="_000_7E05C330D7FD6D4FAD0728C46B8995856FDFFFEDORSMSX105amrcor_" MIME-Version: 1.0 Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 15:20:24 -0000 --_000_7E05C330D7FD6D4FAD0728C46B8995856FDFFFEDORSMSX105amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Surendra, All I'm not trying to have that discussion now. All I'm asking is to get the CH= ARTER such that it will allow it in the future Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, September 18, 2013 12:04 PM To: Elzur, Uri; Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Uri, There has been consensus to postpone the discussion that you are bringing (= as I understand it) until after the WG is formed. At the risk of inviting t= he wrath of Jim, comment inline. Surendra. From: , Uri > Date: Tuesday, September 17, 2013 1:26 PM To: "Jim Guichard (jguichar)" >, "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Hi Jim Thx for the quick response. Pls see below [UE] Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, September 17, 2013 10:49 AM To: Elzur, Uri; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Hi Uri, Inline .. From: , Uri > Date: Tuesday, September 17, 2013 7:09 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Bullet 3 below suggests "it is intended that the encapsulation be agnostic = to the network layer at which it is applied and the service that is being c= onstructed. That is, the same encapsulation may be used on a service functi= on path realised at the network layer or at any other layer, and the same e= ncapsulation will apply for the construction of service function paths rega= rdless of the actual service" This makes me wonder. I assume the intention of the nsc WG is to provide se= rvices to some network nodes that reside in some domain e.g. an overlay, or= in some (single?) admin domain. Would it not be simpler and more natural t= o provide the service at that layer? It seems like the number of cases wher= e a service is centralized or offered across different admin domain than th= at of the consuming nodes, may be dwarfed by the cases where they co-reside= , maybe in the same row, maybe in the same rack or even on the same server.= The incentive may be to localize the service close to its consumer to redu= ce the network burden of carrying traffic unnecessarily over some distance.= Virtualization and Virtual appliances may enable such phenomenon. Jim> it is certainly true that different administrative domains may be pre= sent within a particular operators network and indeed those domains may be = separately managed and therefore services may need to span multiple domains= . However, I am confused by your use of the term "layer". Within the charte= r when we refer to a layer we mean a layer of the protocol stack and not a = layer of the network. We certainly don't mean to imply any form of network = boundary or delineation. In addition, nothing in the above prevents the ser= vice functions to be co-resident with workloads. It just makes it general e= nough to address the broad range of deployment scenarios. Given that "migra= tion" is a killer-app of virtualization, service-overlay becomes critical. [UE] let me try to be more specific. I'd like to make sure the Service Func= tion Chain can be integrated within the entity that provides the Network Ov= erlay (for example for the simple case of a single Admin domain and a singl= e Network Overlay deployed here) I'm not trying to imply that the proposed charter presents the SFC as a Ne= twork Layer. I'm concerned about a separate name space for Services (on top= of that used for a Network Overlay or any Transport already in use). Such = use may increase the storage required in the network (Switch, Router, vSwit= ch etc.) and in the Service devices. Another concern relates to the SFC he= ader location. If it is a separate entity, it may mean that more info like = routing info be required, which may be separate from and duplicate of the r= outing info provided by a Tunnel/Overlay). I'd like to suggest the WG chart= er keeps the door open for extending an existing Overly header to include t= he SFC info (which I think, the consensus is that it is needed), as long as= we talk about Service graph, service index etc. SK> If you are talking about absorbing the service-specific information (or= service-header to use a term for clarity) into the transports, such as int= egrating all that into VXLAN header, it may be too early to talk about it. = However, it did come up earlier in the discussion as well and it is not the= idea that we should be pursuing as it is fraught with issues and many atte= mpts in the past have not succeeded in similar efforts. It seems like a by-product of creating an independent Service layer with fu= ll encapsulation (i.e. header with some routing info as well as other info = related to the service graph and potentially service index number as propos= ed on the list) may cause a need for gateways everywhere an overlay is used= or everywhere the traffic needs to traverse those separate domains to get = into the "service layer" . Jim> again I think this may simply be a terminology mismatch. The overlay i= s simply the transport used to get packets to/from service functions and th= is overlay may or may not span administrative domains. Gateways may be nece= ssary if translation at the service encapsulation layer is needed between d= omains. It is worth noting that the initial task of the WG will be to work = on single domain use cases only before tackling any inter-domain dependenci= es. [UE] Jim, not sure what "overlay is simply the transport" is referred to in= your comment above (existing Transport or a new one for the Services). Pls= see my comment above, I hope we can include the case where the Transport f= or the SFC may also be a Transport already in use (e.g. extending an overla= y like VXLAN to become VXLAN+ or GRE =3D> GRE+ etc.) vs. a completely new T= ransport The WG can achieve the same goal by defining the structure of the SFC heade= rs to be added and make that format universal across any network layer. i.e= . let's suggest some headers containing meta-data and service graph. The sa= me structure can be applied to any network layer, in essence extending its = functionality, by the IETF WG that owns that layer, prime candidates will b= e overlays used in the context of Network Virtualization e.g. added to VXLA= N, NVGRE, GRE or any other layer. It can also allow creation of a dedicated= Service layer OUTSIDE of such Transports or Overlays for those who wish it= , but does nothing to restrict the WG to such Service layer ONLY. Jim> I think we are talking the same language and indeed draft-quinn-nsh ta= kes this exact approach. [UE] I've looked at rev 01 and was not sure as it is not specific enough. B= etween the definitions of the Service Path, Network Platform Context and Se= rvice Platform Context provided in the draft and the GRE example, I was not= able to tell how close it is to the direction suggested above. If indeed w= e are on the same page, I rest my case (and the associated email thread :)) while I'd like to refrain judgement which approach is advantageous, I'd exp= ect the WG will at least discuss it. The above text in the proposed charter= seems to stand against reviewing/discussing this point. Is this discussion= not warranted? Has the pre-WG participants already determine a separate la= yer is a MUST? Jim> there seems to general consensus to postpone discussion beyond the cha= rter until after the WG is formed. [UE] just trying to ensure the charter ALLOWS for the above outlined option= . The architectural discussion can follow later Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 7:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network.Service delivery= is currently both a technical and organisational challenge that involves s= ignificant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_7E05C330D7FD6D4FAD0728C46B8995856FDFFFEDORSMSX105amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Surendra, All

I’m not trying t= o have that discussion now. All I’m asking is to get the CHARTER such= that it will allow it in the future

Thx

 

Uri ("Oo-Ree")

O: (949)-567-4519

C: (949)-3= 78-7568

From: Surendra Kumar (smkumar) [mailt= o:smkumar@cisco.com]
Sent: Wednesday, September 18, 2013 12:04 PM
To: Elzur, Uri; Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=

 

Uri,

 

There has been consensus to postpone the discussion that you are = bringing (as I understand it) until after the WG is formed. At the ris= k of inviting the wrath of Jim, comment inline.

 

Surendra.

 

From: <Elzur>, Uri <uri.elzur@intel.com>
Date: Tuesday, September 17, 2013 1:26 PM
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.or= g>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=

 

Hi Jim

 

Thx for the quick resp= onse. Pls see below [UE]

 

Thx<= /span>

 

Uri ("Oo-Ree")

O: (949)-567-4519

C: (949)-3= 78-7568

From: Jim Gui= chard (jguichar) [mailto:jguichar@cis= co.com]
Sent: Tuesday, September 17, 2013 10:49 AM
To: Elzur, Uri; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

 =

Hi Uri,

 

Inline ..

 

From: <Elzur>, Uri <uri.elzur@intel.com>
Date: Tuesday, September 17, 2013 7:09 AM
To: Microsoft Office User <= jguichar@cisco.com>, "nsc@ietf.= org" <nsc@ietf.org>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=

 

Bullet 3 below suggests “it is intended that= the encapsulation be agnostic to the network layer at which it is applied = and the service that is being constructed. That is, the same encapsulation may be used on a service function path realised= at the network layer or at any other layer, and the same encapsulation wil= l apply for the construction of service function paths regardless of the ac= tual service”

This makes me wonder. I assume the intention of = the nsc WG is to provide services to some network nodes that reside in some= domain e.g. an overlay, or in some (single?) admin domain. Would it not be simpler and more natural to provide the serv= ice at that layer? It seems like the number of cases where a service is cen= tralized or offered across different admin domain than that of the consumin= g nodes, may be dwarfed by the cases where they co-reside, maybe in the sam= e row, maybe in the same rack or even on the same server. The incentive may be to localize the service clos= e to its consumer to reduce the network burden of carrying traffic unnecessarily over some distance. Virtualization and Virtual appliances may enable such pheno= menon.

Jim>  it is certainly true that different admi= nistrative domains may be present within a particular operators network and indeed those domains may be separately managed and t= herefore services may need to span multiple domains. However, I am confused= by your use of the term "layer". Within the charter when we refe= r to a layer we mean a layer of the protocol stack and not a layer of the network. We certainly don= 't mean to imply any form of network boundary or delineation. In addition, = nothing in the above prevents the service functions to be co-resident with workloa= ds. It just makes it general enough to address the broad range of deploymen= t scenarios. Given that "migration" is a killer-app of virtualiza= tion, service-overlay becomes critical.

 

[UE] let me try to be more specific. I’= d like to make sure the Service Function Chain can be integrated within the= entity that provides the Network Overlay (for example for the simple case = of a single Admin domain and a single Network Overlay deployed here)

I’m not trying to imply that the propos= ed charter presents the SFC as  a Network Layer. I’m concerned a= bout a separate name space for Services (on top of that used for a Network = Overlay or any Transport already in use). Such use may increase the storage required in the network (Switch, Router, vSwitch = etc.) and in the Service devices.  Another concern relates to the SFC = header location. If it is a separate entity, it may mean that more info lik= e routing info be required, which may be separate from and duplicate of the routing info provided by a Tunnel/Ov= erlay). I’d like to suggest the WG charter keeps the door open for ex= tending an existing Overly header to include the SFC info (which I think, t= he consensus is that it is needed), as long as we talk about Service graph, service index etc.

SK> If you are talking abou= t absorbing the service-specific information (or service-header to use a te= rm for clarity) into the transports, such as integrating all that into VXLA= N header, it may be too early to talk about it. However, it did come up earlier in the discussion as well and it= is not the idea that we should be pursuing as it is fraught with issues an= d many attempts in the past have not succeeded in similar efforts.

 

It seems like a by-product of creating an indepe= ndent Service layer with full encapsulation (i.e. header with some routing = info as well as other info related to the service graph and potentially service index number as proposed on the list) may cause a need for gateways every= where an overlay is used or everywhere the traffic needs to traverse those separate domains to get into the “se= rvice layer” .

Jim> again I think this may simply be a terminology mismatch. The overl= ay is simply the transport used to get packets to/from service functions an= d this overlay may or may not span administrative domains. Gateways may be necessary if translation at the service encapsula= tion layer is needed between domains. It is worth noting that the initial t= ask of the WG will be to work on single domain use cases only before tackli= ng any inter-domain dependencies.=

[UE] Jim, not sure what “overla= y is simply the transport”= ; is referred to in your comment above (existing Transport or a new one for the Services). Pls see my comment above, I hope we can in= clude the case where the Transport for the SFC may also be a Transport alre= ady in use (e.g. extending an overlay like VXLAN to become VXLAN+ or GR= E =3D> GRE+ etc.) vs. a completely new Transport

 

 

The WG can achieve the same goal by defining the= structure of the SFC headers to be added and make that format universal ac= ross any network layer. i.e. let’s suggest some headers containing meta-data and service graph. The same structure ca= n be applied to any network layer, in essence extending its functionality, by the IE= TF WG that owns that layer, prime candidates will be overlays used in the c= ontext of Network Virtualization e.g. added to VXLAN, NVGRE, GRE or any oth= er layer. It can also allow creation of a dedicated Service layer OUTSIDE of such Transports or Overlays for th= ose who wish it, but does nothing to restrict the WG to such Service layer = ONLY.

Jim> I think we are talking t= he same language and indeed draft-quinn-nsh takes this exact approach. = ;

[UE] I’ve looked at rev 01 and was not = sure as it is not specific enough. Between the definitions of the Service P= ath, Network Platform Context and Service Platform Context provided in the = draft and the GRE example, I was not able to tell how close it is to the direction suggested above. If indeed we are= on the same page, I rest my case (and the associated email thread J)

 

while I’d like to refrain judgement which = approach is advantageous, I’d expect the WG will at least discuss it.= The above text in the proposed charter seems to stand against reviewing/discussing this point. Is this discussion not warranted?= Has the pre-WG participants already determine a separate layer is a MUST?<= /span>

Jim> <= span style=3D"font-size:10.5pt;color:red">there seems to general consensus = to postpone discussion beyond the charter until after the WG is formed. <= /span>

[UE] just trying to ensure the charter ALLOWS= for the above outlined option. The architectural discussion can follow lat= er

 

Thx<= /span>

 

Uri ("Oo-Ree")

O: (949)-567-4519

C: (949)-3= 78-7568

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 7:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the = routing area AD's and our IAB shepherd Joel Halpern over the last few days = to refine the NSC WG charter. The following is our proposal to the communit= y for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Functio= n Chaining (SFC) WG Charter=

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge= that involves significant modification to the network configuration.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups r= esponsible for the protocols being modified in coordination with this worki= ng group, but may be done in this working group after agreement with all the relevant WG chairs and responsi= ble ADs.

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG =

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_7E05C330D7FD6D4FAD0728C46B8995856FDFFFEDORSMSX105amrcor_-- From jguichar@cisco.com Fri Sep 20 08:58: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 213E321F9BB5 for ; Fri, 20 Sep 2013 08:58:51 -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=[AWL=-0.000, 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 4RnInH5gZk7S for ; Fri, 20 Sep 2013 08:58:45 -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 9D18121F9BF1 for ; Fri, 20 Sep 2013 08:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50518; q=dns/txt; s=iport; t=1379692721; x=1380902321; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=y6xRmr3gaZIgwpmGsJu6NIOvJGn+KVALiCdoCPtf9+g=; b=emu3I2CUNDU5rWbvalnM5D+cLURqPz5kS5mYNWJxS57QCqd/P5806SfI otT526IKEGgfmUxYJifoby/wDp6E8NCFBKGM48aLuc0wodMnA061VSC7Y QajtI5zyQ0L9THGie639V1MxIT0P8nr2YIhDGumui6sAiHSmI71LIv6nP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAKhvPFKtJV2c/2dsb2JhbABYA4JDRMJDgRoWdIIlAQEBBBoTOgsHEAIBCBEBAgEBASEBBgcyFAMGCAEBBA4FFIdxummOHBaBDxMBEAYBAg+DDYEAA5Qfg12RdoMkgWkIFw X-IronPort-AV: E=Sophos;i="4.90,945,1371081600"; d="scan'208,217";a="262469366" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 20 Sep 2013 15:58:33 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8KFwWnO022314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 15:58:32 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 10:58:32 -0500 From: "Jim Guichard (jguichar)" To: "Elzur, Uri" Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rE= Date: Fri, 20 Sep 2013 15:58:31 +0000 Message-ID: <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com>, <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_05271FBCBBE74261BC16AAEA55CA3C0Bciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 15:58:51 -0000 --_000_05271FBCBBE74261BC16AAEA55CA3C0Bciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Uri, I see no reason why the current charter does not allow for the points that = you have raised. Sent from my iPhone On Sep 20, 2013, at 11:20 AM, "Elzur, Uri" > wrote: Surendra, All I=92m not trying to have that discussion now. All I=92m asking is to get th= e CHARTER such that it will allow it in the future Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, September 18, 2013 12:04 PM To: Elzur, Uri; Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Uri, There has been consensus to postpone the discussion that you are bringing (= as I understand it) until after the WG is formed. At the risk of inviting t= he wrath of Jim, comment inline. Surendra. From: , Uri > Date: Tuesday, September 17, 2013 1:26 PM To: "Jim Guichard (jguichar)" >, "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Hi Jim Thx for the quick response. Pls see below [UE] Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, September 17, 2013 10:49 AM To: Elzur, Uri; nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Hi Uri, Inline .. From: , Uri > Date: Tuesday, September 17, 2013 7:09 AM To: Microsoft Office User >, = "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Bullet 3 below suggests =93it is intended that the encapsulation be agnosti= c to the network layer at which it is applied and the service that is being= constructed. That is, the same encapsulation may be used on a service func= tion path realised at the network layer or at any other layer, and the same= encapsulation will apply for the construction of service function paths re= gardless of the actual service=94 This makes me wonder. I assume the intention of the nsc WG is to provide se= rvices to some network nodes that reside in some domain e.g. an overlay, or= in some (single?) admin domain. Would it not be simpler and more natural t= o provide the service at that layer? It seems like the number of cases wher= e a service is centralized or offered across different admin domain than th= at of the consuming nodes, may be dwarfed by the cases where they co-reside= , maybe in the same row, maybe in the same rack or even on the same server.= The incentive may be to localize the service close to its consumer to redu= ce the network burden of carrying traffic unnecessarily over some distance.= Virtualization and Virtual appliances may enable such phenomenon. Jim> it is certainly true that different administrative domains may be pre= sent within a particular operators network and indeed those domains may be = separately managed and therefore services may need to span multiple domains= . However, I am confused by your use of the term "layer". Within the charte= r when we refer to a layer we mean a layer of the protocol stack and not a = layer of the network. We certainly don't mean to imply any form of network = boundary or delineation. In addition, nothing in the above prevents the ser= vice functions to be co-resident with workloads. It just makes it general e= nough to address the broad range of deployment scenarios. Given that "migra= tion" is a killer-app of virtualization, service-overlay becomes critical. [UE] let me try to be more specific. I=92d like to make sure the Service Fu= nction Chain can be integrated within the entity that provides the Network = Overlay (for example for the simple case of a single Admin domain and a sin= gle Network Overlay deployed here) I=92m not trying to imply that the proposed charter presents the SFC as a = Network Layer. I=92m concerned about a separate name space for Services (on= top of that used for a Network Overlay or any Transport already in use). S= uch use may increase the storage required in the network (Switch, Router, v= Switch etc.) and in the Service devices. Another concern relates to the SF= C header location. If it is a separate entity, it may mean that more info l= ike routing info be required, which may be separate from and duplicate of t= he routing info provided by a Tunnel/Overlay). I=92d like to suggest the WG= charter keeps the door open for extending an existing Overly header to inc= lude the SFC info (which I think, the consensus is that it is needed), as l= ong as we talk about Service graph, service index etc. SK> If you are talking about absorbing the service-specific information (or= service-header to use a term for clarity) into the transports, such as int= egrating all that into VXLAN header, it may be too early to talk about it. = However, it did come up earlier in the discussion as well and it is not the= idea that we should be pursuing as it is fraught with issues and many atte= mpts in the past have not succeeded in similar efforts. It seems like a by-product of creating an independent Service layer with fu= ll encapsulation (i.e. header with some routing info as well as other info = related to the service graph and potentially service index number as propos= ed on the list) may cause a need for gateways everywhere an overlay is used= or everywhere the traffic needs to traverse those separate domains to get = into the =93service layer=94 . Jim> again I think this may simply be a terminology mismatch. The overlay i= s simply the transport used to get packets to/from service functions and th= is overlay may or may not span administrative domains. Gateways may be nece= ssary if translation at the service encapsulation layer is needed between d= omains. It is worth noting that the initial task of the WG will be to work = on single domain use cases only before tackling any inter-domain dependenci= es. [UE] Jim, not sure what =93overlay is simply the transport=94 is referred t= o in your comment above (existing Transport or a new one for the Services).= Pls see my comment above, I hope we can include the case where the Transpo= rt for the SFC may also be a Transport already in use (e.g. extending an ov= erlay like VXLAN to become VXLAN+ or GRE =3D> GRE+ etc.) vs. a completely n= ew Transport The WG can achieve the same goal by defining the structure of the SFC heade= rs to be added and make that format universal across any network layer. i.e= . let=92s suggest some headers containing meta-data and service graph. The = same structure can be applied to any network layer, in essence extending it= s functionality, by the IETF WG that owns that layer, prime candidates will= be overlays used in the context of Network Virtualization e.g. added to VX= LAN, NVGRE, GRE or any other layer. It can also allow creation of a dedicat= ed Service layer OUTSIDE of such Transports or Overlays for those who wish = it, but does nothing to restrict the WG to such Service layer ONLY. Jim> I think we are talking the same language and indeed draft-quinn-nsh ta= kes this exact approach. [UE] I=92ve looked at rev 01 and was not sure as it is not specific enough.= Between the definitions of the Service Path, Network Platform Context and = Service Platform Context provided in the draft and the GRE example, I was n= ot able to tell how close it is to the direction suggested above. If indeed= we are on the same page, I rest my case (and the associated email thread := )) while I=92d like to refrain judgement which approach is advantageous, I=92d= expect the WG will at least discuss it. The above text in the proposed cha= rter seems to stand against reviewing/discussing this point. Is this discus= sion not warranted? Has the pre-WG participants already determine a separat= e layer is a MUST? Jim> there seems to general consensus to postpone discussion beyond the cha= rter until after the WG is formed. [UE] just trying to ensure the charter ALLOWS for the above outlined option= . The architectural discussion can follow later Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From:nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Friday, September 13, 2013 7:08 AM To: nsc@ietf.org Subject: [nsc] New NSC WG Charter Importance: High Greetings, We have been working with the routing area AD's and our IAB shepherd Joel H= alpern over the last few days to refine the NSC WG charter. The following i= s our proposal to the community for review and comment. Please note that as= an outcome of the various discussions on the list we are proposing that th= e WG name change from "Network Service Chaining (NSC)" to "Service Function= Chaining (SFC)". Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. The process of service delivery is= changing from the physical insertion of equipment on the path into a mecha= nism for causing the path or data to transit specific physical or virtual n= odes on which the service functions are performed. Services are typically i= mplemented by the ordered combination of a number of service functions that= may be implemented at different points within the network.Service delivery= is currently both a technical and organisational challenge that involves s= ignificant modification to the network configuration. For a given service, the abstracted view of the required service functions = and the order in which they are to be invoked is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a ServiceFunction Chain is instantiated via the s= election of specific service function instances and the network nodes on wh= ich they are provided, thereby forming a servicetopology: this is called a = Service Function Path. The service functions may be applied at a specific l= ayer within the network protocol stack (network layer, application layer, e= tc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment, by providing a framework for service= function chaining and the necessary protocols or protocol extensions to co= nvey the service path and for communication between nodes that implement se= rvice functions. The working group will also examine what information need= s to be gathered from the network and service functions in support of servi= ce function chaining and how that information may be made available to node= s that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Add= itionally, the WG will normalize nomenclature and definitions for service f= unction chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, and security models, as wel= l as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level encapsulation protocol for conveying the service= function chain and the service function path, and for communicating inform= ation between nodes that implement service functions. It is intended that t= he encapsulation be agnostic to thenetwork layer at which it is applied and= the service that is being constructed. That is, the same encapsulation may= be used on a service function path realised at the network layer or at any= other layer, and the same encapsulation willapply for the construction of = service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will = be used and extended. All protocol extensions work should be carried out in= the working groups responsible for the protocols being modified in coordin= ation with this working group, but may be done in this working group after = agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service func= tion chaining includingrelevant MIBs and YANG data modules, and service fun= ction chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. --_000_05271FBCBBE74261BC16AAEA55CA3C0Bciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Uri,
I see no reason why the current charter does not allow for the points = that you have raised.

Sent from my iPhone

On Sep 20, 2013, at 11:20 AM, "Elzur, Uri" <uri.elzur@intel.com> wrote:

Surendra, All

I=92m not trying to ha= ve that discussion now. All I=92m asking is to get the CHARTER such that it= will allow it in the future

Thx

 

Uri ("Oo-Ree")

O: (949)-567-4519

C: (949)-3= 78-7568

From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]
Sent: Wednesday, September 18, 2013 12:04 PM
To: Elzur, Uri; Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=

 

Uri,

 

There has been consensus to postpone the discussion that you are = bringing (as I understand it) until after the WG is formed. At the ris= k of inviting the wrath of Jim, comment inline.

 

Surendra.

 

From: <Elzur>, Uri <uri.elzur@intel.com>
Date: Tuesday, September 17, 2013 1:26 PM
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.or= g>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=

 

Hi Jim

 

Thx for the quick resp= onse. Pls see below [UE]

 

Thx<= /span>

 

Uri ("Oo-Ree")

O: (949)-567-4519

C: (949)-3= 78-7568

From: Jim Gui= chard (jguichar) [mailto:jguichar@cis= co.com]
Sent: Tuesday, September 17, 2013 10:49 AM
To: Elzur, Uri; nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

 =

Hi Uri,

 

Inline ..

 

From: <Elzur>, Uri <uri.elzur@intel.com>
Date: Tuesday, September 17, 2013 7:09 AM
To: Microsoft Office User <= jguichar@cisco.com>, "nsc@ietf.= org" <nsc@ietf.org>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=

 

Bullet 3 below suggests =93it is intended that the= encapsulation be agnostic to the network layer at which it is applied and = the service that is being constructed. That is, the same encapsulation may be used on a service function path realised= at the network layer or at any other layer, and the same encapsulation wil= l apply for the construction of service function paths regardless of the ac= tual service=94

This makes me wonder. I assume the intention of = the nsc WG is to provide services to some network nodes that reside in some= domain e.g. an overlay, or in some (single?) admin domain. Would it not be simpler and more natural to provide the serv= ice at that layer? It seems like the number of cases where a service is cen= tralized or offered across different admin domain than that of the consumin= g nodes, may be dwarfed by the cases where they co-reside, maybe in the sam= e row, maybe in the same rack or even on the same server. The incentive may be to localize the service clos= e to its consumer to reduce the network burden of carrying traffic unnecessarily over some distance. Virtualization and Virtual appliances may enable such pheno= menon.

Jim>  it is certainly true that different admi= nistrative domains may be present within a particular operators network and indeed those domains may be separately managed and t= herefore services may need to span multiple domains. However, I am confused= by your use of the term "layer". Within the charter when we refe= r to a layer we mean a layer of the protocol stack and not a layer of the network. We certainly don= 't mean to imply any form of network boundary or delineation. In addition, = nothing in the above prevents the service functions to be co-resident with workloa= ds. It just makes it general enough to address the broad range of deploymen= t scenarios. Given that "migration" is a killer-app of virtualiza= tion, service-overlay becomes critical.

 

[UE] let me try to be more specific. I=92d li= ke to make sure the Service Function Chain can be integrated within the ent= ity that provides the Network Overlay (for example for the simple case of a= single Admin domain and a single Network Overlay deployed here)

I=92m not trying to imply that the proposed c= harter presents the SFC as  a Network Layer. I=92m concerned about a s= eparate name space for Services (on top of that used for a Network Overlay = or any Transport already in use). Such use may increase the storage required in the network (Switch, Router, vSwitch = etc.) and in the Service devices.  Another concern relates to the SFC = header location. If it is a separate entity, it may mean that more info lik= e routing info be required, which may be separate from and duplicate of the routing info provided by a Tunnel/Ov= erlay). I=92d like to suggest the WG charter keeps the door open for extend= ing an existing Overly header to include the SFC info (which I think, the c= onsensus is that it is needed), as long as we talk about Service graph, service index etc.

SK> If you are talking abou= t absorbing the service-specific information (or service-header to use a te= rm for clarity) into the transports, such as integrating all that into VXLA= N header, it may be too early to talk about it. However, it did come up earlier in the discussion as well and it= is not the idea that we should be pursuing as it is fraught with issues an= d many attempts in the past have not succeeded in similar efforts.

 

It seems like a by-product of creating an indepe= ndent Service layer with full encapsulation (i.e. header with some routing = info as well as other info related to the service graph and potentially service index number as proposed on the list) may cause a need for gateways every= where an overlay is used or everywhere the traffic needs to traverse those separate domains to get into the =93servic= e layer=94 .

Jim> again I think this may simply be a terminology mismatch. The overl= ay is simply the transport used to get packets to/from service functions an= d this overlay may or may not span administrative domains. Gateways may be necessary if translation at the service encapsula= tion layer is needed between domains. It is worth noting that the initial t= ask of the WG will be to work on single domain use cases only before tackli= ng any inter-domain dependencies.=

[UE] Jim, not sure what =93overlay is= simply the transport=94 is ref= erred to in your comment above (existing Transport or a new one for the Services). Pls see my comment above, I hope we can in= clude the case where the Transport for the SFC may also be a Transport alre= ady in use (e.g. extending an overlay like VXLAN to become VXLAN+ or GR= E =3D> GRE+ etc.) vs. a completely new Transport

 

 

The WG can achieve the same goal by defining the= structure of the SFC headers to be added and make that format universal ac= ross any network layer. i.e. let=92s suggest some headers containing meta-data and service graph. The same structure ca= n be applied to any network layer, in essence extending its functionality, by the IE= TF WG that owns that layer, prime candidates will be overlays used in the c= ontext of Network Virtualization e.g. added to VXLAN, NVGRE, GRE or any oth= er layer. It can also allow creation of a dedicated Service layer OUTSIDE of such Transports or Overlays for th= ose who wish it, but does nothing to restrict the WG to such Service layer = ONLY.

Jim> I think we are talking t= he same language and indeed draft-quinn-nsh takes this exact approach. = ;

[UE] I=92ve looked at rev 01 and was not sure= as it is not specific enough. Between the definitions of the Service Path,= Network Platform Context and Service Platform Context provided in the draf= t and the GRE example, I was not able to tell how close it is to the direction suggested above. If indeed we are= on the same page, I rest my case (and the associated email thread J)

 

while I=92d like to refrain judgement which appr= oach is advantageous, I=92d expect the WG will at least discuss it. The abo= ve text in the proposed charter seems to stand against reviewing/discussing this point. Is this discussion not warranted?= Has the pre-WG participants already determine a separate layer is a MUST?<= /span>

Jim> <= span style=3D"font-size:10.5pt;color:red">there seems to general consensus = to postpone discussion beyond the charter until after the WG is formed. <= /span>

[UE] just trying to ensure the charter ALLOWS= for the above outlined option. The architectural discussion can follow lat= er

 

Thx<= /span>

 

Uri ("Oo-Ree")

O: (949)-567-4519

C: (949)-3= 78-7568

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 7:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

 

Greetings,

 

We have been working with the = routing area AD's and our IAB shepherd Joel Halpern over the last few days = to refine the NSC WG charter. The following is our proposal to the communit= y for review and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)". 

 

Proposed Service Functio= n Chaining (SFC) WG Charter=

 

Networks, servers, storage technologies, and appli= cations, have all undergone significant change in recent years with the int= roduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge= that involves significant modification to the network configuration.

For a given service, the abstracted view of the re= quired service functions and the order in which they are to be invoked is c= alled a Service Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group = will develop new approaches to service delivery and deployment, by providin= g a framework for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.&n= bsp; The working group will also examine what information needs to be gathe= red from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver t= he following: 

1) Problem Statement: This document will provide a= summary of the problem space to be addressed by the WG including example h= igh-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a desc= ription of the architectural building blocks and their relationships includ= ing interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation= : A document will describe the single service-level encapsulation protocol = for conveying the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents wi= ll be developed to describe requirements and protocols necessary to convey = information to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups r= esponsible for the protocols being modified in coordination with this worki= ng group, but may be done in this working group after agreement with all the relevant WG chairs and responsi= ble ADs.

5) Manageability: This document will address the m= anagement of service function chaining includingrelevant MIBs and YANG data= modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):

Request the IESG for publication of an Information= al document defining the problem statement and core use cases for Service F= unction Chaining

Request the IESG for publication of Informational = documents defining the architecture for SFC and describing the framework an= d requirements for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Tr= ack document specifying the generic service function chaining encapsulation= protocol.

Request the IESG for publication of Informational = documents specifying control plane requirements in support of specific SFC = use cases.

Request the IESG for publication of an Information= al document defining SFC manageability including diagnostics, and MIB and Y= ANG data models to IESG =

Request the IESG for publication of Informational = applicability documents defining how the protocol elements developed by the= WG may be combined with other IETF protocols to satisfy the use cases.

 

 

--_000_05271FBCBBE74261BC16AAEA55CA3C0Bciscocom_-- From ghanwani@gmail.com Fri Sep 20 12:34: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 284AE21F8267 for ; Fri, 20 Sep 2013 12:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Xl4AEQ6oDQGV for ; Fri, 20 Sep 2013 12:34:02 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4B121F9DD0 for ; Fri, 20 Sep 2013 12:34:00 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id t60so928488wes.22 for ; Fri, 20 Sep 2013 12:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=neqBr6b8fjmVa4NY75WGRLgdOXYHMRE0YibU//WO8TE=; b=fqbApE9eBbkwhaahBq6eEHT23/WdnAZCuIexrY/wnd1xhsm2YfJ8bMt8WoSGEkGk/W 83bfHJfYsdkVwbqvOQIXyow+8zgzadUAHPAEoCBBDjbWNBq3ti2yfY/WCTY9GUqJHnni GzYb32sD22hvgMgECKn+pz8fzxxxIVgxwdknTRTqZ7tenq9508T+HKlXITmAAsB9YpGl y+ObrSMHCzZoaLgi1HwwsjErHRCc56PzijqKYgWG/J7C1R/tpswatyu6q/R5MZhe8Ky+ fkoDCHWNTHIGYq2ODItW8UFPwKahNRVRXv2LzGe2IdZsjlcqEIMpEkOEY/Cz80M9b0L2 IjUw== MIME-Version: 1.0 X-Received: by 10.180.74.164 with SMTP id u4mr3966215wiv.17.1379705640266; Fri, 20 Sep 2013 12:34:00 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.217.54.6 with HTTP; Fri, 20 Sep 2013 12:34:00 -0700 (PDT) In-Reply-To: <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> Date: Fri, 20 Sep 2013 12:34:00 -0700 X-Google-Sender-Auth: yOLE_3wy97MicZatUk7rwM42XDI Message-ID: From: Anoop Ghanwani To: "Jim Guichard (jguichar)" Content-Type: multipart/alternative; boundary=f46d043c7f5695335d04e6d5c058 Cc: "Elzur, Uri" , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 19:34:04 -0000 --f46d043c7f5695335d04e6d5c058 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My interpretation of the following line: >>> A document will describe the single service-level encapsulation protocol for conveying the service function chain and the service function path >>> is that there will be a single encapsulation protocol at the "service layer". Are we saying that there could be more than one way of carrying this header but that the contents would be the same? Would the output of this WG would allow the creation of a service chain even when overlays are not in use? (This is not clear from reading the charter.) Finally, is the work intended to support chains of both transparent and non-transparent appliances, or is the focus mainly on transparent appliances? I ask because there may be interesting layering issues with respect to the placement of this header, especially if we have a combination of transparent and non-transparent appliances. Anoop On Fri, Sep 20, 2013 at 8:58 AM, Jim Guichard (jguichar) wrote: > Hi Uri, > I see no reason why the current charter does not allow for the points tha= t > you have raised. > > Sent from my iPhone > > On Sep 20, 2013, at 11:20 AM, "Elzur, Uri" wrote: > > Surendra, All**** > > I=92m not trying to have that discussion now. All I=92m asking is to get = the > CHARTER such that it will allow it in the future**** > > Thx**** > > **** > > Uri ("Oo-Ree")**** > > O: (949)-567-4519**** > > C: (949)-378-7568**** > > *From:* Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > *Sent:* Wednesday, September 18, 2013 12:04 PM > *To:* Elzur, Uri; Jim Guichard (jguichar); nsc@ietf.org > *Subject:* Re: [nsc] New NSC WG Charter - charter bullet #3**** > > ** ** > > Uri,**** > > ** ** > > There has been consensus to postpone the discussion that you are bringing > (as I understand it) until after the WG is formed. At the risk of invitin= g > the wrath of Jim, comment inline.**** > > ** ** > > Surendra.**** > > ** ** > > *From: *, Uri > *Date: *Tuesday, September 17, 2013 1:26 PM > *To: *"Jim Guichard (jguichar)" , "nsc@ietf.org" < > nsc@ietf.org> > *Subject: *Re: [nsc] New NSC WG Charter - charter bullet #3**** > > ** ** > > Hi Jim**** > > **** > > Thx for the quick response. Pls see below [UE]**** > > **** > > Thx**** > > **** > > Uri ("Oo-Ree")**** > > O: (949)-567-4519**** > > C: (949)-378-7568**** > > *From:* Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > *Sent:* Tuesday, September 17, 2013 10:49 AM > *To:* Elzur, Uri; nsc@ietf.org > *Subject:* Re: [nsc] New NSC WG Charter - charter bullet #3**** > > **** > > Hi Uri,**** > > **** > > Inline ..**** > > **** > > *From: *, Uri > *Date: *Tuesday, September 17, 2013 7:09 AM > *To: *Microsoft Office User , "nsc@ietf.org" < > nsc@ietf.org> > *Subject: *Re: [nsc] New NSC WG Charter - charter bullet #3**** > > **** > > Bullet 3 below suggests =93it is intended that the encapsulation be agnos= tic > to the network layer at which it is applied and the service that is being > constructed. That is, the same encapsulation may be used on a service > function path realised at the network layer or at any other layer, and th= e > same encapsulation will apply for the construction of service function > paths regardless of the actual service=94**** > > This makes me wonder. I assume the intention of the nsc WG is to provide > services to some network nodes that reside in some domain e.g. an overlay= , > or in some (single?) admin domain. Would it not be simpler and more natur= al > to provide the service * at that layer*? It seems like the number of > cases where a service is centralized or offered across different admin > domain than that of the consuming nodes, may be dwarfed by the cases wher= e > they co-reside, maybe in the same row, maybe in the same rack or even on > the same server. The incentive may be to localize the service close to it= s > consumer to reduce the network burden of carrying traffic unnecessarily > over some distance. Virtualization and Virtual appliances may enable such > phenomenon.**** > > Jim> it is certainly true that different administrative domains may be > present within a particular operators network and indeed those domains ma= y > be separately managed and therefore services may need to span multiple > domains. However, I am confused by your use of the term "layer". Within t= he > charter when we refer to a layer we mean a layer of the protocol stack an= d > not a layer of the network. We certainly don't mean to imply any form of > network boundary or delineation. In addition, nothing in the above > prevents the service functions to be co-resident with workloads. It just > makes it general enough to address the broad range of deployment scenario= s. > Given that "migration" is a killer-app of virtualization, service-overlay > becomes critical.**** > > **** > > [UE] let me try to be more specific. I=92d like to make sure the Service > Function Chain can be integrated within the entity that provides the > Network Overlay (for example for the simple case of a single Admin domain > and a single Network Overlay deployed here)**** > > I=92m not trying to imply that the proposed charter presents the SFC as = a > Network Layer. I=92m concerned about a separate name space for Services (= on > top of that used for a Network Overlay or any Transport already in use). > Such use may increase the storage required in the network (Switch, Router= , > vSwitch etc.) and in the Service devices. Another concern relates to the > SFC header location. If it is a separate entity, it may mean that more in= fo > like routing info be required, which may be separate from and duplicate o= f > the routing info provided by a Tunnel/Overlay). I=92d like to suggest the= WG > charter keeps the door open for extending an existing Overly header to > include the SFC info (which I think, the consensus is that it is needed), > as long as we talk about Service graph, service index etc.**** > > SK> If you are talking about absorbing the service-specific information > (or service-header to use a term for clarity) into the transports, such a= s > integrating all that into VXLAN header, it may be too early to talk about > it. However, it did come up earlier in the discussion as well and it is n= ot > the idea that we should be pursuing as it is fraught with issues and many > attempts in the past have not succeeded in similar efforts.**** > > **** > > It seems like a by-product of creating an independent Service layer with > full encapsulation (i.e. header with some routing info as well as other > info related to the service graph and potentially service index number as= proposed > on the list) may cause a need for gateways everywhere an overlay is used = or > everywhere the traffic needs to traverse those separate domains to get in= to > the =93service layer=94 .**** > > Jim> again I think this may simply be a terminology mismatch. The overlay > is simply the transport used to get packets to/from service functions and > this overlay may or may not span administrative domains. Gateways may be > necessary if translation at the service encapsulation layer is needed > between domains. It is worth noting that the initial task of the WG will = be > to work on single domain use cases only before tackling any inter-domain > dependencies.**** > > [UE] Jim, not sure what =93overlay is simply the transport=94 is referred= to > in your comment above (existing Transport or a new one for the Services). > Pls see my comment above, I hope we can include the case where the > Transport for the SFC may also be a Transport already in use (e.g. > extending an overlay like VXLAN to become VXLAN+ or GRE =3D> GRE+ etc.) v= s. a > completely new Transport**** > > **** > > **** > > The WG can achieve the same goal by defining the structure of the SFC > headers to be added and make that format universal across any network > layer. i.e. let=92s suggest some headers containing meta-data and service > graph. The same structure can be applied to *any* network layer, in > essence extending its functionality, by the IETF WG that owns that layer, > prime candidates will be overlays used in the context of Network > Virtualization e.g. added to VXLAN, NVGRE, GRE or any other layer. It can > also allow creation of a dedicated Service layer OUTSIDE of such Transpor= ts > or Overlays for those who wish it, but does nothing to restrict the WG to > such Service layer ONLY. **** > > Jim> I think we are talking the same language and indeed draft-quinn-nsh > takes this exact approach. **** > > [UE] I=92ve looked at rev 01 and was not sure as it is not specific enoug= h. > Between the definitions of the Service Path, Network Platform Context and > Service Platform Context provided in the draft and the GRE example, I was > not able to tell how close it is to the direction suggested above. If > indeed we are on the same page, I rest my case (and the associated email > thread J)**** > > **** > > while I=92d like to refrain judgement which approach is advantageous, I= =92d > expect the WG will at least discuss it. The above text in the proposed > charter seems to stand against reviewing/discussing this point. Is this > discussion not warranted? Has the pre-WG participants already determine a > separate layer is a MUST?**** > > Jim> there seems to general consensus to postpone discussion beyond the > charter until after the WG is formed. **** > > [UE] just trying to ensure the charter ALLOWS for the above outlined > option. The architectural discussion can follow later**** > > **** > > Thx**** > > **** > > Uri ("Oo-Ree")**** > > O: (949)-567-4519**** > > C: (949)-378-7568**** > > *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] > *On Behalf Of *Jim Guichard (jguichar) > *Sent:* Friday, September 13, 2013 7:08 AM > *To:* nsc@ietf.org > *Subject:* [nsc] New NSC WG Charter > *Importance:* High**** > > **** > > Greetings,**** > > **** > > We have been working with the routing area AD's and our IAB shepherd Joel > Halpern over the last few days to refine the NSC WG charter. The followin= g > is our proposal to the community for review and comment. Please note that > as an outcome of the various discussions on the list we are proposing tha= t > the WG name change from "Network Service Chaining (NSC)" to "Service > Function Chaining (SFC)". **** > > **** > > *Proposed Service Function Chaining (SFC) WG Charter***** > > **** > > Networks, servers, storage technologies, and applications, have all > undergone significant change in recent years with the introduction of > virtualization, network overlays, and orchestration. The process of servi= ce > delivery is changing from the physical insertion of equipment on the path > into a mechanism for causing the path or data to transit specific physica= l > or virtual nodes on which the service functions are performed. Services a= re > typically implemented by the ordered combination of a number of service > functions that may be implemented at different points within the > network.Service delivery is currently both a technical and organisational > challenge that involves significant modification to the network > configuration.**** > > For a given service, the abstracted view of the required service function= s > and the order in which they are to be invoked is called a Service Functio= n > Chain (SFC). Since a given service function may be available on more than > one node within a network, a ServiceFunction Chain is instantiated via th= e > selection of specific service function instances and the network nodes on > which they are provided, thereby forming a servicetopology: this is calle= d > a Service Function Path. The service functions may be applied at a specif= ic > layer within the network protocol stack (network layer, application layer= , > etc.).**** > > The Service Function Chaining (SFC) working group will develop new > approaches to service delivery and deployment, by providing a framework f= or > service function chaining and the necessary protocols or protocol > extensions to convey the service path and for communication between nodes > that implement service functions. The working group will also examine wh= at > information needs to be gathered from the network and service functions i= n > support of service function chaining and how that information may be made > available to nodes that implement the service functions.**** > > Specifically, the SFC WG is chartered to deliver the following: **** > > 1) Problem Statement: This document will provide a summary of the problem > space to be addressed by the WG including example high-level use cases. > Additionally, the WG will normalize nomenclature and definitions for > service function chaining.**** > > 2) Architecture: This document will provide a description of the > architectural building blocks and their relationships including > interconnection, placement of capabilities, management, diagnostics, and > security models, as well as requirements on the protocol mechanisms.**** > > 3) Generic Service Function Chaining Encapsulation: A document will > describe the single service-level encapsulation protocol for conveying th= e > service function chain and the service function path, and for communicati= ng > information between nodes that implement service functions. It is intende= d > that the encapsulation be agnostic to thenetwork layer at which it is > applied and the service that is being constructed. That is, the same > encapsulation may be used on a service function path realised at the > network layer or at any other layer, and the same encapsulation willapply > for the construction of service function paths regardless of the actual > service.**** > > 4) Control Plane Mechanisms: A set of documents will be developed to > describe requirements and protocols necessary to convey information to > service function implementation points. Where possible, existing IETF > protocols will be used and extended. All protocol extensions work should = be > carried out in the working groups responsible for the protocols being > modified in coordination with this working group, but may be done in this > working group after agreement with all the relevant WG chairs and > responsible ADs.**** > > 5) Manageability: This document will address the management of service > function chaining includingrelevant MIBs and YANG data modules, and servi= ce > function chaining diagnostics.**** > > Proposed Milestones (all dates TBD):**** > > Request the IESG for publication of an Informational document defining th= e > problem statement and core use cases for Service Function Chaining**** > > Request the IESG for publication of Informational documents defining the > architecture for SFC and describing the framework and requirements for a > generic service function chaining encapsulation protocol.**** > > Request the IESG for publication of a Standards Track document specifying > the generic service function chaining encapsulation protocol.**** > > Request the IESG for publication of Informational documents specifying > control plane requirements in support of specific SFC use cases.**** > > Request the IESG for publication of an Informational document defining SF= C > manageability including diagnostics, and MIB and YANG data models to IESG > **** > > Request the IESG for publication of Informational applicability documents > defining how the protocol elements developed by the WG may be combined wi= th > other IETF protocols to satisfy the use cases.**** > > **** > > **** > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > > --f46d043c7f5695335d04e6d5c058 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
My interpretation of the following line:
>>><= /div>
A document will describe the= single service-level encapsulation protocol for conveying the service func= tion chain and the service function path
>>>
is that there will be a single enca= psulation protocol at the "service layer". Are we saying that the= re could be more than one way of carrying this header but that the contents= would be the same?

Would the output of this WG would allow the creat= ion of a service chain even when overlays are not in use? =A0(This is not c= lear from reading the charter.)

Finally, is the work intended to support ch= ains of both transparent and non-transparent appliances, or is the focus ma= inly on transparent appliances? =A0I ask because there may be interesting l= ayering issues with respect to the placement of this header, especially if = we have a combination of transparent and non-transparent appliances.=

Anoop


On Fri, Sep 2= 0, 2013 at 8:58 AM, Jim Guichard (jguichar) <jguichar@cisco.com>= wrote:
Hi Uri,
I see no reason why the current charter does not allow for the points = that you have raised.

Sent from my iPhone

On Sep 20, 2013, at 11:20 AM, "Elzur, Uri" <uri.elzur@intel.com> wrote:

Surendra, All

I=92m not trying to ha= ve that discussion now. All I=92m asking is to get the CHARTER such that it= will allow it in the future

Thx=

=A0

Uri ("Oo-Ree")

O: (949)-567-4519

C: (949)-= 378-7568

From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com<= /a>]
Sent: Wednesday, September 18, 2013 12:04 PM
To: Elzur, Uri; Jim Guichard (jguichar); nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3<= /u>

=A0

Ur= i,

=A0

Th= ere has been consensus to postpone the discussion that you are bringing (as= I understand it) until after the WG is formed.=A0At the risk of inviting t= he wrath of Jim, comment inline.

=A0

Su= rendra.

=A0

From: <Elzu= r>, Uri <uri= .elzur@intel.com>
Date: Tuesday, September 17, 2013 1:26 PM
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3<= /u>

=A0

Hi Jim

=A0=

Thx for the quick resp= onse. Pls see below [UE]<= /span>

=A0=

Thx

=A0

Uri ("Oo-Ree")=

O: (949)-567-4519

C: (949)-= 378-7568

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com= ]
Sent: Tuesday, September 17, 2013 10:49 AM
To: Elzur, Uri; ns= c@ietf.org
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

=A0

Hi= Uri,

= =A0

In= line ..

= =A0

From: <Elzu= r>, Uri <uri= .elzur@intel.com>
Date: Tuesday, September 17, 2013 7:09 AM
To: Microsoft Office User <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3<= /u>

= =A0

Bullet 3 below suggests =93it is intended that the encapsulati= on be agnostic to the network layer at which it is applied and the service = that is being constructed. That is, the same encapsulation may be used on a service function path realised= at the network layer or at any other layer, and the same encapsulation wil= l apply for the construction of service function paths regardless of the ac= tual service=94

This makes me wonder. I assume the intention of = the nsc WG is to provide services to some network nodes that reside in some= domain e.g. an overlay, or in some (single?) admin domain. Would it not be simpler and more natural to provide the serv= ice at that layer? It seems like the number of cases where a service is cen= tralized or offered across different admin domain than that of the consumin= g nodes, may be dwarfed by the cases where they co-reside, maybe in the sam= e row, maybe in the same rack or even on the same server. The incentive may be to localize the service clos= e to its consumer to reduce the network burden of carrying traffic=A0unne= cessarily over some distance. Virtualization and Virtual appliances may enable such pheno= menon.

Jim>=A0=A0it is certainly true that= different administrative domains may be present within a particular operators network and indeed those domains may be separately managed and t= herefore services may need to span multiple domains. However, I am confused= by your use of the term "layer". Within the charter when we refe= r to a layer we mean a layer of the protocol stack and not a layer of the network.=A0We certainly don't mean to imply any form = of network boundary or delineation. In addition, nothing in the above prevents the service functions to be co-resident with workloa= ds. It just makes it general enough to address the broad range of deploymen= t scenarios. Given that "migration" is a killer-app of virtualiza= tion, service-overlay becomes critical.=

=A0

[UE] let me try to be more specific. I=92d li= ke to make sure the Service Function Chain can be integrated within the ent= ity that provides the Network Overlay (for example for the simple case of a= single Admin domain and a single Network Overlay deployed here)

I=92m not trying to imply that the proposed c= harter presents the SFC as =A0a Network Layer. I=92m concerned about a sepa= rate name space for Services (on top of that used for a Network Overlay or = any Transport already in use). Such use may increase the storage required in the network (Switch, Router, vSwitch = etc.) and in the Service devices.=A0 Another concern relates to the SFC hea= der location. If it is a separate entity, it may mean that more info like r= outing info be required, which may be separate from and duplicate of the routing info provided by a Tunnel/Ov= erlay). I=92d like to suggest the WG charter keeps the door open for extend= ing an existing Overly header to include the SFC info (which I think, the c= onsensus is that it is needed), as long as we talk about Service graph, service index etc.=

SK> If you are talking about absorbing = the service-specific information (or service-header to use a term for clari= ty) into the transports, such as integrating all that into VXLAN header, it= may be too early to talk about it. However, it did come up earlier in the discussion as well and it= is not the idea that we should be pursuing as it is fraught with issues an= d many attempts in the past have not succeeded in similar efforts.

=A0

It seems like a by-product of creating an indepe= ndent Service layer with full encapsulation (i.e. header with some routing = info as well as other info related to the service graph and potentially service index number as=A0<= span style=3D"font-size:10.5pt;line-height:115%;color:#376092">proposed on = the list) may cause a need for gateways everywhere an overlay is used or ev= erywhere the traffic needs to traverse those separate domains to get into the =93servic= e layer=94 .

Jim> again I think this= may simply be a terminology mismatch. The overlay is simply the transport = used to get packets to/from service functions and this overlay may or may n= ot span administrative domains. Gateways may be necessary if translation at the service encapsula= tion layer is needed between domains. It is worth noting that the initial t= ask of the WG will be to work on single domain use cases only before tackli= ng any inter-domain dependencies.

[UE] Jim, not sure what =93overlay is simply the transport=94 is referred to in your comment ab= ove (existing Transport or a new one for the Services). Pls see my comment above, I hope we can in= clude the case where the Transport for the SFC may also be a Transport alre= ady in use (e.g. extending an overlay like VXLAN to become VXLAN+ or GRE = =3D> GRE+ etc.) vs. a completely new Transport

=A0

=A0

The WG can achieve the same goal by defining the= structure of the SFC headers to be added and make that format universal ac= ross any network layer. i.e. let=92s suggest some headers containing meta-data and service graph. The same structure ca= n be applied to any network layer, in essence extending its functionality, by the IE= TF WG that owns that layer, prime candidates will be overlays used in the c= ontext of Network Virtualization e.g. added to VXLAN, NVGRE, GRE or any oth= er layer. It can also allow creation of a dedicated Service layer OUTSIDE of such Transports or Overlays for th= ose who wish it, but does nothing to restrict the WG to such Service layer = ONLY.

Jim> I think we are talking t= he same language and indeed draft-quinn-nsh takes this exact approach.=A0

[UE] I=92ve looked at rev 01 and was not sure= as it is not specific enough. Between the definitions of the Service Path,= Network Platform Context and Service Platform Context provided in the draf= t and the GRE example, I was not able to tell how close it is to the direction suggested above. If indeed we are= on the same page, I rest my case (and the associated email thread J)

=A0

while I=92d like to refrain judgement which appr= oach is advantageous, I=92d expect the WG will at least discuss it. The abo= ve text in the proposed charter seems to stand against reviewing/discussing this point. Is this discussion not warranted?= Has the pre-WG participants already determine a separate layer is a MUST?<= /span>

Jim>=A0there seems to general consensus to postpone discussion beyond = the charter until after the WG is formed.=A0

[UE] just trying to ensure the charter ALLOWS= for the above outlined option. The architectural discussion can follow lat= er

=A0

Thx

=A0

Uri ("Oo-Ree")=

O: (949)-567-4519

C: (949)-= 378-7568

From:nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 7:08 AM
To: nsc@ietf.org
Subject: [nsc] New NSC WG Charter
Importance: High

=A0

Greetings,

=A0

We have been working with the routing area= AD's and our IAB shepherd Joel Halpern over the last few days to refin= e the NSC WG charter. The following is our proposal to the community for re= view and comment. Please note that as an outcome of the various discussions on the list we are proposing= that the WG name change from "Network Service Chaining (NSC)" to= "Service Function Chaining (SFC)".=A0<= u>

=A0

Proposed Service Function Chaining (= SFC) WG Charter

=A0

Networks, servers, storage technologies, and applications, hav= e all undergone significant change in recent years with the introduction of= virtualization, network overlays, and orchestration. The process of service delivery is changing from the ph= ysical insertion of equipment on the path into a mechanism for causing the = path or data to transit specific physical or virtual nodes on which the ser= vice functions are performed. Services are typically implemented by the ordered combination of a number of servic= e functions that may be implemented at different points within the network.= Service delivery is currently both a technical and organisational challenge= that involves significant modification to the network configuration.

For a given service, the abstracted view of the required servi= ce functions and the order in which they are to be invoked is called a Serv= ice Function Chain (SFC). Since a given service function may be available on more than one node with= in a network, a ServiceFunction Chain is instantiated via the selection of = specific service function instances and the network nodes on which they are= provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be appli= ed at a specific layer within the network protocol stack (network layer, ap= plication layer, etc.).

The Service Function Chaining (SFC) working group will develop= new approaches to service delivery and deployment, by providing a framewor= k for service function chaining and the necessary protocols or protocol extensions to convey the service p= ath and for communication between nodes that implement service functions.= =A0 The working group will also examine what information needs to be gather= ed from the network and service functions in support of service function chaining and how that information may be ma= de available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver the following= :=A0

1) Problem Statement: This document will provide a summary of = the problem space to be addressed by the WG including example high-level us= e cases. =A0Additionally, the WG will normalize nomenclature and definitions for service function chaini= ng.

2) Architecture: This document will provide a description of t= he architectural building blocks and their relationships including intercon= nection, placement of capabilities, management, diagnostics, and security models, as well as requirements on t= he protocol mechanisms.

3) Generic Service Function Chaining Encapsulation: A document= will describe the single service-level encapsulation protocol for conveyin= g the service function chain and the service function path, and for communicating information between n= odes that implement service functions. It is intended that the encapsulatio= n be agnostic to thenetwork layer at which it is applied and the service th= at is being constructed. That is, the same encapsulation may be used on a service function path realised at = the network layer or at any other layer, and the same encapsulation willapp= ly for the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents will be develo= ped to describe requirements and protocols necessary to convey information = to service function implementation points. Where possible, existing IETF protocols will be used and extended.= All protocol extensions work should be carried out in the working groups r= esponsible for the protocols being modified in coordination with this worki= ng group, but may be done in this working group after agreement with all the relevant WG chairs and responsi= ble ADs.

5) Manageability: This document will address the management of= service function chaining includingrelevant MIBs and YANG data modules, an= d service function chaining diagnostics.

Proposed Milestones (all dates TBD):=

Request the IESG for publication of an Informational document = defining the problem statement and core use cases for Service Function Chai= ning

Request the IESG for publication of Informational documents de= fining the architecture for SFC and describing the framework and requiremen= ts for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Track document= specifying the generic service function chaining encapsulation protocol.

Request the IESG for publication of Informational documents sp= ecifying control plane requirements in support of specific SFC use cases.

Request the IESG for publication of an Informational document = defining SFC manageability including diagnostics, and MIB and YANG data mod= els to IESG=A0

Request the IESG for publication of Informational applicabilit= y documents defining how the protocol elements developed by the WG may be c= ombined with other IETF protocols to satisfy the use cases.

=A0

=A0


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


--f46d043c7f5695335d04e6d5c058-- From adrian@olddog.co.uk Sun Sep 22 06:12: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 B4B2B21F9FD7 for ; Sun, 22 Sep 2013 06:12: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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBFmrWDnpi0l for ; Sun, 22 Sep 2013 06:11:58 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0093E21F9E9F for ; Sun, 22 Sep 2013 06:11:57 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8MDBr8F020931; Sun, 22 Sep 2013 14:11:53 +0100 Received: from 950129200 (240-187-254-62.static.virginmedia.com [62.254.187.240] (may be forged)) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8MDBq1R020920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Sep 2013 14:11:53 +0100 From: "Adrian Farrel" To: "'Anoop Ghanwani'" References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> In-Reply-To: Date: Sun, 22 Sep 2013 14:11:51 +0100 Message-ID: <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFg04QWmsYKG8fALD16ZmQnwUtrcgFgAU6uAa8PxyMBkBIW6wGQttblmnwDUCA= Content-Language: en-gb Cc: nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 13:12:05 -0000 Hi Anoop, > My interpretation of the following line: >>> > A document will describe the single service-level encapsulation = protocol for > conveying the service function chain and the service function path >>> > > is that there will be a single encapsulation protocol at the "service = layer". Are > we saying that there could be more than one way of carrying this = header but > that the contents would be the same? That is my interpretation. I.e., this is an encapsulation that can be placed between the = "transport" (e.g., IP, MPLS, TCP, HTTP....) and the payload. > Would the output of this WG would allow the creation of a service = chain even > when overlays are not in use? =A0(This is not clear from reading the = charter.) Well, erm, what is an "overlay"? Isn't an overlay just a network that happens to be running over another = network? Why would that need to be mentioned explicitly? Why would you assume it is ruled out if it is not mentioned? > Finally, is the work intended to support chains of both transparent = and non- > transparent appliances, or is the focus mainly on transparent = appliances? =A0I > ask because there may be interesting layering issues with respect to = the > placement of this header, especially if we have a combination of = transparent > and non-transparent appliances. That is probably a good question. Personally, I would like to put it "for investigation." I.e., I don't = think we know enough about the use cases and requirements to answer your question = at this stage. But if enough people show up on the list saying that they only want to = handle one categorisation, then perhaps we can limit from day one. Cheers, Adrian From ghanwani@gmail.com Sun Sep 22 09:33: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 6CE8711E80FB for ; Sun, 22 Sep 2013 09:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Jw-pG5FYDPDt for ; Sun, 22 Sep 2013 09:33:29 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 439E321F9EA2 for ; Sun, 22 Sep 2013 09:33:29 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id m15so1325005wgh.3 for ; Sun, 22 Sep 2013 09:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mAYV8eP8E9SyNb+4zCgIwQjmgEr8cqnDz39WRMTOPtQ=; b=U9CuvD8SSL106823ccN3w+GnsL24IKhf5m8zn3ol8aifaI1uFq+3/lnAaDO/De/K0p 3WzV64hAk/nqL2XZr/PZvjB2wp2VzNYjYMCq6NEwxzTR+kxTvU6Y2vl9PX17Yx9yA056 97tPPKkZo+2S+2IjBbb+S0hYUp8D63bpz7MDjISdg5koNvUAi4IyHJcNNd0Uul612y2R w4xlwt7gzrVDrFhrET8eEU2ueVbiCUtOlyDXRf7Xuvs2vJ/KgcWbFAf4VbiouGW7qEmo M/HdXenKWjguNpKz88bZ81WDxSRGRqDF5KEZroNQoSeCqW/H+ycRGg0JiBYorQsY4rJx c/DQ== MIME-Version: 1.0 X-Received: by 10.180.184.107 with SMTP id et11mr10295398wic.60.1379867608439; Sun, 22 Sep 2013 09:33:28 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.217.54.6 with HTTP; Sun, 22 Sep 2013 09:33:28 -0700 (PDT) In-Reply-To: <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> Date: Sun, 22 Sep 2013 09:33:28 -0700 X-Google-Sender-Auth: qe6vqYg_NgIVhxIWc8ezsK_dzaY Message-ID: From: Anoop Ghanwani To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a11c227eea3624604e6fb76cb Cc: "nsc@ietf.org" Subject: Re: [nsc] 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: Sun, 22 Sep 2013 16:33:30 -0000 --001a11c227eea3624604e6fb76cb Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, >>> That is my interpretation. I.e., this is an encapsulation that can be placed between the "transport" (e.g., IP, MPLS, TCP, HTTP....) and the payload. >>> OK, I think that's a bit different from what Uri was arguing for. >>> Well, erm, what is an "overlay"? Isn't an overlay just a network that happens to be running over another network? Why would that need to be mentioned explicitly? Why would you assume it is ruled out if it is not mentioned? >>> I tend to think of an overlay as one where there are multiple occurrences of the same layer of header in the packet., but maybe I have it wrong. Does the IETF have a formal definition for this? >>> That is probably a good question. Personally, I would like to put it "for investigation." I.e., I don't think we know enough about the use cases and requirements to answer your question at this stage. But if enough people show up on the list saying that they only want to handle one categorisation, then perhaps we can limit from day one. >>> I think it would make sense to add something explicit to the charter about this. Since I have been asked the question offline, I will go ahead and explain what I mean by transparent vs non-transparent appliances. With a non-transparent appliance, the appliance appears as a "router" in the path of the data. As far as I'm aware this is how load balancers are deployed and this is how firewalls are commonly deployed. In the non-transparent case, the address of the appliance does not appear in the packet; instead packets are diverted to the appliance using PBR. This used sometimes for IDS/IPS type appliances. Anoop On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel wrote: > Hi Anoop, > > > My interpretation of the following line: > >>> > > A document will describe the single service-level encapsulation protocol > for > > conveying the service function chain and the service function path > >>> > > > > is that there will be a single encapsulation protocol at the "service > layer". > Are > > we saying that there could be more than one way of carrying this header > but > > that the contents would be the same? > > That is my interpretation. > > I.e., this is an encapsulation that can be placed between the "transport" > (e.g., > IP, MPLS, TCP, HTTP....) and the payload. > > > Would the output of this WG would allow the creation of a service chain > even > > when overlays are not in use? (This is not clear from reading the > charter.) > > Well, erm, what is an "overlay"? > Isn't an overlay just a network that happens to be running over another > network? > Why would that need to be mentioned explicitly? > Why would you assume it is ruled out if it is not mentioned? > > > Finally, is the work intended to support chains of both transparent and > non- > > transparent appliances, or is the focus mainly on transparent > appliances? I > > ask because there may be interesting layering issues with respect to the > > placement of this header, especially if we have a combination of > transparent > > and non-transparent appliances. > > That is probably a good question. > Personally, I would like to put it "for investigation." I.e., I don't > think we > know enough about the use cases and requirements to answer your question > at this > stage. > > But if enough people show up on the list saying that they only want to > handle > one categorisation, then perhaps we can limit from day one. > > Cheers, > Adrian > > --001a11c227eea3624604e6fb76cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

>>>
That = is my interpretation.

I.e., this is an encapsulation that can be pla= ced between the "transport" (e.g.,
IP, MPLS, TCP, HTTP....) an= d the payload.
>>>

OK, I think that's a bit dif= ferent from what Uri was arguing for.

>>>=
Well, erm, what is an "overlay"?
Isn't an overl= ay just a network that happens to be running over another network?
Why would that need to be mentioned explicitly?
Why would you assume it = is ruled out if it is not mentioned?
>>>
<= br>
I tend to think of an overlay as one where there are multiple= occurrences of the same layer of =A0header in the packet., but maybe I hav= e it wrong. =A0Does the IETF have a formal definition for this?

>>>
That is probably a good question= .
Personally, I would like to put it "for investigation." I.e.= , I don't think we
know enough about the use cases and requirements = to answer your question at this
stage.

But if enough people show up on the list saying that they onl= y want to handle
one categorisation, then perhaps we can limit from day = one.
>>>

I think it would make sense to add som= ething explicit to the charter about this.
=
Since I have been asked the question o= ffline, I will go ahead and explain what I mean by transparent vs non-trans= parent appliances. =A0With a non-transparent appliance, the appliance appea= rs as a "router" in the path of the data. =A0As far as I'm aw= are this is how load balancers are deployed and this is how firewalls are c= ommonly deployed. =A0In the non-transparent case, the address of the applia= nce does not appear in the packet; instead packets are diverted to the appl= iance using PBR. =A0This used sometimes for IDS/IPS type appliances.

Anoop
On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel= <adrian@olddog.co.uk> wrote:
Hi Anoop,

> My interpretation of the following line:
>>>
> A document will describe the single service-level encapsulation protoc= ol for
> conveying the service function chain and the service function path
>>>
>
> is that there will be a single encapsulation protocol at the "ser= vice layer".
Are
> we saying that there could be more than one way of carrying this heade= r but
> that the contents would be the same?

That is my interpretation.

I.e., this is an encapsulation that can be placed between the "transpo= rt" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.

> Would the output of this WG would allow the creation of a service chai= n even
> when overlays are not in use? =A0(This is not clear from reading the c= harter.)

Well, erm, what is an "overlay"?
Isn't an overlay just a network that happens to be running over another= network?
Why would that need to be mentioned explicitly?
Why would you assume it is ruled out if it is not mentioned?

> Finally, is the work intended to support chains of both transparent an= d non-
> transparent appliances, or is the focus mainly on transparent applianc= es? =A0I
> ask because there may be interesting layering issues with respect to t= he
> placement of this header, especially if we have a combination of trans= parent
> and non-transparent appliances.

That is probably a good question.
Personally, I would like to put it "for investigation." I.e., I d= on't think we
know enough about the use cases and requirements to answer your question at= this
stage.

But if enough people show up on the list saying that they only want to hand= le
one categorisation, then perhaps we can limit from day one.

Cheers,
Adrian


--001a11c227eea3624604e6fb76cb-- From cpignata@cisco.com Sun Sep 22 10:00:43 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A750021F970E for ; Sun, 22 Sep 2013 10:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wfFhNMxwjbNz for ; Sun, 22 Sep 2013 10:00:38 -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 5BBB521F96CA for ; Sun, 22 Sep 2013 10:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13448; q=dns/txt; s=iport; t=1379869238; x=1381078838; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7JaJh5wch9jS4/FfVN5qJT/3osaXokENqXKAjOokqC4=; b=gpukEk2Y2SImaQOsyT3sMs9d6ue+YAQAYM7vI+o4NEPG79Fp9a0gjnQA S4Rf3FrSfkKTnVgG+QRSYyFsOCk1ipizifm4L3WJtHtUlWf/8WT8KsrA3 5IMHH4Db+qXT11Z2hkM7Zg2VzD5mc0wRqwOPhNqr2t4lWkHOV3dqYC8Qz s=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAG0hP1KtJXHB/2dsb2JhbABZDoJ5OFLBL4ESFnSCJQEBAQMBAQEBYgkGBQULAgEIEgYKJCcLFw4CBA4FCAaHcQYMujUEjieBDTEHgx6BAAOQJoEvmB6CZT+BaUE X-IronPort-AV: E=Sophos;i="4.90,957,1371081600"; d="asc'?scan'208,217";a="263013657" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 22 Sep 2013 17:00:34 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8MH0XPD023030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Sep 2013 17:00:34 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Sun, 22 Sep 2013 12:00:33 -0500 From: "Carlos Pignataro (cpignata)" To: Anoop Ghanwani Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAEgCgAABXPIWAAAcKmAAAAPH+AA== Date: Sun, 22 Sep 2013 17:00:32 +0000 Message-ID: <95067C434CE250468B77282634C96ED325F88253@xmb-aln-x02.cisco.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.244] Content-Type: multipart/signed; boundary="Apple-Mail=_57817191-A7A6-4A9C-BE81-B66C1C9FCBE2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "nsc@ietf.org" , Adrian Farrel Subject: Re: [nsc] 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: Sun, 22 Sep 2013 17:00:43 -0000 --Apple-Mail=_57817191-A7A6-4A9C-BE81-B66C1C9FCBE2 Content-Type: multipart/alternative; boundary="Apple-Mail=_F4600400-C9AB-4E84-B0FC-0A4956C18D41" --Apple-Mail=_F4600400-C9AB-4E84-B0FC-0A4956C18D41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Anoop, On Sep 22, 2013, at 12:33 PM, Anoop Ghanwani = wrote: > Hi Adrian, >=20 > > we saying that there could be more than one way of carrying this = header but > > that the contents would be the same? > >>> > That is my interpretation. >=20 Yes. > I.e., this is an encapsulation that can be placed between the = "transport" (e.g., > IP, MPLS, TCP, HTTP....) and the payload. > >>> >=20 > OK, I think that's a bit different from what Uri was arguing for. An explicit goal is that the encapsulation carrying service information = not be dependent on the transport.=20 Like Jim said, the charter does not disallow (sorry for the double = negative) the points on this thread, to be discussed on the WG-to-be. >=20 > >>> > Well, erm, what is an "overlay"? > Isn't an overlay just a network that happens to be running over = another network? > Why would that need to be mentioned explicitly? > Why would you assume it is ruled out if it is not mentioned? > >>> >=20 > I tend to think of an overlay as one where there are multiple = occurrences of the same layer of header in the packet., but maybe I = have it wrong. Does the IETF have a formal definition for this? >=20 I am not sure if there is *a* formal definition of Network overlay, but = the meaning is a network running on top of another network, regardless = of the "same layer of header". > >>> > That is probably a good question. > Personally, I would like to put it "for investigation." I.e., I don't = think we > know enough about the use cases and requirements to answer your = question at this > stage. >=20 > But if enough people show up on the list saying that they only want to = handle > one categorisation, then perhaps we can limit from day one. > >>> >=20 > I think it would make sense to add something explicit to the charter = about this. >=20 The charter, in its lack of explicit mention, is generic to allow for = this to be discussed later. I strongly disagree with limiting this early on the on this, as I do not = believe the WG discussed it to make that call. Seems like a degree of granularity for a framework or an architecture = and not a charter. Thanks, -- Carlos. > Since I have been asked the question offline, I will go ahead and = explain what I mean by transparent vs non-transparent appliances. With = a non-transparent appliance, the appliance appears as a "router" in the = path of the data. As far as I'm aware this is how load balancers are = deployed and this is how firewalls are commonly deployed. In the = non-transparent case, the address of the appliance does not appear in = the packet; instead packets are diverted to the appliance using PBR. = This used sometimes for IDS/IPS type appliances. >=20 > Anoop >=20 > On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel = wrote: > Hi Anoop, >=20 > > My interpretation of the following line: > >>> > > A document will describe the single service-level encapsulation = protocol for > > conveying the service function chain and the service function path > >>> > > > > is that there will be a single encapsulation protocol at the = "service layer". > Are > > we saying that there could be more than one way of carrying this = header but > > that the contents would be the same? >=20 > That is my interpretation. >=20 > I.e., this is an encapsulation that can be placed between the = "transport" (e.g., > IP, MPLS, TCP, HTTP....) and the payload. >=20 > > Would the output of this WG would allow the creation of a service = chain even > > when overlays are not in use? (This is not clear from reading the = charter.) >=20 > Well, erm, what is an "overlay"? > Isn't an overlay just a network that happens to be running over = another network? > Why would that need to be mentioned explicitly? > Why would you assume it is ruled out if it is not mentioned? >=20 > > Finally, is the work intended to support chains of both transparent = and non- > > transparent appliances, or is the focus mainly on transparent = appliances? I > > ask because there may be interesting layering issues with respect to = the > > placement of this header, especially if we have a combination of = transparent > > and non-transparent appliances. >=20 > That is probably a good question. > Personally, I would like to put it "for investigation." I.e., I don't = think we > know enough about the use cases and requirements to answer your = question at this > stage. >=20 > But if enough people show up on the list saying that they only want to = handle > one categorisation, then perhaps we can limit from day one. >=20 > Cheers, > Adrian >=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc --Apple-Mail=_F4600400-C9AB-4E84-B0FC-0A4956C18D41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi, = Anoop,

On Sep 22, 2013, at 12:33 PM, Anoop Ghanwani = <anoop@alumni.duke.edu>= wrote:

Hi = Adrian,

> we saying that there = could be more than one way of carrying this header but
> that the = contents would be the = same?
>>>
That is my = interpretation.


Yes.
I.e., this is an = encapsulation that can be placed between the "transport" (e.g.,
IP, = MPLS, TCP, HTTP....) and the payload.
>>>

OK, I think that's a bit = different from what Uri was arguing = for.

An explicit goal is = that the encapsulation carrying service information not be dependent on = the transport. 

Like Jim said, the charter = does not disallow (sorry for the double negative) the points on this = thread, to be discussed on the WG-to-be.


>>>
Well, erm, what = is an "overlay"?
Isn't an overlay just a network that happens to be = running over another network?
Why would that need to be mentioned explicitly?
Why would you assume = it is ruled out if it is not = mentioned?
>>>

I tend to = think of an overlay as one where there are multiple occurrences of the = same layer of  header in the packet., but maybe I have it wrong. =  Does the IETF have a formal definition for this?


I am not sure if = there is *a* formal definition of Network overlay, but the meaning is a = network running on top of another network, regardless of the "same layer = of header".

>>>
That is probably a good = question.
Personally, I would like to put it "for investigation." = I.e., I don't think we
know enough about the use cases and = requirements to answer your question at this
stage.

But if enough people show up on the list saying that they = only want to handle
one categorisation, then perhaps we can limit = from day one.
>>>

I think it would make sense to add = something explicit to the charter about this.


The charter, in its lack of explicit mention, is generic to allow for = this to be discussed later.

I strongly disagree = with limiting this early on the on this, as I do not believe the WG = discussed it to make that call.

Seems like a = degree of granularity for a framework or an architecture and not a = charter.

Thanks,

-- = Carlos.

Since I have been asked the question offline, I = will go ahead and explain what I mean by transparent vs non-transparent = appliances.  With a non-transparent appliance, the appliance = appears as a "router" in the path of the data.  As far as I'm aware = this is how load balancers are deployed and this is how firewalls are = commonly deployed.  In the non-transparent case, the address of the = appliance does not appear in the packet; instead packets are diverted to = the appliance using PBR.  This used sometimes for IDS/IPS type = appliances.

Anoop

On Sun, = Sep 22, 2013 at 6:11 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi Anoop,

> My interpretation of the following line:
>>>
> A document will describe the single service-level encapsulation = protocol for
> conveying the service function chain and the service function = path
>>>
>
> is that there will be a single encapsulation protocol at the = "service layer".
Are
> we saying that there could be more than one way of carrying this = header but
> that the contents would be the same?

That is my interpretation.

I.e., this is an encapsulation that can be placed between the = "transport" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.

> Would the output of this WG would allow the creation of a service = chain even
> when overlays are not in use?  (This is not clear from reading = the charter.)

Well, erm, what is an "overlay"?
Isn't an overlay just a network that happens to be running over another = network?
Why would that need to be mentioned explicitly?
Why would you assume it is ruled out if it is not mentioned?

> Finally, is the work intended to support chains of both transparent = and non-
> transparent appliances, or is the focus mainly on transparent = appliances?  I
> ask because there may be interesting layering issues with respect = to the
> placement of this header, especially if we have a combination of = transparent
> and non-transparent appliances.

That is probably a good question.
Personally, I would like to put it "for investigation." I.e., I don't = think we
know enough about the use cases and requirements to answer your question = at this
stage.

But if enough people show up on the list saying that they only want to = handle
one categorisation, then perhaps we can limit from day one.

Cheers,
Adrian


_______________________________________________
nsc mailing = list
nsc@ietf.org
https://www.ietf.org/mail= man/listinfo/nsc

= --Apple-Mail=_F4600400-C9AB-4E84-B0FC-0A4956C18D41-- --Apple-Mail=_57817191-A7A6-4A9C-BE81-B66C1C9FCBE2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlI/IjAACgkQtfDPGTp3USybDACfYmVP+hdTitNuAILgYxGEIHCY m9YAn3QTEeeR1DHzeUGJoi3HZwn2AAOF =7rLP -----END PGP SIGNATURE----- --Apple-Mail=_57817191-A7A6-4A9C-BE81-B66C1C9FCBE2-- From jguichar@cisco.com Sun Sep 22 11: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 7DF7221F9C99 for ; Sun, 22 Sep 2013 11:14:14 -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=[AWL=0.000, 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 gwUSX4NQ4QzK for ; Sun, 22 Sep 2013 11:14:09 -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 A105C21F9983 for ; Sun, 22 Sep 2013 11:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2170; q=dns/txt; s=iport; t=1379873649; x=1381083249; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KJtYUTYgNkBRF/o+fASKkNZZOQklCe5pinQMLxQwaKg=; b=mciKT/iJ6IBRnIxyoPuxIdz67Q3Hl5cNLeE40/lUvDwZO+G37vGqRaRr HpZnHyph63BkH3iS3xs8aDIrB55JLIzMiVAzspgnMXE57xD3ZKjEB2dOH qmDi1mQQJo3VXxbJlpMUsgudmUNUNwbSv3lt7sapZ1loWygrQ5WnZCzV8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAAgzP1KtJV2Y/2dsb2JhbABZgwc4wgGBEhZ0giUBAQEDAQEBATc0BgUFCwIBCBgeECcLJQIEDgWHfwYMug8EjieBCzMHgx6BAAOXfJF3gySBaQ X-IronPort-AV: E=Sophos;i="4.90,957,1371081600"; d="scan'208";a="263030198" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 22 Sep 2013 18:14:09 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8MIE8Qe014136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Sep 2013 18:14:09 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Sun, 22 Sep 2013 13:14:08 -0500 From: "Jim Guichard (jguichar)" To: "" Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAEgCgAABXPIWAAAAUXPY= Date: Sun, 22 Sep 2013 18:14:07 +0000 Message-ID: <0C948610-30FF-4EAE-8139-7669CA96B33C@cisco.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> , <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> In-Reply-To: <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> 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" , Anoop Ghanwani Subject: Re: [nsc] 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: Sun, 22 Sep 2013 18:14:14 -0000 Hi Anoop, Could you be more specific as to your definition for transparent and non-tr= ansparent appliances? Sent from my iPhone > On Sep 22, 2013, at 9:12 AM, "Adrian Farrel" wrote: >=20 > Hi Anoop, >=20 >> My interpretation of the following line: >> A document will describe the single service-level encapsulation protocol= for >> conveying the service function chain and the service function path >>=20 >> is that there will be a single encapsulation protocol at the "service la= yer". > Are >> we saying that there could be more than one way of carrying this header = but >> that the contents would be the same? >=20 > That is my interpretation. >=20 > I.e., this is an encapsulation that can be placed between the "transport"= (e.g., > IP, MPLS, TCP, HTTP....) and the payload. >=20 >> Would the output of this WG would allow the creation of a service chain = even >> when overlays are not in use? (This is not clear from reading the chart= er.) >=20 > Well, erm, what is an "overlay"? > Isn't an overlay just a network that happens to be running over another n= etwork? > Why would that need to be mentioned explicitly? > Why would you assume it is ruled out if it is not mentioned? >=20 >> Finally, is the work intended to support chains of both transparent and = non- >> transparent appliances, or is the focus mainly on transparent appliances= ? I >> ask because there may be interesting layering issues with respect to the >> placement of this header, especially if we have a combination of transpa= rent >> and non-transparent appliances. >=20 > That is probably a good question. > Personally, I would like to put it "for investigation." I.e., I don't thi= nk we > know enough about the use cases and requirements to answer your question = at this > stage. >=20 > But if enough people show up on the list saying that they only want to ha= ndle > one categorisation, then perhaps we can limit from day one. >=20 > Cheers, > Adrian >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From smkumar@cisco.com Sun Sep 22 12:23: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 EA93811E8133 for ; Sun, 22 Sep 2013 12:23:49 -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 qeKl0ySKjv0m for ; Sun, 22 Sep 2013 12:23: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 282B611E8138 for ; Sun, 22 Sep 2013 12:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13545; q=dns/txt; s=iport; t=1379877824; x=1381087424; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Zjkj84MGTBIV4jzJShRlKVk/EsMqJljv82ogWfztaIw=; b=I72lRplVwdvFXZ6y29kW/ASPsOPiqmSzPg3EVJ/qoiIhpdCuODLatJng 5rp3UkTa8G02a6IZBCTCvBjx3pwbhlJFYzXdLipmd0h/4i9B5jWBhBrI+ vbbA8QQ2jEzBV51/QIBuYy0ZW+Yncyzp5JOp2MAah4vBUqargKHVP/+ZQ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAHdDP1KtJXG//2dsb2JhbABZDoI1RDhSwTCBEhZ0giUBAQEDAWUPBQUNAQgRAwECCx05FAkIAgQBDQUIh3cGuXGOJ4ENIBEHgx6BAAOpc4JlP4FpQQ X-IronPort-AV: E=Sophos;i="4.90,957,1371081600"; d="scan'208,217";a="262988374" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 22 Sep 2013 19:23:30 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8MJNUPT006734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Sep 2013 19:23:30 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.195]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Sun, 22 Sep 2013 14:23:30 -0500 From: "Surendra Kumar (smkumar)" To: Anoop Ghanwani , Adrian Farrel Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAEgCgAABXPIWAAAcKmAD//7olgA== Date: Sun, 22 Sep 2013 19:23:29 +0000 Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C92114EC41@xmb-aln-x09.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.3.7.130812 x-originating-ip: [10.21.126.74] Content-Type: multipart/alternative; boundary="_000_8E86B6E7C6FB9F40A00B0E269045A7C92114EC41xmbalnx09ciscoc_" MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] 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: Sun, 22 Sep 2013 19:23:50 -0000 --_000_8E86B6E7C6FB9F40A00B0E269045A7C92114EC41xmbalnx09ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Anoop, Comments inline. Surendra. From: Anoop Ghanwani > Date: Sunday, September 22, 2013 9:33 AM To: Adrian Farrel > Cc: "nsc@ietf.org" > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Hi Adrian, >>> That is my interpretation. I.e., this is an encapsulation that can be placed between the "transport" (= e.g., IP, MPLS, TCP, HTTP....) and the payload. >>> OK, I think that's a bit different from what Uri was arguing for. >>> Well, erm, what is an "overlay"? Isn't an overlay just a network that happens to be running over another net= work? Why would that need to be mentioned explicitly? Why would you assume it is ruled out if it is not mentioned? >>> I tend to think of an overlay as one where there are multiple occurrences o= f the same layer of header in the packet., but maybe I have it wrong. Doe= s the IETF have a formal definition for this? SK> Here is an IP-in-MAC overlay or L3 packet over L2 network: [L2-LLC/SNAP= | original-IPpayload=97noL2Hdr] This is still an overlay although the same = layer does not appear multiple times. >>> That is probably a good question. Personally, I would like to put it "for investigation." I.e., I don't think= we know enough about the use cases and requirements to answer your question at= this stage. But if enough people show up on the list saying that they only want to hand= le one categorisation, then perhaps we can limit from day one. >>> I think it would make sense to add something explicit to the charter about = this. SK> It is not necessary to add such detail to the charter when it is not ne= eded. Since I have been asked the question offline, I will go ahead and explain w= hat I mean by transparent vs non-transparent appliances. With a non-transp= arent appliance, the appliance appears as a "router" in the path of the dat= a. As far as I'm aware this is how load balancers are deployed and this is= how firewalls are commonly deployed. In the non-transparent case, the add= ress of the appliance does not appear in the packet; instead packets are di= verted to the appliance using PBR. This used sometimes for IDS/IPS type ap= pliances. SK> That is my interpretation of transparent and terminated as well. It is = also referred to as the go-to vs go-through, bridged vs routed, off-path vs= in-path etc. I also would like to note that the same appliance could behav= e both as a transparent or a terminated. It depends on the service function= . When we speak of service chains, I really expect terminated service functio= ns to be part of the chain and in that sense terminated should be in scope.= Having said that, we can debate later. Anoop On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel > wrote: Hi Anoop, > My interpretation of the following line: >>> > A document will describe the single service-level encapsulation protocol = for > conveying the service function chain and the service function path >>> > > is that there will be a single encapsulation protocol at the "service lay= er". Are > we saying that there could be more than one way of carrying this header b= ut > that the contents would be the same? That is my interpretation. I.e., this is an encapsulation that can be placed between the "transport" (= e.g., IP, MPLS, TCP, HTTP....) and the payload. > Would the output of this WG would allow the creation of a service chain e= ven > when overlays are not in use? (This is not clear from reading the charte= r.) Well, erm, what is an "overlay"? Isn't an overlay just a network that happens to be running over another net= work? Why would that need to be mentioned explicitly? Why would you assume it is ruled out if it is not mentioned? > Finally, is the work intended to support chains of both transparent and n= on- > transparent appliances, or is the focus mainly on transparent appliances?= I > ask because there may be interesting layering issues with respect to the > placement of this header, especially if we have a combination of transpar= ent > and non-transparent appliances. That is probably a good question. Personally, I would like to put it "for investigation." I.e., I don't think= we know enough about the use cases and requirements to answer your question at= this stage. But if enough people show up on the list saying that they only want to hand= le one categorisation, then perhaps we can limit from day one. Cheers, Adrian --_000_8E86B6E7C6FB9F40A00B0E269045A7C92114EC41xmbalnx09ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Anoop,

Comments inline.

Surendra.

From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Sunday, September 22, 2013 9:= 33 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "nsc@ietf.org" <nsc@ietf.= org>
Subject: Re: [nsc] New NSC WG Chart= er - charter bullet #3

Hi Adrian,

>>>
That is my interpretation.

I.e., this is an encapsulation that can be placed between the "transpo= rt" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.
>>>

OK, I think that's a bit different fro= m what Uri was arguing for.

>>>
Well, erm, what is an "overlay&qu= ot;?
Isn't an overlay just a network that happens to be running over another net= work?
Why would that need to be mentioned explicitly?
Why would you assume it is ruled out if it is not mentioned?
>>>

I tend to think of an overlay as one w= here there are multiple occurrences of the same layer of  header in th= e packet., but maybe I have it wrong.  Does the IETF have a formal def= inition for this?
SK> Here is an IP-in-MAC overlay or L3 pack= et over L2 network: [L2-LLC/SNAP| original-IPpayload=97noL2Hdr] This is sti= ll an overlay although the same layer does not appear multiple times. =

>>>
That is probably a good question.
Personally, I would like to put it "for investigation." I.e., I d= on't think we
know enough about the use cases and requirements to answer your question at= this
stage.

But if enough people show up on the list saying that they only want to hand= le
one categorisation, then perhaps we can limit from day one.
>>>

I think it would make sense to add something exp= licit to the charter about this.
SK> It is not necessary to add such detail = to the charter when it is not needed.

Since I have been asked the question offline, I = will go ahead and explain what I mean by transparent vs non-transparent app= liances.  With a non-transparent appliance, the appliance appears as a= "router" in the path of the data.  As far as I'm aware this is how load balancers are deployed and this is how f= irewalls are commonly deployed.  In the non-transparent case, the addr= ess of the appliance does not appear in the packet; instead packets are div= erted to the appliance using PBR.  This used sometimes for IDS/IPS type appliances.
SK> That is my interpretation of transparen= t and terminated as well. It is also referred to as the go-to vs go-through= , bridged vs routed, off-path vs in-path etc. I also would like to note tha= t the same appliance could behave both as a transparent or a terminated. It depends on the service function.
When we speak of service chains, I really expe= ct terminated service functions to be part of the chain and in that sense t= erminated should be in scope. Having said that, we can debate later.=

Anoop

On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel <= span dir=3D"ltr"> <adrian@olddog.= co.uk> wrote:
Hi Anoop,

> My interpretation of the following line:
>>>
> A document will describe the single service-level encapsulation protoc= ol for
> conveying the service function chain and the service function path
>>>
>
> is that there will be a single encapsulation protocol at the "ser= vice layer".
Are
> we saying that there could be more than one way of carrying this heade= r but
> that the contents would be the same?

That is my interpretation.

I.e., this is an encapsulation that can be placed between the "transpo= rt" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.

> Would the output of this WG would allow the creation of a service chai= n even
> when overlays are not in use?  (This is not clear from reading th= e charter.)

Well, erm, what is an "overlay"?
Isn't an overlay just a network that happens to be running over another net= work?
Why would that need to be mentioned explicitly?
Why would you assume it is ruled out if it is not mentioned?

> Finally, is the work intended to support chains of both transparent an= d non-
> transparent appliances, or is the focus mainly on transparent applianc= es?  I
> ask because there may be interesting layering issues with respect to t= he
> placement of this header, especially if we have a combination of trans= parent
> and non-transparent appliances.

That is probably a good question.
Personally, I would like to put it "for investigation." I.e., I d= on't think we
know enough about the use cases and requirements to answer your question at= this
stage.

But if enough people show up on the list saying that they only want to hand= le
one categorisation, then perhaps we can limit from day one.

Cheers,
Adrian


 --_000_8E86B6E7C6FB9F40A00B0E269045A7C92114EC41xmbalnx09ciscoc_-- From smkumar@cisco.com Sun Sep 22 12:24:34 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 D426A21F9C53 for ; Sun, 22 Sep 2013 12:24:34 -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 p5pENNMEbw3Q for ; Sun, 22 Sep 2013 12:24:30 -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 DDE8221F964C for ; Sun, 22 Sep 2013 12:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14758; q=dns/txt; s=iport; t=1379877868; x=1381087468; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=bLNVpKPzIV1ZCROKiGfGZt9Zaj04SbIEObjMo09nhWw=; b=mSOG3snohG1AhzOFVev5xiov/T7J3Uo3ZtsF/dc8uP6y734uB9Q2Aj4w n0JevFfeOYCgjqnbMuz4t9jCIkvQZ30/Z3jmhblZZW9ycATECv4LGb/TE WZiYdyBDF+83SR/uijrp7X4iV0+G/cXWFjP2kN3h79ySJGN+PyYaPUSbO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAGhDP1KtJXHA/2dsb2JhbABZDoI1RDhSwTCBEhZ0giUBAQEDAQEBAWIJBgUFDQEIEQECAQILHS4LFAMGCAIEAQ0FCId3Bgy5YQSOJ4ENIA0EB4MegQADqXOCZT+BaUE X-IronPort-AV: E=Sophos;i="4.90,957,1371081600"; d="scan'208,217";a="260020339" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 22 Sep 2013 19:24:28 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8MJORYY013706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Sep 2013 19:24:27 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.195]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sun, 22 Sep 2013 14:24:26 -0500 From: "Surendra Kumar (smkumar)" To: "Carlos Pignataro (cpignata)" , Anoop Ghanwani Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAEgCgAABXPIWAAAcKmAAAAPH+AP//stqA Date: Sun, 22 Sep 2013 19:24:26 +0000 Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C92114EC53@xmb-aln-x09.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED325F88253@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.21.126.74] Content-Type: multipart/alternative; boundary="_000_8E86B6E7C6FB9F40A00B0E269045A7C92114EC53xmbalnx09ciscoc_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , Adrian Farrel Subject: Re: [nsc] 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: Sun, 22 Sep 2013 19:24:35 -0000 --_000_8E86B6E7C6FB9F40A00B0E269045A7C92114EC53xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Surendra. From: "Carlos Pignataro (cpignata)" > Date: Sunday, September 22, 2013 10:00 AM To: Anoop Ghanwani > Cc: "nsc@ietf.org" >= , Adrian Farrel > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Hi, Anoop, On Sep 22, 2013, at 12:33 PM, Anoop Ghanwani > wrote: Hi Adrian, > we saying that there could be more than one way of carrying this header b= ut > that the contents would be the same? >>> That is my interpretation. Yes. I.e., this is an encapsulation that can be placed between the "transport" (= e.g., IP, MPLS, TCP, HTTP....) and the payload. >>> OK, I think that's a bit different from what Uri was arguing for. An explicit goal is that the encapsulation carrying service information not= be dependent on the transport. Like Jim said, the charter does not disallow (sorry for the double negative= ) the points on this thread, to be discussed on the WG-to-be. >>> Well, erm, what is an "overlay"? Isn't an overlay just a network that happens to be running over another net= work? Why would that need to be mentioned explicitly? Why would you assume it is ruled out if it is not mentioned? >>> I tend to think of an overlay as one where there are multiple occurrences o= f the same layer of header in the packet., but maybe I have it wrong. Doe= s the IETF have a formal definition for this? I am not sure if there is *a* formal definition of Network overlay, but the= meaning is a network running on top of another network, regardless of the = "same layer of header". >>> That is probably a good question. Personally, I would like to put it "for investigation." I.e., I don't think= we know enough about the use cases and requirements to answer your question at= this stage. But if enough people show up on the list saying that they only want to hand= le one categorisation, then perhaps we can limit from day one. >>> I think it would make sense to add something explicit to the charter about = this. The charter, in its lack of explicit mention, is generic to allow for this = to be discussed later. I strongly disagree with limiting this early on the on this, as I do not be= lieve the WG discussed it to make that call. Seems like a degree of granularity for a framework or an architecture and n= ot a charter. Thanks, -- Carlos. Since I have been asked the question offline, I will go ahead and explain w= hat I mean by transparent vs non-transparent appliances. With a non-transp= arent appliance, the appliance appears as a "router" in the path of the dat= a. As far as I'm aware this is how load balancers are deployed and this is= how firewalls are commonly deployed. In the non-transparent case, the add= ress of the appliance does not appear in the packet; instead packets are di= verted to the appliance using PBR. This used sometimes for IDS/IPS type ap= pliances. Anoop On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel > wrote: Hi Anoop, > My interpretation of the following line: >>> > A document will describe the single service-level encapsulation protocol = for > conveying the service function chain and the service function path >>> > > is that there will be a single encapsulation protocol at the "service lay= er". Are > we saying that there could be more than one way of carrying this header b= ut > that the contents would be the same? That is my interpretation. I.e., this is an encapsulation that can be placed between the "transport" (= e.g., IP, MPLS, TCP, HTTP....) and the payload. > Would the output of this WG would allow the creation of a service chain e= ven > when overlays are not in use? (This is not clear from reading the charte= r.) Well, erm, what is an "overlay"? Isn't an overlay just a network that happens to be running over another net= work? Why would that need to be mentioned explicitly? Why would you assume it is ruled out if it is not mentioned? > Finally, is the work intended to support chains of both transparent and n= on- > transparent appliances, or is the focus mainly on transparent appliances?= I > ask because there may be interesting layering issues with respect to the > placement of this header, especially if we have a combination of transpar= ent > and non-transparent appliances. That is probably a good question. Personally, I would like to put it "for investigation." I.e., I don't think= we know enough about the use cases and requirements to answer your question at= this stage. But if enough people show up on the list saying that they only want to hand= le one categorisation, then perhaps we can limit from day one. Cheers, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_8E86B6E7C6FB9F40A00B0E269045A7C92114EC53xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <7C3783D61EFB3E43B7DFBC1B51CABCCF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
+1

Surendra.

From: "Carlos Pignataro (cpign= ata)" <cpignata@cisco.com= >
Date: Sunday, September 22, 2013 10= :00 AM
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Cc: "nsc@ietf.org" <nsc@ietf.= org>, Adrian Farrel <adria= n@olddog.co.uk>
Subject: Re: [nsc] New NSC WG Chart= er - charter bullet #3

Hi, Anoop,

On Sep 22, 2013, at 12:33 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:

Hi Adrian,

> we saying that there could be more than one way of c= arrying this header but
> that the contents would be the same?
>>>
That is my interpretation.


Yes.

I.e., this is an encapsulation that can be placed between the "tr= ansport" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.
>>>

OK, I think that's a bit different from what Uri was arguing for.

An explicit goal is that the encapsulation carrying service informatio= n not be dependent on the transport. 

Like Jim said, the charter does not disallow (sorry for the double neg= ative) the points on this thread, to be discussed on the WG-to-be.


>>>
Well, erm, what is an "overlay"?
Isn't an overlay just a network that happens to be running over another net= work?
Why would that need to be mentioned explicitly?
Why would you assume it is ruled out if it is not mentioned?
>>>

I tend to think of an overlay as one where there are multiple occurren= ces of the same layer of  header in the packet., but maybe I have it w= rong.  Does the IETF have a formal definition for this?


I am not sure if there is *a* formal definition of Network overlay, bu= t the meaning is a network running on top of another network, regardless of= the "same layer of header".

>>>
That is probably a good question.
Personally, I would like to put it "for investigation." I.e., I d= on't think we
know enough about the use cases and requirements to answer your question at= this
stage.

But if enough people show up on the list saying that they only want to hand= le
one categorisation, then perhaps we can limit from day one.
>>>

I think it would make sense to add something exp= licit to the charter about this.


The charter, in its lack of explicit mention, is generic to allow for = this to be discussed later.

I strongly disagree with limiting this early on the on this, as I do n= ot believe the WG discussed it to make that call.

Seems like a degree of granularity for a framework or an architecture = and not a charter.

Thanks,

-- Carlos.

Since I have been asked the question offline, I = will go ahead and explain what I mean by transparent vs non-transparent app= liances.  With a non-transparent appliance, the appliance appears as a= "router" in the path of the data.  As far as I'm aware this is how load balancers are deployed and this is how f= irewalls are commonly deployed.  In the non-transparent case, the addr= ess of the appliance does not appear in the packet; instead packets are div= erted to the appliance using PBR.  This used sometimes for IDS/IPS type appliances.

Anoop

On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel <= span dir=3D"ltr"> <adrian@olddog.= co.uk> wrote:
Hi Anoop,

> My interpretation of the following line:
>>>
> A document will describe the single service-level encapsulation protoc= ol for
> conveying the service function chain and the service function path
>>>
>
> is that there will be a single encapsulation protocol at the "ser= vice layer".
Are
> we saying that there could be more than one way of carrying this heade= r but
> that the contents would be the same?

That is my interpretation.

I.e., this is an encapsulation that can be placed between the "transpo= rt" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.

> Would the output of this WG would allow the creation of a service chai= n even
> when overlays are not in use?  (This is not clear from reading th= e charter.)

Well, erm, what is an "overlay"?
Isn't an overlay just a network that happens to be running over another net= work?
Why would that need to be mentioned explicitly?
Why would you assume it is ruled out if it is not mentioned?

> Finally, is the work intended to support chains of both transparent an= d non-
> transparent appliances, or is the focus mainly on transparent applianc= es?  I
> ask because there may be interesting layering issues with respect to t= he
> placement of this header, especially if we have a combination of trans= parent
> and non-transparent appliances.

That is probably a good question.
Personally, I would like to put it "for investigation." I.e., I d= on't think we
know enough about the use cases and requirements to answer your question at= this
stage.

But if enough people show up on the list saying that they only want to hand= le
one categorisation, then perhaps we can limit from day one.

Cheers,
Adrian


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

 --_000_8E86B6E7C6FB9F40A00B0E269045A7C92114EC53xmbalnx09ciscoc_-- From uri.elzur@intel.com Sun Sep 22 23:40:49 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA9921F9E12 for ; Sun, 22 Sep 2013 23:40:49 -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 xvwPtLNXNgml for ; Sun, 22 Sep 2013 23:40:40 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id 64FCF11E8199 for ; Sun, 22 Sep 2013 23:40:38 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by azsmga101.ch.intel.com with ESMTP; 22 Sep 2013 23:40:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.90,960,1371106800"; d="scan'208,217";a="399572345" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by fmsmga001.fm.intel.com with ESMTP; 22 Sep 2013 23:40:25 -0700 Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 22 Sep 2013 23:40:25 -0700 Received: from orsmsx105.amr.corp.intel.com ([169.254.4.17]) by ORSMSX152.amr.corp.intel.com ([169.254.8.106]) with mapi id 14.03.0123.003; Sun, 22 Sep 2013 23:40:25 -0700 From: "Elzur, Uri" To: Anoop Ghanwani , Adrian Farrel Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: AQFg04QWQ/5RtvjWRWGXnZqzywWMVAFgAU6uAa8PxyMBkBIW6wGQttblmnwDUCCAAK8fAIAAcZ+A Date: Mon, 23 Sep 2013 06:40:25 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B8995856FE011C4@ORSMSX105.amr.corp.intel.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_7E05C330D7FD6D4FAD0728C46B8995856FE011C4ORSMSX105amrcor_" MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] 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: Mon, 23 Sep 2013 06:40:49 -0000 --_000_7E05C330D7FD6D4FAD0728C46B8995856FE011C4ORSMSX105amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My point was that given some "overlay" or "encapsulation" that is "placed b= etween the transport" where the potential consumers of the "service" are lo= cated, the "services" should be stitched into that "overlay", as one option= that is to be allowed by the charter. Exchanges on this ml in last few days, reaffirms that the issue is resolved= for now as the proposed charter allows for this combination. (in plain text: VMs connected by an overlay [e.g. VXLAN, GRE etc. in a mult= itenant environment] that request services [e.g. LB/FW and other], could ge= t the services at that overlay [extension will be required] vs. requiring a= different encapsulation dedicated for services only [with no VMs]) Thx Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Anoop= Ghanwani Sent: Sunday, September 22, 2013 9:33 AM To: Adrian Farrel Cc: nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Hi Adrian, >>> That is my interpretation. I.e., this is an encapsulation that can be placed between the "transport" (= e.g., IP, MPLS, TCP, HTTP....) and the payload. >>> OK, I think that's a bit different from what Uri was arguing for. >>> Well, erm, what is an "overlay"? Isn't an overlay just a network that happens to be running over another net= work? Why would that need to be mentioned explicitly? Why would you assume it is ruled out if it is not mentioned? >>> I tend to think of an overlay as one where there are multiple occurrences o= f the same layer of header in the packet., but maybe I have it wrong. Doe= s the IETF have a formal definition for this? >>> That is probably a good question. Personally, I would like to put it "for investigation." I.e., I don't think= we know enough about the use cases and requirements to answer your question at= this stage. But if enough people show up on the list saying that they only want to hand= le one categorisation, then perhaps we can limit from day one. >>> I think it would make sense to add something explicit to the charter about = this. Since I have been asked the question offline, I will go ahead and explain w= hat I mean by transparent vs non-transparent appliances. With a non-transp= arent appliance, the appliance appears as a "router" in the path of the dat= a. As far as I'm aware this is how load balancers are deployed and this is= how firewalls are commonly deployed. In the non-transparent case, the add= ress of the appliance does not appear in the packet; instead packets are di= verted to the appliance using PBR. This used sometimes for IDS/IPS type ap= pliances. Anoop On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel > wrote: Hi Anoop, > My interpretation of the following line: >>> > A document will describe the single service-level encapsulation protocol = for > conveying the service function chain and the service function path >>> > > is that there will be a single encapsulation protocol at the "service lay= er". Are > we saying that there could be more than one way of carrying this header b= ut > that the contents would be the same? That is my interpretation. I.e., this is an encapsulation that can be placed between the "transport" (= e.g., IP, MPLS, TCP, HTTP....) and the payload. > Would the output of this WG would allow the creation of a service chain e= ven > when overlays are not in use? (This is not clear from reading the charte= r.) Well, erm, what is an "overlay"? Isn't an overlay just a network that happens to be running over another net= work? Why would that need to be mentioned explicitly? Why would you assume it is ruled out if it is not mentioned? > Finally, is the work intended to support chains of both transparent and n= on- > transparent appliances, or is the focus mainly on transparent appliances?= I > ask because there may be interesting layering issues with respect to the > placement of this header, especially if we have a combination of transpar= ent > and non-transparent appliances. That is probably a good question. Personally, I would like to put it "for investigation." I.e., I don't think= we know enough about the use cases and requirements to answer your question at= this stage. But if enough people show up on the list saying that they only want to hand= le one categorisation, then perhaps we can limit from day one. Cheers, Adrian --_000_7E05C330D7FD6D4FAD0728C46B8995856FE011C4ORSMSX105amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My point was that given s= ome “overlay” or “encapsulation” that is “pla= ced between the transport” where the potential consumers of the ̶= 0;service” are located, the “services” should be stitched into that “overlayR= 21;, as one option that is to be allowed by the charter.

Exchanges on this ml in l= ast few days, reaffirms that the issue is resolved for now as the proposed = charter allows for this combination.

 <= /p>

(in plain text: VMs conne= cted by an overlay [e.g. VXLAN, GRE etc. in a multitenant environment] that= request services [e.g. LB/FW and other], could get the services at that overlay [extension will be required] vs. requiring a diff= erent encapsulation dedicated for services only [with no VMs])

 <= /p>

Thx

 

Uri ("Oo-Ree")

O: (949)-567-4519

C: (949)-378-7568

From: nsc-boun= ces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Anoop Ghanwani
Sent: Sunday, September 22, 2013 9:33 AM
To: Adrian Farrel
Cc: nsc@ietf.org
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=

 

Hi Adrian,

 

>>> 

That is my interpretation.

I.e., this is an encapsulation that can be placed between the "transpo= rt" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.

>>> 

 

OK, I think that's a bit different from what Uri was= arguing for.

 

>>> 

Well, erm, what is an "overlay"?
Isn't an overlay just a network that happens to be running over another net= work?
Why would that need to be mentioned explicitly?
Why would you assume it is ruled out if it is not mentioned?

>>> 

 

I tend to think of an overlay as one where there are= multiple occurrences of the same layer of  header in the packet., but= maybe I have it wrong.  Does the IETF have a formal definition for th= is?

 

>>> 

That is probably a good question.
Personally, I would like to put it "for investigation." I.e., I d= on't think we
know enough about the use cases and requirements to answer your question at= this
stage.

But if enough people show up on the list saying that they only want to hand= le
one categorisation, then perhaps we can limit from day one.

>>> 

 

I think it would make sense to add something explici= t to the charter about this.

 

Since I have been asked the question offline, I will= go ahead and explain what I mean by transparent vs non-transparent applian= ces.  With a non-transparent appliance, the appliance appears as a &qu= ot;router" in the path of the data.  As far as I'm aware this is how load balancers are deployed and this is how firew= alls are commonly deployed.  In the non-transparent case, the address = of the appliance does not appear in the packet; instead packets are diverte= d to the appliance using PBR.  This used sometimes for IDS/IPS type appliances.

 

Anoop

On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

Hi Anoop,


> My interpretation of the following line:
>>>
> A document will describe the single service-level encapsulation protoc= ol for
> conveying the service function chain and the service function path
>>>
>
> is that there will be a single encapsulation protocol at the "ser= vice layer".
Are
> we saying that there could be more than one way of carrying this heade= r but
> that the contents would be the same?

That is my interpretation.

I.e., this is an encapsulation that can be placed between the "transpo= rt" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.


> Would the output of this WG would allow the creation of a service chai= n even
> when overlays are not in use?  (This is not clear from reading th= e charter.)

Well, erm, what is an "overlay"?
Isn't an overlay just a network that happens to be running over another net= work?
Why would that need to be mentioned explicitly?
Why would you assume it is ruled out if it is not mentioned?


> Finally, is the work intended to support chains of both transparent an= d non-
> transparent appliances, or is the focus mainly on transparent applianc= es?  I
> ask because there may be interesting layering issues with respect to t= he
> placement of this header, especially if we have a combination of trans= parent
> and non-transparent appliances.

That is probably a go= od question.
Personally, I would like to put it "for investigation." I.e., I d= on't think we
know enough about the use cases and requirements to answer your question at= this
stage.

But if enough people show up on the list saying that they only want to hand= le
one categorisation, then perhaps we can limit from day one.

Cheers,
Adrian

 

--_000_7E05C330D7FD6D4FAD0728C46B8995856FE011C4ORSMSX105amrcor_-- From tnadeau@lucidvision.com Mon Sep 23 04:55: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 7E14B21F8E97 for ; Mon, 23 Sep 2013 04:55:03 -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, 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 amNUPaKiNOEm for ; Mon, 23 Sep 2013 04:54:58 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0F421F9343 for ; Mon, 23 Sep 2013 04:54:47 -0700 (PDT) Received: from [172.28.132.89] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 433D4257CF5A; Mon, 23 Sep 2013 07:54:46 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_099F41B6-7911-411A-B22C-CA358AE6A9FB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Nadeau In-Reply-To: <95067C434CE250468B77282634C96ED325F88253@xmb-aln-x02.cisco.com> Date: Mon, 23 Sep 2013 07:54:44 -0400 Message-Id: <529390CE-CE27-4824-92C4-035847B0E205@lucidvision.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <95067C434CE250468B77282634C96ED325F88253@xmb-aln-x02.cisco.com> To: "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.1510) Cc: "nsc@ietf.org" , Adrian Farrel , Anoop Ghanwani Subject: Re: [nsc] 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: Mon, 23 Sep 2013 11:55:03 -0000 --Apple-Mail=_099F41B6-7911-411A-B22C-CA358AE6A9FB Content-Type: multipart/alternative; boundary="Apple-Mail=_07A5D3E8-1B2A-4AF8-A8B4-AA7D93D6B600" --Apple-Mail=_07A5D3E8-1B2A-4AF8-A8B4-AA7D93D6B600 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 22, 2013:1:00 PM, at 1:00 PM, "Carlos Pignataro (cpignata)" = wrote: > Hi, Anoop, >=20 > On Sep 22, 2013, at 12:33 PM, Anoop Ghanwani = wrote: >=20 >> Hi Adrian, >>=20 >> > we saying that there could be more than one way of carrying this = header but >> > that the contents would be the same? >> >>> >> That is my interpretation. >>=20 >=20 > Yes. >=20 >> I.e., this is an encapsulation that can be placed between the = "transport" (e.g., >> IP, MPLS, TCP, HTTP....) and the payload. >> >>> >>=20 >> OK, I think that's a bit different from what Uri was arguing for. >=20 > An explicit goal is that the encapsulation carrying service = information not be dependent on the transport.=20 >=20 > Like Jim said, the charter does not disallow (sorry for the double = negative) the points on this thread, to be discussed on the WG-to-be. >=20 >>=20 >> >>> >> Well, erm, what is an "overlay"? >> Isn't an overlay just a network that happens to be running over = another network? >> Why would that need to be mentioned explicitly? >> Why would you assume it is ruled out if it is not mentioned? >> >>> >>=20 >> I tend to think of an overlay as one where there are multiple = occurrences of the same layer of header in the packet., but maybe I = have it wrong. Does the IETF have a formal definition for this? >>=20 >=20 > I am not sure if there is *a* formal definition of Network overlay, = but the meaning is a network running on top of another network, = regardless of the "same layer of header". Precisely. It is my understanding that you can have "IP over IP" = for example, and that should be completely valid. --Tom >> >>> >> That is probably a good question. >> Personally, I would like to put it "for investigation." I.e., I don't = think we >> know enough about the use cases and requirements to answer your = question at this >> stage. >>=20 >> But if enough people show up on the list saying that they only want = to handle >> one categorisation, then perhaps we can limit from day one. >> >>> >>=20 >> I think it would make sense to add something explicit to the charter = about this. >>=20 >=20 > The charter, in its lack of explicit mention, is generic to allow for = this to be discussed later. >=20 > I strongly disagree with limiting this early on the on this, as I do = not believe the WG discussed it to make that call. >=20 > Seems like a degree of granularity for a framework or an architecture = and not a charter. >=20 > Thanks, >=20 > -- Carlos. >=20 >> Since I have been asked the question offline, I will go ahead and = explain what I mean by transparent vs non-transparent appliances. With = a non-transparent appliance, the appliance appears as a "router" in the = path of the data. As far as I'm aware this is how load balancers are = deployed and this is how firewalls are commonly deployed. In the = non-transparent case, the address of the appliance does not appear in = the packet; instead packets are diverted to the appliance using PBR. = This used sometimes for IDS/IPS type appliances. >>=20 >> Anoop >>=20 >> On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel = wrote: >> Hi Anoop, >>=20 >> > My interpretation of the following line: >> >>> >> > A document will describe the single service-level encapsulation = protocol for >> > conveying the service function chain and the service function path >> >>> >> > >> > is that there will be a single encapsulation protocol at the = "service layer". >> Are >> > we saying that there could be more than one way of carrying this = header but >> > that the contents would be the same? >>=20 >> That is my interpretation. >>=20 >> I.e., this is an encapsulation that can be placed between the = "transport" (e.g., >> IP, MPLS, TCP, HTTP....) and the payload. >>=20 >> > Would the output of this WG would allow the creation of a service = chain even >> > when overlays are not in use? (This is not clear from reading the = charter.) >>=20 >> Well, erm, what is an "overlay"? >> Isn't an overlay just a network that happens to be running over = another network? >> Why would that need to be mentioned explicitly? >> Why would you assume it is ruled out if it is not mentioned? >>=20 >> > Finally, is the work intended to support chains of both transparent = and non- >> > transparent appliances, or is the focus mainly on transparent = appliances? I >> > ask because there may be interesting layering issues with respect = to the >> > placement of this header, especially if we have a combination of = transparent >> > and non-transparent appliances. >>=20 >> That is probably a good question. >> Personally, I would like to put it "for investigation." I.e., I don't = think we >> know enough about the use cases and requirements to answer your = question at this >> stage. >>=20 >> But if enough people show up on the list saying that they only want = to handle >> one categorisation, then perhaps we can limit from day one. >>=20 >> Cheers, >> Adrian >>=20 >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc --Apple-Mail=_07A5D3E8-1B2A-4AF8-A8B4-AA7D93D6B600 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 cpignata@cisco.com> = wrote:

Hi, = Anoop,

On Sep 22, 2013, at 12:33 PM, Anoop Ghanwani = <anoop@alumni.duke.edu>= wrote:

Hi = Adrian,

> we saying that there = could be more than one way of carrying this header but
> that the = contents would be the = same?
>>>
That is my = interpretation.


Yes.
I.e., this is an = encapsulation that can be placed between the "transport" (e.g.,
IP, = MPLS, TCP, HTTP....) and the payload.
>>>

OK, I think that's a bit = different from what Uri was arguing = for.

An explicit goal is = that the encapsulation carrying service information not be dependent on = the transport. 

Like Jim said, the charter = does not disallow (sorry for the double negative) the points on this = thread, to be discussed on the WG-to-be.


>>>
Well, erm, what = is an "overlay"?
Isn't an overlay just a network that happens to be = running over another network?
Why would that need to be mentioned explicitly?
Why would you assume = it is ruled out if it is not = mentioned?
>>>

I tend to = think of an overlay as one where there are multiple occurrences of the = same layer of  header in the packet., but maybe I have it wrong. =  Does the IETF have a formal definition for this?


I am not sure if = there is *a* formal definition of Network overlay, but the meaning is a = network running on top of another network, regardless of the "same layer = of = header".

= Precisely. It is my understanding that you can have "IP over IP" = for example, and that should be completely = valid.

= --Tom



>>>
That is = probably a good question.
Personally, I would like to put it "for = investigation." I.e., I don't think we
know enough about the use = cases and requirements to answer your question at this
stage.

But if enough people show up on the list saying that they = only want to handle
one categorisation, then perhaps we can limit = from day one.
>>>

I think it would make sense to add = something explicit to the charter about this.


The charter, in its lack of explicit mention, is generic to allow for = this to be discussed later.

I strongly disagree = with limiting this early on the on this, as I do not believe the WG = discussed it to make that call.

Seems like a = degree of granularity for a framework or an architecture and not a = charter.

Thanks,

-- = Carlos.

Since I have been asked the question offline, I = will go ahead and explain what I mean by transparent vs non-transparent = appliances.  With a non-transparent appliance, the appliance = appears as a "router" in the path of the data.  As far as I'm aware = this is how load balancers are deployed and this is how firewalls are = commonly deployed.  In the non-transparent case, the address of the = appliance does not appear in the packet; instead packets are diverted to = the appliance using PBR.  This used sometimes for IDS/IPS type = appliances.

Anoop

On Sun, = Sep 22, 2013 at 6:11 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi Anoop,

> My interpretation of the following line:
>>>
> A document will describe the single service-level encapsulation = protocol for
> conveying the service function chain and the service function = path
>>>
>
> is that there will be a single encapsulation protocol at the = "service layer".
Are
> we saying that there could be more than one way of carrying this = header but
> that the contents would be the same?

That is my interpretation.

I.e., this is an encapsulation that can be placed between the = "transport" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.

> Would the output of this WG would allow the creation of a service = chain even
> when overlays are not in use?  (This is not clear from reading = the charter.)

Well, erm, what is an "overlay"?
Isn't an overlay just a network that happens to be running over another = network?
Why would that need to be mentioned explicitly?
Why would you assume it is ruled out if it is not mentioned?

> Finally, is the work intended to support chains of both transparent = and non-
> transparent appliances, or is the focus mainly on transparent = appliances?  I
> ask because there may be interesting layering issues with respect = to the
> placement of this header, especially if we have a combination of = transparent
> and non-transparent appliances.

That is probably a good question.
Personally, I would like to put it "for investigation." I.e., I don't = think we
know enough about the use cases and requirements to answer your question = at this
stage.

But if enough people show up on the list saying that they only want to = handle
one categorisation, then perhaps we can limit from day one.

Cheers,
Adrian


_______________________________________________
nsc mailing = list
nsc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/nsc

_____________= __________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mail= man/listinfo/nsc

= --Apple-Mail=_07A5D3E8-1B2A-4AF8-A8B4-AA7D93D6B600-- --Apple-Mail=_099F41B6-7911-411A-B22C-CA358AE6A9FB 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 iQIcBAEBCgAGBQJSQCwEAAoJEPcO+I7eiUJZgcoQAKAlcDNJDArnDEu7cBpNiwgA HoG5Xk3yHGDDIlirUyzyJQunpShf2VKSReyUojY/afb1IcMQ69kqvX5gqId99p49 i482if6jh7OJsc2zQDWStGXdJ0nTRv9Z8RcCrRv5zSEDP+jJvS9wrA3BId5foJvi TTm2zYAG2S0eZFIslCbR8wNiqLnhtPTHCQ8ouOcFMqPeH4+GTQQ66472Zv1wa6b/ fqmmPNveTPZru1cOqWEfqWpRqv/p4y93zgV2C7+mPwGQltvzGeBTlMIajchRtIml n/EGUSOES+dKT3j5EVTt+PLbTyaD2j4Y82eKZ57rBB617QJMc2W3BnbqhjdQkTbx krwPuoA8WxhDxN2aumtyvZ6r4e/yuxIvcqt9z/SgYAAWeOKPF8hhs6AVWNVSTFA5 rlapTr18u/nKdwIOAhck1ASc1/C2GVZPM3NYmxUDbvBWAdSro9rs6Ga8sDC/F56Z fesn9L08OeHmCeJvFQrrRqER3yEB0jk3zZldUQr89NgygiDXPPpWlhaHEA0W/6I/ /GqeOt4s41HJjZQuR/u3K4kO7HUkkUkGt4hL1fX76DQhDUXK6RMO5frBjqhqeIH8 GfUcKwMXobQ85/5PpuIzzFoM6ShXG2PGcE3O/GIOHEEbnx8GsL92FR28AcuaVebI RwQpNR/CeI+VmQqK8iGH =smWT -----END PGP SIGNATURE----- --Apple-Mail=_099F41B6-7911-411A-B22C-CA358AE6A9FB-- From linda.dunbar@huawei.com Mon Sep 23 09:12: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 D49E421F9FA7 for ; Mon, 23 Sep 2013 09:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.109 X-Spam-Level: X-Spam-Status: No, score=-6.109 tagged_above=-999 required=5 tests=[AWL=0.490, 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 T4v3gc8rsQ6P for ; Mon, 23 Sep 2013 09:12:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B286121F9F5B for ; Mon, 23 Sep 2013 09:12: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 AYD91163; Mon, 23 Sep 2013 16:12:46 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 23 Sep 2013 17:11:55 +0100 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.146.0; Mon, 23 Sep 2013 17:12:41 +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, 23 Sep 2013 09:12:37 -0700 From: Linda Dunbar To: "adrian@olddog.co.uk" , "'Anoop Ghanwani'" Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAFjGCAABXPIWAACmS74A= Date: Mon, 23 Sep 2013 16:12:36 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> In-Reply-To: <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.59] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" Subject: Re: [nsc] 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: Mon, 23 Sep 2013 16:12:54 -0000 Adrian,=20 Just want to double check your comments > -----Original Message----- >=20 > That is my interpretation. >=20 > I.e., this is an encapsulation that can be placed between the > "transport" (e.g., > IP, MPLS, TCP, HTTP....) and the payload. [Linda] Does it mean that using IETF already defined header for encapsulati= on will NOT be excluded by the NSC (or SFC) Charter if the existing header = can carry the needed metadata among Service Functions? >=20 > > Would the output of this WG would allow the creation of a service > chain even > > when overlays are not in use? =A0(This is not clear from reading the > charter.) >=20 > Well, erm, what is an "overlay"? > Isn't an overlay just a network that happens to be running over another > network? > Why would that need to be mentioned explicitly? [Linda] I have the same question.=20 I can't tell from the wording in the charter if the charter allows the opti= on of the "metadata" among Service Functions being carried by out-of-band m= ethods, can it? Linda From adrian@olddog.co.uk Tue Sep 24 08:15:36 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAF321F9248 for ; Tue, 24 Sep 2013 08:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 Ntsyx+eZipcr for ; Tue, 24 Sep 2013 08:15:31 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id E6E9411E8159 for ; Tue, 24 Sep 2013 08:15:30 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8OFFT8a009775 for ; Tue, 24 Sep 2013 16:15:29 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8OFFSBP009755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 24 Sep 2013 16:15:28 +0100 From: "Adrian Farrel" To: Date: Tue, 24 Sep 2013 16:15:26 +0100 Message-ID: <041a01ceb938$e6927c70$b3b77550$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac65OLM5rhg5lgLcQKGKMsSbe4YZ1A== Content-Language: en-gb Subject: [nsc] Vancouver BoF approved X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 15:15:36 -0000 Hi, The IAB/IESG has just approved holding a BoF for SFC as currently described in the Wiki at http://trac.tools.ietf.org/bof/trac/ There were comments from a couple of people that they were very impressed with the progress that had been made since Berlin. If there had been an additional month between Berlin and Vancouver we might even have pushed this to become a WG. I have asked Jim to work on preparing a draft agenda for the meeting. I am anticipating that if the discussion of the charter goes well (and you do all seem to have reached a form of stability) you will get on to do some real work (maybe requirements and architecture) in the meeting. Thanks, Adrian From paulq@cisco.com Tue Sep 24 10:17: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 44B3811E8156 for ; Tue, 24 Sep 2013 10:17:33 -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 Z2rJEenzh+zv for ; Tue, 24 Sep 2013 10:17:28 -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 513DA21F992A for ; Tue, 24 Sep 2013 10:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1258; q=dns/txt; s=iport; t=1380043047; x=1381252647; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=OLEt9dsvfqEbyAED56NxVSJhl87bYhu3nPmZSTqj7CU=; b=evIKCTuWpktaF3YqVcbBTDjdvwtVSwqbBicRAMdP/eX4RERyAyNge8U2 6tY190QU6qGu4oRMTH4yhaWdJ9lj1t4ukLo7gUrCCI5avoRRk5iFqMKtI dXDDCLlbAiARP7SC4f8mod5HLdk37AzvpVPftyJL0g6SbbWMDLoQ6iwI3 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGAHDIQVKtJV2b/2dsb2JhbABagwc4UsBWgSAWbQeCJQEBAQMBOj0CEAIBGhAUEDIXBAoCBA4NARKHZAYMvD6PIDGDJIEAA5krkEiDJIIq X-IronPort-AV: E=Sophos;i="4.90,972,1371081600"; d="scan'208";a="263699269" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 24 Sep 2013 17:17:27 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8OHHQ25011424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 24 Sep 2013 17:17:26 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; Tue, 24 Sep 2013 12:17:26 -0500 From: "Paul Quinn (paulq)" To: "nsc@ietf.org" Thread-Topic: New Version Notification for draft-quinn-nsc-arch-00.txt Thread-Index: AQHOuUPbqQrgsFc3cEmq+i2pDaKPGw== Date: Tue, 24 Sep 2013 17:17:26 +0000 Message-ID: References: <20130924163350.9434.41091.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.67.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <42AF4239FEE6334A85A30E7F931445A8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Carlos Pignataro \(cpignata\)" , "Surendra Kumar \(smkumar\)" , "Jim Guichard \(jguichar\)" Subject: [nsc] Fwd: New Version Notification for draft-quinn-nsc-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: Tue, 24 Sep 2013 17:17:33 -0000 Folks, We submitted an architecture document that describes an overall SFC archite= cture, focusing on principals and components. Thanks Paul >=20 > A new version of I-D, draft-quinn-nsc-arch-00.txt > has been successfully submitted by Paul Quinn and posted to the > IETF repository. >=20 > Filename: draft-quinn-nsc-arch > Revision: 00 > Title: Service Function Chaining (SFC) Architecture > Creation date: 2013-09-23 > Group: Individual Submission > Number of pages: 17 > URL: http://www.ietf.org/internet-drafts/draft-quinn-nsc-arch= -00.txt > Status: http://datatracker.ietf.org/doc/draft-quinn-nsc-arch > Htmlized: http://tools.ietf.org/html/draft-quinn-nsc-arch-00 >=20 >=20 > Abstract: > This document describes a standard 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 adrian@olddog.co.uk Tue Sep 24 11:38: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 C43BC21F9F19 for ; Tue, 24 Sep 2013 11:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 p-FUw3xZVz4R for ; Tue, 24 Sep 2013 11:38:44 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1946911E80EC for ; Tue, 24 Sep 2013 11:38:40 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8OIcVJK007622; Tue, 24 Sep 2013 19:38:31 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8OIcUo2007612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Sep 2013 19:38:31 +0100 From: "Adrian Farrel" To: "'Linda Dunbar'" References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> Date: Tue, 24 Sep 2013 19:38:29 +0100 Message-ID: <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFg04QWmsYKG8fALD16ZmQnwUtrcgFgAU6uAa8PxyMBkBIW6wGQttblAbGnGaMB00D665pjVECA Content-Language: en-gb Cc: nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 18:38:50 -0000 Hello Linda, > > I.e., this is an encapsulation that can be placed between the > > "transport" (e.g., IP, MPLS, TCP, HTTP....) and the payload. > > [Linda] Does it mean that using IETF already defined header for encapsulation will > NOT be excluded by the NSC (or SFC) Charter if the existing header can carry the > needed metadata among Service Functions? The draft charter text says: | 3) Generic Service Function Chaining Encapsulation: A document will | describe the single service-level encapsulation protocol for conveying | the service function chain and the service function path, and for | communicating information between nodes that implement service | functions. It is intended that the encapsulation be agnostic to the | network layer at which it is applied and the service that is being | constructed. That is, the same encapsulation may be used on a | service function path realized at the network layer or at any other | layer, and the same encapsulation will apply for the construction of | service function paths regardless of the actual service. It also 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 There is no specific exclusion of using (or overloading) fields in the transport/tunnelling/encapsulation protocol. On the other hand, there is no exclusion of killing elephants and having a giant barbeque. If there is something specific you think should be in scope for the working group I suggest that *now* is the time to raise it and the mailing list can discuss. For me, I have to ask: Suppose foo is a well-known edge-to-edge tunnelling protocol. Suppose that foo has the ability to include additional information (such as TLVs) in the encapsulation header. Suppose there is a proposal to carry SFC information directly in foo. Suppose also that the WG delivers on item 3). Now, in a foo network where I want to achieve service chaining, which mechanism will I use? When I need to encapsulate foo packets in bah packets, will I need to move/copy/whatever the information from the foo header into a generic header and insert it? If there are many examples of foo, will implementations that support service chaining have to understand each way of carrying chaining information in each example of foo? Compare this with a single generic protocol. Then consider why IP has been successful. > I can't tell from the wording in the charter if the charter allows the option of the > "metadata" among Service Functions being carried by out-of-band methods, can > it? 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." 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 From linda.dunbar@huawei.com Tue Sep 24 16:02: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 592B211E80F8 for ; Tue, 24 Sep 2013 16:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.470, 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 XbNNM0PZzAPr for ; Tue, 24 Sep 2013 16:02:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5C29211E8182 for ; Tue, 24 Sep 2013 16:02:19 -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 AYF12790; Tue, 24 Sep 2013 23:02:17 +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; Wed, 25 Sep 2013 00:01:31 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 25 Sep 2013 00:02:16 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Tue, 24 Sep 2013 16:02:09 -0700 From: Linda Dunbar To: "adrian@olddog.co.uk" Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAFjGCAABXPIWAACmS74AARmqagAAGAzmg Date: Tue, 24 Sep 2013 23:02:09 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> In-Reply-To: <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.59] 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] 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, 24 Sep 2013 23:02:29 -0000 Adrian,=20 Very good analysis. Thank you.=20 "Metadata" has been used extensively in the NSC context. But beyond the "se= rvice chain ID", I can't find any other necessary information required to b= e exchanged among the "Service Functions" in all the use cases presented at= the Berlin informal BoF and use cases drafts. Can anyone give some example= s of the information required to be exchanged among those "Service Function= s" 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=20 > -----Original Message----- >=20 > 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. >=20 > 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) >=20 > 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 informatio= n on the sequence of Service Functions associated with the ID.=20 >=20 > The charter says: >=20 > | 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 >=20 > and: >=20 > | 4) Control Plane Mechanisms: A set of documents will be > | developed to describe requirements and protocols necessary > | to convey information to service function implementation > | points. Where possible, existing IETF protocols will be used > | and extended. >=20 > This feels like out-of-band exchange of information is expected. >=20 > Adrian >=20 >=20 >=20 >=20 >=20 From tnadeau@lucidvision.com Tue Sep 24 17:18: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 35C3921E8082 for ; Tue, 24 Sep 2013 17:18:03 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15l5wI3WkWpw for ; Tue, 24 Sep 2013 17:17:58 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0C811E80FB for ; Tue, 24 Sep 2013 17:17:58 -0700 (PDT) Received: from [172.28.130.28] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 735532580B24; Tue, 24 Sep 2013 20:17:56 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1F3DDA58-0CB1-4BB5-A61E-C36FF76B5914"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Nadeau In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> Date: Tue, 24 Sep 2013 20:17:53 -0400 Message-Id: <583789CD-C183-451C-B4DD-8944A1DC03B1@lucidvision.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1510) Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] 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: Wed, 25 Sep 2013 00:18:03 -0000 --Apple-Mail=_1F3DDA58-0CB1-4BB5-A61E-C36FF76B5914 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 24, 2013:7:02 PM, at 7:02 PM, Linda Dunbar = wrote: > Adrian,=20 >=20 > Very good analysis. Thank you.=20 >=20 > "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? Some examples might be OAM, other stats, service chain = descriptions, etc... --Tom > 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. =09 >=20 >=20 > Thanks, Linda=20 >=20 >> -----Original Message----- >>=20 >> 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. >>=20 >> 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) >>=20 >> We should also look at what you mean by out-of-band. I think here you >> mean >> "using some information exchange protocol." >=20 > [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.=20 >=20 >=20 >>=20 >> The charter says: >>=20 >> | 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 >>=20 >> and: >>=20 >> | 4) Control Plane Mechanisms: A set of documents will be >> | developed to describe requirements and protocols necessary >> | to convey information to service function implementation >> | points. Where possible, existing IETF protocols will be used >> | and extended. >>=20 >> This feels like out-of-band exchange of information is expected. >>=20 >> Adrian >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 --Apple-Mail=_1F3DDA58-0CB1-4BB5-A61E-C36FF76B5914 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 iQIcBAEBCgAGBQJSQiuyAAoJEPcO+I7eiUJZYlkP/3HxeEfeP1UgR9gbz4mUhLdx Lp6/1UWWdazIN+UPzMqf6R1omr/ZwZfkZfsO5YdlMqsiHbUCkOFHLqpyp/tdnuew UviG9ElT6vcVuRFTUhwBUzmKlv8atKHVHmuzclppOqPWJVLdwCKcUPtQegalQo7k 0zEyEzCMT8XWU6fyZjkHDCKA8MyVThcGQUIozeAPEfLDmeMFnHze7kojvW+zGOmG WPFzmV3E/W51fScLQj+r8hlQfKEIm/T6YxDYyrZ+IcomA/yPkdyx4Gp3nRYSyrfr umnHpibrBFZKkWO+lz9eA4VL7Tw1IIW7WKFExJvEVaP7LmQz7/5zSnhl7+2eLlRs NGZQ8d8AKZ2e6qQcpBfi8xXG7tdSfkO3iMiAppS+l35viRGINU7MPYze8kU/DcT1 74B850YqGJdCLELmfdMQMx6kysgP7HDVxjuNzmwhvF6TtRGZrYXzcNXCvwzlvHNO 8yUfN4WmsdoQSvVZMV/TLorp5BGl0OfcMoy4SkLbHIjgur9v3oKhWvIBji4fyana XkQAS1GSFMIGwojZ7i8ixgcZ1It2YzEHL3YBA/KlvVWuSzyaCsSjm6ybhk54Nubg lqATaaCqEfWxqiaky6cplkz8x4sDjZtiG6s+sLjhdj8XE3072Oba3CtMGcRTnuku RolFKuwT18NE2ZfJEZTv =7Tud -----END PGP SIGNATURE----- --Apple-Mail=_1F3DDA58-0CB1-4BB5-A61E-C36FF76B5914-- From jmoisand@juniper.net Tue Sep 24 18:50: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 82D7711E81A3 for ; Tue, 24 Sep 2013 18:50:51 -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 rxVz68BIzhKW for ; Tue, 24 Sep 2013 18:50:46 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 51A0621F9B08 for ; Tue, 24 Sep 2013 18:50:46 -0700 (PDT) Received: from mail155-co1-R.bigfish.com (10.243.78.243) by CO1EHSOBE039.bigfish.com (10.243.66.104) with Microsoft SMTP Server id 14.1.225.22; Wed, 25 Sep 2013 01:50:44 +0000 Received: from mail155-co1 (localhost [127.0.0.1]) by mail155-co1-R.bigfish.com (Postfix) with ESMTP id 2D78B78010D; Wed, 25 Sep 2013 01:50:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371I542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail155-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(51704005)(13464003)(164054003)(24454002)(199002)(189002)(74502001)(47446002)(79102001)(74706001)(33646001)(46102001)(77096001)(56816003)(47976001)(81542001)(56776001)(54316002)(51856001)(50986001)(76576001)(19580395003)(81342001)(47736001)(74366001)(49866001)(74662001)(74316001)(31966008)(80022001)(66066001)(81816001)(81686001)(63696002)(76786001)(76796001)(76482001)(59766001)(65816001)(77982001)(80976001)(74876001)(19580405001)(83322001)(53806001)(4396001)(54356001)(15975445006)(69226001)(83072001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB251; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail155-co1 (localhost.localdomain [127.0.0.1]) by mail155-co1 (MessageSwitch) id 1380073841835379_2534; Wed, 25 Sep 2013 01:50:41 +0000 (UTC) Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.226]) by mail155-co1.bigfish.com (Postfix) with ESMTP id C867960004D; Wed, 25 Sep 2013 01:50:41 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 25 Sep 2013 01:50:41 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.359.1; Wed, 25 Sep 2013 01:50:34 +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.775.9; Wed, 25 Sep 2013 01:50:33 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.237]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.237]) with mapi id 15.00.0775.005; Wed, 25 Sep 2013 01:50:33 +0000 From: Jerome Moisand To: Thomas Nadeau , Linda Dunbar Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: AQHOuYStmsYKG8fALD16ZmQnwUtrcpnVmy3Q Date: Wed, 25 Sep 2013 01:50:32 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> <583789CD-C183-451C-B4DD-8944A1DC03B1@lucidvision.com> In-Reply-To: <583789CD-C183-451C-B4DD-8944A1DC03B1@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 098076C36C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] 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: Wed, 25 Sep 2013 01:50:51 -0000 There are definitely quite a few additional candidates for metadata fields = of interest... But I believe we need much more work on the PROBLEM STATEMEN= T, and not jump to solution design.=20 We really need to work much more on use cases. Some use cases may imply mor= e 'metadata' than others. Simple problems may be solved by simple means. Mo= re complex problems may require more complex elements of solutions. Some ca= ses could be solved by signaling means instead of data plane means. Or the = reverse way around. Etc. Let me suggest we give more priority to refining the problem statement(s) f= irst... And not rush the design process. -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Nadeau Sent: Tuesday, September 24, 2013 8:18 PM To: Linda Dunbar Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 On Sep 24, 2013:7:02 PM, at 7:02 PM, Linda Dunbar = wrote: > Adrian, >=20 > Very good analysis. Thank you.=20 >=20 > "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 examp= les of the information required to be exchanged among those "Service Functi= ons" given by the draft-quinn-nsc-arch-00? Some examples might be OAM, other stats, service chain descriptions, etc..= . --Tom > 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. =09 >=20 >=20 > Thanks, Linda >=20 >> -----Original Message----- >>=20 >> I think "metadata" is a particularly poor term to use here because it=20 >> 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. >>=20 >> 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 =20 >> another service node (e.g. about how to perform given some state=20 >> information) >>=20 >> We should also look at what you mean by out-of-band. I think here you=20 >> mean "using some information exchange protocol." >=20 > [Linda] Since each Service-Chain ID represents a list of service function= s, it is possible to use "out-of-band" control channel to pass the informat= ion on the sequence of Service Functions associated with the ID.=20 >=20 >=20 >>=20 >> The charter says: >>=20 >> | 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 protocols=20 >> | or protocol extensions to convey the service path and for=20 >> | communication between nodes that implement service functions >>=20 >> and: >>=20 >> | 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. >>=20 >> This feels like out-of-band exchange of information is expected. >>=20 >> Adrian >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 From liushucheng@huawei.com Tue Sep 24 20:36: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 E867311E8199 for ; Tue, 24 Sep 2013 20:36:12 -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 bCRSzS7u-bTc for ; Tue, 24 Sep 2013 20:36:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 128EB21F92B9 for ; Tue, 24 Sep 2013 20:36:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYF26808; Wed, 25 Sep 2013 03:36:05 +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.146.0; Wed, 25 Sep 2013 04:35:18 +0100 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 25 Sep 2013 04:36:04 +0100 Received: from szxeml559-mbx.china.huawei.com ([169.254.1.2]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.03.0146.000; Wed, 25 Sep 2013 11:35:55 +0800 From: "Will Liu (Shucheng)" To: "nsc@ietf.org" Thread-Topic: New Version Notification for draft-liu-service-chaining-use-cases-02.txt Thread-Index: AQHOuZ7fpdZ3mOJiOUK8+t1whkTXvpnVyqmg Date: Wed, 25 Sep 2013 03:35:55 +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 Cc: "draft-liu-service-chaining-use-cases@tools.ietf.org" Subject: [nsc] FW: New Version Notification for draft-liu-service-chaining-use-cases-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: Wed, 25 Sep 2013 03:36:13 -0000 Rm9sa3MsDQoNCldlJ3ZlIHVwZGF0ZWQgb3VyIHVzZSBjYXNlIGRyYWZ0IGFjY29yZGluZyB0byB0 aGUgZGlzY3Vzc2lvbnMgaW4gdGhlIG1haWxpbmcgbGlzdC4gVGhlIHRleHQgc3RydWN0dXJlIGlz IG1vZGlmaWVkIGFuZCB1c2UgY2FzZXMgYXJlIGNhdGVnb3JpemVkLiBBIGNvdXBsZSBvZiBuZXcg dXNlIGNhc2VzIGFyZSBhZGRlZCBzdWNoIGFzIHVzZSBjYXNlcyBvZiBtb2JpbGUgbmV0d29yayBh bmQgREMuIEhvcGUgdGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyB0aGUgY29tbWVudHMgYXMgd2VsbCBh cyBsaW5lcyB1cCB3ZWxsIHdpdGggdGhlIG5ldyBwcm9wb3NlZCBjaGFydGVyLg0KDQpZb3VyIGNv bW1lbnRzIGFyZSBoaWdobHkgYXBwcmVjaWF0ZWQuDQoNClJlZ2FyZHMsDQpTaHVjaGVuZyBMSVUg KFdpbGwpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2Vk bmVzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTMgMTE6MjUgQU0NClRvOiBXaWxsIExpdSAoU2h1Y2hl bmcpOyBKaWUgSHU7IEhvbmd5dSBMaSAoSnVsaW8pOyBIdWFuZ3lvbmcgKE9saXZlcik7IE1vaGFt ZWQgQm91Y2FkYWlyOyBXaWxsIExpdSAoU2h1Y2hlbmcpOyBOaWNvbGFpIExleW1hbm47IFpoZW4g Q2FvDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1zZXJ2 aWNlLWNoYWluaW5nLXVzZS1jYXNlcy0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtbGl1LXNlcnZpY2UtY2hhaW5pbmctdXNlLWNhc2VzLTAyLnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBXaWxsKFNodWNoZW5nKSBMaXUgYW5kIHBvc3RlZCB0byB0 aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1saXUtc2VydmljZS1jaGFp bmluZy11c2UtY2FzZXMNClJldmlzaW9uOgkgMDINClRpdGxlOgkJIFNlcnZpY2UgRnVuY3Rpb24g Q2hhaW5pbmcgVXNlIENhc2VzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wOS0yNQ0KR3JvdXA6CQkg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE0DQpVUkw6ICAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS1zZXJ2aWNl LWNoYWluaW5nLXVzZS1jYXNlcy0wMi50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtc2VydmljZS1jaGFpbmluZy11c2UtY2FzZXMN Ckh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LXNl cnZpY2UtY2hhaW5pbmctdXNlLWNhc2VzLTAyDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxpdS1zZXJ2aWNlLWNoYWluaW5nLXVzZS1jYXNl cy0wMg0KDQpBYnN0cmFjdDoNCiAgIFRoZSBkZWxpdmVyeSBvZiB2YWx1ZS1hZGRlZCBzZXJ2aWNl cyByZWxpZXMgb24gdGhlIGludm9jYXRpb24gb2YNCiAgIGFkdmFuY2VkIFNlcnZpY2UgRnVuY3Rp b25zIGluIGEgc2VxdWVudGlhbCBvcmRlci4gIFRoaXMgbWVjaGFuaXNtIGlzDQogICBjYWxsZWQg U2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKS4gIFRoZSBzZXQgb2YgaW52b2x2ZWQgU2Vy dmljZQ0KICAgRnVuY3Rpb25zIGFuZCB0aGVpciBvcmRlciBkZXBlbmRzIG9uIHRoZSBzZXJ2aWNl IGNvbnRleHQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYSBzZXQgb2YgdXNlIGNhc2Vz IG9mIFNlcnZpY2UgRnVuY3Rpb24NCiAgIENoYWluaW5nIChTRkMpLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0K From jmh@joelhalpern.com Wed Sep 25 00:23: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 F148821F91BF for ; Wed, 25 Sep 2013 00:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 0r8u5LOj9-tz for ; Wed, 25 Sep 2013 00:23:54 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5462C21F9AD2 for ; Wed, 25 Sep 2013 00:23:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 429341C079B; Wed, 25 Sep 2013 00:23:54 -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 4FC871C049C; Wed, 25 Sep 2013 00:23:53 -0700 (PDT) Message-ID: <52428F89.4040006@joelhalpern.com> Date: Wed, 25 Sep 2013 03:23:53 -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: Linda Dunbar References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] 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: Wed, 25 Sep 2013 07:23:59 -0000 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 > From uri.elzur@intel.com Wed Sep 25 01:40: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 12EF721F9FF9 for ; Wed, 25 Sep 2013 01:40:35 -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=[AWL=0.000, 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 zzwp7HloCXC8 for ; Wed, 25 Sep 2013 01:40:30 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by ietfa.amsl.com (Postfix) with ESMTP id DC17221E8082 for ; Wed, 25 Sep 2013 01:40:26 -0700 (PDT) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 25 Sep 2013 01:40:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.90,976,1371106800"; d="scan'208";a="299105526" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by AZSMGA002.ch.intel.com with ESMTP; 25 Sep 2013 01:40:25 -0700 Received: from orsmsx105.amr.corp.intel.com ([169.254.4.17]) by ORSMSX103.amr.corp.intel.com ([169.254.2.200]) with mapi id 14.03.0123.003; Wed, 25 Sep 2013 01:40:25 -0700 From: "Elzur, Uri" To: Jerome Moisand , Thomas Nadeau , Linda Dunbar Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAFjGCAABXPIWAACmS74AARmqagAAGAzmgAAXXQIAAAzxbAAAAXDag Date: Wed, 25 Sep 2013 08:40:24 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B8995856FE06F35@ORSMSX105.amr.corp.intel.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> <583789CD-C183-451C-B4DD-8944A1DC03B1@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] 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: Wed, 25 Sep 2013 08:40:35 -0000 +1 Thx =20 Uri ("Oo-Ree") O: (949)-567-4519 C: (949)-378-7568 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jerom= e Moisand Sent: Tuesday, September 24, 2013 6:51 PM To: Thomas Nadeau; Linda Dunbar Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 There are definitely quite a few additional candidates for metadata fields = of interest... But I believe we need much more work on the PROBLEM STATEMEN= T, and not jump to solution design.=20 We really need to work much more on use cases. Some use cases may imply mor= e 'metadata' than others. Simple problems may be solved by simple means. Mo= re complex problems may require more complex elements of solutions. Some ca= ses could be solved by signaling means instead of data plane means. Or the = reverse way around. Etc. Let me suggest we give more priority to refining the problem statement(s) f= irst... And not rush the design process. -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Nadeau Sent: Tuesday, September 24, 2013 8:18 PM To: Linda Dunbar Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 On Sep 24, 2013:7:02 PM, at 7:02 PM, Linda Dunbar = wrote: > Adrian, >=20 > Very good analysis. Thank you.=20 >=20 > "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 examp= les of the information required to be exchanged among those "Service Functi= ons" given by the draft-quinn-nsc-arch-00? Some examples might be OAM, other stats, service chain descriptions, etc..= . --Tom > 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. =09 >=20 >=20 > Thanks, Linda >=20 >> -----Original Message----- >>=20 >> I think "metadata" is a particularly poor term to use here because it=20 >> 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. >>=20 >> 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=20 >> service node (e.g. about how to perform given some state >> information) >>=20 >> We should also look at what you mean by out-of-band. I think here you=20 >> mean "using some information exchange protocol." >=20 > [Linda] Since each Service-Chain ID represents a list of service function= s, it is possible to use "out-of-band" control channel to pass the informat= ion on the sequence of Service Functions associated with the ID.=20 >=20 >=20 >>=20 >> The charter says: >>=20 >> | 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 protocols=20 >> | or protocol extensions to convey the service path and for=20 >> | communication between nodes that implement service functions >>=20 >> and: >>=20 >> | 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. >>=20 >> This feels like out-of-band exchange of information is expected. >>=20 >> Adrian >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From cpignata@cisco.com Wed Sep 25 05:07: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 5FF1121F9E40 for ; Wed, 25 Sep 2013 05:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 nO998YMH-dka for ; Wed, 25 Sep 2013 05:07:23 -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 10C9221F9E91 for ; Wed, 25 Sep 2013 05:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4901; q=dns/txt; s=iport; t=1380110843; x=1381320443; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2MR//dVSCqaxT03L3WJeBwgP+eUGSW6jeghkTQQuphY=; b=RcqMB7b0V6T76RQTD1UYXzqnY6cNi48rmUhi5+QRp3+xLX2MrXUwkPJS fF0u6NCNdNaycKORqXz7hhL8L9jVUtAw9Aqp7K5987oGlY0A4jMMl/Vnv FyVM1C0KkTpyRbSZ9MRV/qQetlMWHRgJhLPzfXobm0/K21Y/YeLho9Gf9 k=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAIrQQlKtJXHA/2dsb2JhbABRCoMHOFLARIEeFnSCJQEBAQMBAQEBYgkLBQcEAgEIGAokJwslAgQOBQgGh3IGDLwRBI4OgRIxB4MdgQADkCaBL5gegySCKg X-IronPort-AV: E=Sophos;i="4.90,978,1371081600"; d="asc'?scan'208";a="261263370" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 25 Sep 2013 12:07:21 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8PC7L6x030553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 12:07:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 07:07:20 -0500 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAEgCgAABXPIWAADiaogAAN2LngAAJNV2AABGF2IAACeY+AA== Date: Wed, 25 Sep 2013 12:07:20 +0000 Message-ID: <95067C434CE250468B77282634C96ED325FA2181@xmb-aln-x02.cisco.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> <52428F89.4040006@joelhalpern.com> In-Reply-To: <52428F89.4040006@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.59] Content-Type: multipart/signed; boundary="Apple-Mail=_DD9C02A7-6B2E-4EE1-8EF0-28ED6209AFEA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" , Linda Dunbar Subject: Re: [nsc] 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: Wed, 25 Sep 2013 12:07:28 -0000 --Apple-Mail=_DD9C02A7-6B2E-4EE1-8EF0-28ED6209AFEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This, access/subscriber identification, is a good example. Another typical example is to use metadata to share the result of = ingress classification, or network information (as e.g., to be used in = subscriber identification) to then be used for policy in a service = function downstream the service path. One such example is VRF = information. Thanks, -- Carlos. On Sep 25, 2013, at 3:23 AM, Joel M. Halpern = wrote: > 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. >=20 > 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. >=20 > Yours, > Joel >=20 > On 9/24/13 7:02 PM, Linda Dunbar wrote: >> Adrian, >>=20 >> Very good analysis. Thank you. >>=20 >> "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? >>=20 >> 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. >>=20 >>=20 >> Thanks, Linda >>=20 >>> -----Original Message----- >>>=20 >>> 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. >>>=20 >>> 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) >>>=20 >>> We should also look at what you mean by out-of-band. I think here = you >>> mean >>> "using some information exchange protocol." >>=20 >> [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. >>=20 >>=20 >>>=20 >>> The charter says: >>>=20 >>> | 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 >>>=20 >>> and: >>>=20 >>> | 4) Control Plane Mechanisms: A set of documents will be >>> | developed to describe requirements and protocols necessary >>> | to convey information to service function implementation >>> | points. Where possible, existing IETF protocols will be used >>> | and extended. >>>=20 >>> This feels like out-of-band exchange of information is expected. >>>=20 >>> Adrian >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >>=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc --Apple-Mail=_DD9C02A7-6B2E-4EE1-8EF0-28ED6209AFEA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJC0fgACgkQtfDPGTp3USwbgACgkzcw/6UuKmHKkX6bsx2mqUhj YH4AoJw1w5hBbiN16ywoCo9BCzMvCFG8 =UYQa -----END PGP SIGNATURE----- --Apple-Mail=_DD9C02A7-6B2E-4EE1-8EF0-28ED6209AFEA-- From narten@us.ibm.com Wed Sep 25 07:35: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 66EA511E810D for ; Wed, 25 Sep 2013 07:35:38 -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 UIGAGNwWAxr9 for ; Wed, 25 Sep 2013 07:35:32 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id 62EBE21E805F for ; Wed, 25 Sep 2013 07:35:28 -0700 (PDT) Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Sep 2013 08:35:27 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 25 Sep 2013 08:35:24 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id D71AD1FF001C for ; Wed, 25 Sep 2013 08:35:16 -0600 (MDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8PEZ8MS304978 for ; Wed, 25 Sep 2013 08:35:11 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r8PEZ8PS003835 for ; Wed, 25 Sep 2013 08:35:08 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-228-93.mts.ibm.com [9.65.228.93]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r8PEZ81P003691; Wed, 25 Sep 2013 08:35:08 -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 r8PEZ6qo007011; Wed, 25 Sep 2013 10:35:06 -0400 Message-Id: <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> To: Anoop Ghanwani In-reply-to: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> Comments: In-reply-to Anoop Ghanwani message dated "Sun, 22 Sep 2013 09:33:28 -0700." Date: Wed, 25 Sep 2013 10:35:06 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13092514-7164-0000-0000-000001EA0C8B Cc: "nsc@ietf.org" , Adrian Farrel Subject: [nsc] transparent vs. non-transparent services [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: Wed, 25 Sep 2013 14:35:38 -0000 Hi Anoop. Anoop Ghanwani writes: > Since I have been asked the question offline, I will go ahead and explain > what I mean by transparent vs non-transparent appliances. With a > non-transparent appliance, the appliance appears as a "router" in the path > of the data. As far as I'm aware this is how load balancers are deployed > and this is how firewalls are commonly deployed. In the non-transparent > case, the address of the appliance does not appear in the packet; instead > packets are diverted to the appliance using PBR. This used sometimes for > IDS/IPS type appliances. I don't quite get this. To me, SFC is all about applying service functions to traffic flows -- but in a way that is transparent to those traffic flows and the end points originating them. That is, "applications" generating traffic aren't generally aware of these service functions and they aren't really asking for them. They are applied as the result of network policy/operations, not because the applications need them (for correctness). E.g., load balancing and firewalls. Those sorts of things are applied by network operators whether the applications want them or not. So the kinds of service functions this group is interested in are in some sense by definition "transparent" to applications. [BTW, it would be useful to have a term for the endpoints of a chain -- that is what I mean by "application" above. These are the components of the overall service that are doing the work, i.e., the DB, the application server, etc. They are *NOT* service functions, in my mind.] Service functions aren't going to be addressed by the traffic - traffic is between the "applications", i.e., the end points of a service chain. Today, service functions are deployed along the path between applications -- because that is how we know how to do it. Going forward, we don't want to *require* that anymore. So back to your example of an appliance, I would call such appliances "transparent" because they are not explicitely addressed by the traffic flows and are in fact transparent to the applications. Thomas > Anoop > On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel wrote: > > Hi Anoop, > > > > > My interpretation of the following line: > > >>> > > > A document will describe the single service-level encapsulation protocol > > for > > > conveying the service function chain and the service function path > > >>> > > > > > > is that there will be a single encapsulation protocol at the "service > > layer". > > Are > > > we saying that there could be more than one way of carrying this header > > but > > > that the contents would be the same? > > > > That is my interpretation. > > > > I.e., this is an encapsulation that can be placed between the "transport" > > (e.g., > > IP, MPLS, TCP, HTTP....) and the payload. > > > > > Would the output of this WG would allow the creation of a service chain > > even > > > when overlays are not in use? (This is not clear from reading the > > charter.) > > > > Well, erm, what is an "overlay"? > > Isn't an overlay just a network that happens to be running over another > > network? > > Why would that need to be mentioned explicitly? > > Why would you assume it is ruled out if it is not mentioned? > > > > > Finally, is the work intended to support chains of both transparent and > > non- > > > transparent appliances, or is the focus mainly on transparent > > appliances? I > > > ask because there may be interesting layering issues with respect to the > > > placement of this header, especially if we have a combination of > > transparent > > > and non-transparent appliances. > > > > That is probably a good question. > > Personally, I would like to put it "for investigation." I.e., I don't > > think we > > know enough about the use cases and requirements to answer your question > > at this > > stage. > > > > But if enough people show up on the list saying that they only want to > > handle > > one categorisation, then perhaps we can limit from day one. > > > > Cheers, > > Adrian > > > > > --001a11c227eea3624604e6fb76cb > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable >
Hi Adrian,

>>>
That = > is my interpretation.

I.e., this is an encapsulation that can be pla= > ced between the "transport" (e.g.,
IP, MPLS, TCP, HTTP....) an= > d the payload.
>
>>>

OK, I think that's a bit dif= > ferent from what Uri was arguing for.

>>>= >
Well, erm, what is an "overlay"?
Isn't an overl= > ay just a network that happens to be running over another network?
> Why would that need to be mentioned explicitly?
Why would you assume it = > is ruled out if it is not mentioned?
>>>
<= > br>
I tend to think of an overlay as one where there are multiple= > occurrences of the same layer of =A0header in the packet., but maybe I hav= > e it wrong. =A0Does the IETF have a formal definition for this?
>

>>>
That is probably a good question= > .
Personally, I would like to put it "for investigation." I.e.= > , I don't think we
know enough about the use cases and requirements = > to answer your question at this
> stage.

But if enough people show up on the list saying that they onl= > y want to handle
one categorisation, then perhaps we can limit from day = > one.
>>>
tra"> >
I think it would make sense to add som= > ething explicit to the charter about this.
= >
Since I have been asked the question o= > ffline, I will go ahead and explain what I mean by transparent vs non-trans= > parent appliances. =A0With a non-transparent appliance, the appliance appea= > rs as a "router" in the path of the data. =A0As far as I'm aw= > are this is how load balancers are deployed and this is how firewalls are c= > ommonly deployed. =A0In the non-transparent case, the address of the applia= > nce does not appear in the packet; instead packets are diverted to the appl= > iance using PBR. =A0This used sometimes for IDS/IPS type appliances.
>

Anoop
r>
On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel= > < ank">adrian@olddog.co.uk> wrote:
>
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= > adding-left:1ex">Hi Anoop,
>

> > My interpretation of the following line:
> >>>
> > A document will describe the single service-level encapsulation protoc= > ol for
> > conveying the service function chain and the service function path
> >>>
> >
> > is that there will be a single encapsulation protocol at the "ser= > vice layer".
> Are
> > we saying that there could be more than one way of carrying this heade= > r but
> > that the contents would be the same?
>
>
That is my interpretation.
>
> I.e., this is an encapsulation that can be placed between the "transpo= > rt" (e.g.,
> IP, MPLS, TCP, HTTP....) and the payload.
>

> > Would the output of this WG would allow the creation of a service chai= > n even
> > when overlays are not in use? =A0(This is not clear from reading the c= > harter.)
>
>
Well, erm, what is an "overlay"?
> Isn't an overlay just a network that happens to be running over another= > network?
> Why would that need to be mentioned explicitly?
> Why would you assume it is ruled out if it is not mentioned?
>

> > Finally, is the work intended to support chains of both transparent an= > d non-
> > transparent appliances, or is the focus mainly on transparent applianc= > es? =A0I
> > ask because there may be interesting layering issues with respect to t= > he
> > placement of this header, especially if we have a combination of trans= > parent
> > and non-transparent appliances.
>
>
That is probably a good question.
> Personally, I would like to put it "for investigation." I.e., I d= > on't think we
> know enough about the use cases and requirements to answer your question at= > this
> stage.
>
> But if enough people show up on the list saying that they only want to hand= > le
> one categorisation, then perhaps we can limit from day one.
>
> Cheers,
> Adrian
>
>

> --001a11c227eea3624604e6fb76cb-- > --===============0224793606959901704== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > --===============0224793606959901704==-- From Ron_Parker@affirmednetworks.com Wed Sep 25 07:53: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 B880421F9E39 for ; Wed, 25 Sep 2013 07:53:00 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaP3iYhpjS+b for ; Wed, 25 Sep 2013 07:52:56 -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 0912D21F9E11 for ; Wed, 25 Sep 2013 07:52:55 -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; Wed, 25 Sep 2013 07:52:51 -0700 From: Ron Parker To: Thomas Narten , Anoop Ghanwani Thread-Topic: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3] Thread-Index: AQHOufyF35Madjcy/kOUwQkC4b68NJnWiCNw Date: Wed, 25 Sep 2013 14:52:50 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> In-Reply-To: <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , Adrian Farrel Subject: Re: [nsc] transparent vs. non-transparent services [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: Wed, 25 Sep 2013 14:53:00 -0000 Thomas, Anoop, It strikes me that this transparency is not wrt to the originator or addres= see of the traffic, but rather between the SFC classifier and the SFC servi= ce nodes (SNs). In particular, whether an encapsulating "transport" head= er (e.g., IPv4/UDP) is applied in front of the NSC/SFC "service header" (wh= ich is in front of the original packet), or not. If an IP-layer encapsulation is applied, for example, the packets are route= d/switched normally amongst the SFC classifier and SN's because the packets= are explicitly IP addressed at each hop (given that the SN's would need to= change the destination IP in the encapsulating header to select the "next"= SN). However, if a "transport" header is not applied, policy-based routi= ng/switching would need to be used to steer the traffic in such a way that = did not necessarily conform to traditional routing/switching decisions. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Narten Sent: Wednesday, September 25, 2013 10:35 AM To: Anoop Ghanwani Cc: nsc@ietf.org; Adrian Farrel Subject: [nsc] transparent vs. non-transparent services [was Re: New NSC WG= Charter - charter bullet #3] Hi Anoop. Anoop Ghanwani writes: > Since I have been asked the question offline, I will go ahead and=20 > explain what I mean by transparent vs non-transparent appliances. =20 > With a non-transparent appliance, the appliance appears as a "router"=20 > in the path of the data. As far as I'm aware this is how load=20 > balancers are deployed and this is how firewalls are commonly=20 > deployed. In the non-transparent case, the address of the appliance=20 > does not appear in the packet; instead packets are diverted to the=20 > appliance using PBR. This used sometimes for IDS/IPS type appliances. I don't quite get this. To me, SFC is all about applying service functions = to traffic flows -- but in a way that is transparent to those traffic flows= and the end points originating them. That is, "applications" generating tr= affic aren't generally aware of these service functions and they aren't rea= lly asking for them. They are applied as the result of network policy/opera= tions, not because the applications need them (for correctness). E.g., load= balancing and firewalls. Those sorts of things are applied by network ope= rators whether the applications want them or not. So the kinds of service f= unctions this group is interested in are in some sense by definition "trans= parent" to applications. [BTW, it would be useful to have a term for the endpoints of a chain -- that is what I mean by "application" above. These are the components of = the overall service that are doing the work, i.e., the DB, the application = server, etc. They are *NOT* service functions, in my mind.] Service functions aren't going to be addressed by the traffic - traffic is = between the "applications", i.e., the end points of a service chain. Today, service functions are deployed along the path between applications -= - because that is how we know how to do it. Going forward, we don't want to= *require* that anymore.=20 So back to your example of an appliance, I would call such appliances "tran= sparent" because they are not explicitely addressed by the traffic flows an= d are in fact transparent to the applications. Thomas > Anoop > On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel wrot= e: > > Hi Anoop, > > > > > My interpretation of the following line: > > >>> > > > A document will describe the single service-level encapsulation=20 > > > protocol > > for > > > conveying the service function chain and the service function path > > >>> > > > > > > is that there will be a single encapsulation protocol at the=20 > > > "service > > layer". > > Are > > > we saying that there could be more than one way of carrying this=20 > > > header > > but > > > that the contents would be the same? > > > > That is my interpretation. > > > > I.e., this is an encapsulation that can be placed between the "transpor= t" > > (e.g., > > IP, MPLS, TCP, HTTP....) and the payload. > > > > > Would the output of this WG would allow the creation of a service=20 > > > chain > > even > > > when overlays are not in use? (This is not clear from reading the > > charter.) > > > > Well, erm, what is an "overlay"? > > Isn't an overlay just a network that happens to be running over=20 > > another network? > > Why would that need to be mentioned explicitly? > > Why would you assume it is ruled out if it is not mentioned? > > > > > Finally, is the work intended to support chains of both=20 > > > transparent and > > non- > > > transparent appliances, or is the focus mainly on transparent > > appliances? I > > > ask because there may be interesting layering issues with respect=20 > > > to the placement of this header, especially if we have a=20 > > > combination of > > transparent > > > and non-transparent appliances. > > > > That is probably a good question. > > Personally, I would like to put it "for investigation." I.e., I=20 > > don't think we know enough about the use cases and requirements to=20 > > answer your question at this stage. > > > > But if enough people show up on the list saying that they only want=20 > > to handle one categorisation, then perhaps we can limit from day=20 > > one. > > > > Cheers, > > Adrian > > > > > --001a11c227eea3624604e6fb76cb > Content-Type: text/html; charset=3DISO-8859-1 > Content-Transfer-Encoding: quoted-printable >
Hi=20 > Adrian,

>>>
That =3D is my=20 > interpretation.

I.e., this is an encapsulation that can be pla=3D= =20 > ced between the "transport" (e.g.,
IP, MPLS, TCP,=20 > HTTP....) an=3D d the payload.
=20 >
>>>

OK, I think that's a=20 > bit dif=3D ferent from what Uri was arguing=20 > for.

>>>=3D >
Well, erm, what is an "overlay"?
Isn't an=20 > overl=3D ay just a network that happens to be running over another=20 > network?
Why would that need to be mentioned explicitly?
Why=20 > would you assume it =3D is ruled out if it is not=20 > mentioned?
>>>
<=3D > br>
I tend to think of an overlay as one where there are=20 > br>multiple=3D > occurrences of the same layer of =3DA0header in the packet., but maybe=20 > I hav=3D e it wrong. =3DA0Does the IETF have a formal definition for=20 > this?

>>>
That is=20 > probably a good question=3D .
Personally, I would like to put it=20 > "for investigation." I.e.=3D , I don't think we
know=20 > enough about the use cases and requirements =3D to answer your question=20 > at this
stage.

But if enough people show up on the list=20 > saying that they onl=3D y want to handle
one categorisation, then=20 > perhaps we can limit from day =3D one.
class=3D3D"gmail_extra">>>>
I think it would make sense to=20 > add som=3D ething explicit to the charter about this.
class=3D3D"gmail_extra">=3D
Since = I=20 > have been asked the question o=3D ffline, I will go ahead and explain=20 > what I mean by transparent vs non-trans=3D parent appliances. =3DA0With a= =20 > non-transparent appliance, the appliance appea=3D rs as a=20 > "router" in the path of the data. =3DA0As far as I'm aw=3D= =20 > are this is how load balancers are deployed and this is how firewalls=20 > are c=3D ommonly deployed. =3DA0In the non-transparent case, the address= =20 > of the applia=3D nce does not appear in the packet; instead packets are=20 > diverted to the appl=3D iance using PBR. =3DA0This used sometimes for=20 > IDS/IPS type appliances.
class=3D3D"gmail_extra">
class=3D3D"gmail_extra">Anoop
r>
On Sun, Sep 22, 2013 at 6:11 AM, Adrian=20 > r>Farrel=3D > < target=3D3D"_bl=3D ank">adrian@olddog.co.uk> wrote:
=20 >
0.8ex;border-=3D=20 > left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so > lid;p=3D > adding-left:1ex">Hi Anoop,
>

> > My interpretation of the following line:
>>>
=20 > > A document will describe the single service-level encapsulation=20 > protoc=3D ol for
> conveying the service function chain and the=20 > service function path
>>>
>
> is that there=20 > will be a single encapsulation protocol at the "ser=3D vice=20 > layer".
Are
> we saying that there could be more than=20 > one way of carrying this heade=3D r but
> that the contents would= =20 > be the same?

That is my interpretation.

I.e.,=20 > this is an encapsulation that can be placed between the "transpo=3D= =20 > rt" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.
class=3D3D"im">
> Would the output of this WG would allow the=20 > creation of a service chai=3D n even
> when overlays are not in=20 > use? =3DA0(This is not clear from reading the c=3D harter.)

=20 >
Well, erm, what is an "overlay"?
Isn't an=20 > overlay just a network that happens to be running over another=3D =20 > network?
Why would that need to be mentioned explicitly?
Why=20 > would you assume it is ruled out if it is not mentioned?
class=3D3D"im">
> Finally, is the work intended to support chains= =20 > of both transparent an=3D d non-
> transparent appliances, or is=20 > the focus mainly on transparent applianc=3D es? =3DA0I
> ask=20 > because there may be interesting layering issues with respect to t=3D=20 > he
> placement of this header, especially if we have a=20 > combination of trans=3D parent
> and non-transparent=20 > appliances.

That is probably a good question.
=20 > Personally, I would like to put it "for investigation."=20 > I.e., I d=3D on't think we
know enough about the use cases and=20 > requirements to answer your question at=3D this
stage.

But= =20 > if enough people show up on the list saying that they only want to=20 > hand=3D le
one categorisation, then perhaps we can limit from day=20 > one.

Cheers,
Adrian

=20 >

> --001a11c227eea3624604e6fb76cb-- > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0224793606959901704=3D=3D > Content-Type: text/plain; charset=3D"us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0224793606959901704=3D=3D-= - _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From adrian@olddog.co.uk Wed Sep 25 08:45: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 CFF5A11E8118 for ; Wed, 25 Sep 2013 08:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Eo3YNinsufMV for ; Wed, 25 Sep 2013 08:44:58 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7AE11E8115 for ; Wed, 25 Sep 2013 08:44:56 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8PFiiOx018614; Wed, 25 Sep 2013 16:44:44 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8PFihFB018604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Sep 2013 16:44:43 +0100 From: "Adrian Farrel" To: "'Ron Parker'" , "'Thomas Narten'" , "'Anoop Ghanwani'" References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> In-Reply-To: Date: Wed, 25 Sep 2013 16:44:41 +0100 Message-ID: <064001ceba06$27012680$75037380$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFg04QWmsYKG8fALD16ZmQnwUtrcgFgAU6uAa8PxyMBkBIW6wGQttblAbGnGaMBv0EZ/wHyjkOYAXDdn7CaSkLrsA== Content-Language: en-gb Cc: nsc@ietf.org Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:45:03 -0000 I *think* the distinction being made is... Does the packet follow the path it would have followed absent the imposition of a service function? If so, the service function is applied transparently. If not, the packet is somehow diverted (e.g. down a tunnel, by stealing the destination address field, etc.) and the service function is applied non-transparently. If I am right in this, then I think it is not helpful to talk about transparent or non-transparent services (or service functions), but how they are applied or realised for a particular flow. Adrian > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: 25 September 2013 15:53 > To: Thomas Narten; Anoop Ghanwani > Cc: nsc@ietf.org; Adrian Farrel > Subject: RE: [nsc] transparent vs. non-transparent services [was Re: New NSC > WG Charter - charter bullet #3] > > Thomas, Anoop, > > It strikes me that this transparency is not wrt to the originator or addressee of the > traffic, but rather between the SFC classifier and the SFC service nodes (SNs). In > particular, whether an encapsulating "transport" header (e.g., IPv4/UDP) is > applied in front of the NSC/SFC "service header" (which is in front of the original > packet), or not. > > If an IP-layer encapsulation is applied, for example, the packets are > routed/switched normally amongst the SFC classifier and SN's because the > packets are explicitly IP addressed at each hop (given that the SN's would need to > change the destination IP in the encapsulating header to select the "next" SN). > However, if a "transport" header is not applied, policy-based routing/switching > would need to be used to steer the traffic in such a way that did not necessarily > conform to traditional routing/switching decisions. > > Ron > > > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thomas > Narten > Sent: Wednesday, September 25, 2013 10:35 AM > To: Anoop Ghanwani > Cc: nsc@ietf.org; Adrian Farrel > Subject: [nsc] transparent vs. non-transparent services [was Re: New NSC WG > Charter - charter bullet #3] > > Hi Anoop. > > Anoop Ghanwani writes: > > > Since I have been asked the question offline, I will go ahead and > > explain what I mean by transparent vs non-transparent appliances. > > With a non-transparent appliance, the appliance appears as a "router" > > in the path of the data. As far as I'm aware this is how load > > balancers are deployed and this is how firewalls are commonly > > deployed. In the non-transparent case, the address of the appliance > > does not appear in the packet; instead packets are diverted to the > > appliance using PBR. This used sometimes for IDS/IPS type appliances. > > I don't quite get this. To me, SFC is all about applying service functions to traffic > flows -- but in a way that is transparent to those traffic flows and the end points > originating them. That is, "applications" generating traffic aren't generally aware > of these service functions and they aren't really asking for them. They are applied > as the result of network policy/operations, not because the applications need > them (for correctness). E.g., load balancing and firewalls. Those sorts of things > are applied by network operators whether the applications want them or not. So > the kinds of service functions this group is interested in are in some sense by > definition "transparent" to applications. > > [BTW, it would be useful to have a term for the endpoints of a chain > -- that is what I mean by "application" above. These are the components of the > overall service that are doing the work, i.e., the DB, the application server, etc. > They are *NOT* service functions, in my mind.] > > Service functions aren't going to be addressed by the traffic - traffic is between > the "applications", i.e., the end points of a service chain. > > Today, service functions are deployed along the path between applications -- > because that is how we know how to do it. Going forward, we don't want to > *require* that anymore. > > So back to your example of an appliance, I would call such appliances > "transparent" because they are not explicitely addressed by the traffic flows and > are in fact transparent to the applications. > > Thomas > > > > > Anoop > > > On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel wrote: > > > > Hi Anoop, > > > > > > > My interpretation of the following line: > > > >>> > > > > A document will describe the single service-level encapsulation > > > > protocol > > > for > > > > conveying the service function chain and the service function path > > > >>> > > > > > > > > is that there will be a single encapsulation protocol at the > > > > "service > > > layer". > > > Are > > > > we saying that there could be more than one way of carrying this > > > > header > > > but > > > > that the contents would be the same? > > > > > > That is my interpretation. > > > > > > I.e., this is an encapsulation that can be placed between the "transport" > > > (e.g., > > > IP, MPLS, TCP, HTTP....) and the payload. > > > > > > > Would the output of this WG would allow the creation of a service > > > > chain > > > even > > > > when overlays are not in use? (This is not clear from reading the > > > charter.) > > > > > > Well, erm, what is an "overlay"? > > > Isn't an overlay just a network that happens to be running over > > > another network? > > > Why would that need to be mentioned explicitly? > > > Why would you assume it is ruled out if it is not mentioned? > > > > > > > Finally, is the work intended to support chains of both > > > > transparent and > > > non- > > > > transparent appliances, or is the focus mainly on transparent > > > appliances? I > > > > ask because there may be interesting layering issues with respect > > > > to the placement of this header, especially if we have a > > > > combination of > > > transparent > > > > and non-transparent appliances. > > > > > > That is probably a good question. > > > Personally, I would like to put it "for investigation." I.e., I > > > don't think we know enough about the use cases and requirements to > > > answer your question at this stage. > > > > > > But if enough people show up on the list saying that they only want > > > to handle one categorisation, then perhaps we can limit from day > > > one. > > > > > > Cheers, > > > Adrian > > > > > > > > > --001a11c227eea3624604e6fb76cb > > Content-Type: text/html; charset=ISO-8859-1 > > Content-Transfer-Encoding: quoted-printable > > >
Hi > > Adrian,

>>>
That = is my > > interpretation.

I.e., this is an encapsulation that can be pla= > > ced between the "transport" (e.g.,
IP, MPLS, TCP, > > HTTP....) an= d the payload.
> >
>>>

OK, I think that's a > > bit dif= ferent from what Uri was arguing > > for.

>>>= > >
Well, erm, what is an "overlay"?
Isn't an > > overl= ay just a network that happens to be running over another > > network?
Why would that need to be mentioned explicitly?
Why > > would you assume it = is ruled out if it is not > > mentioned?
>>>
<= > > br>
I tend to think of an overlay as one where there are > > br>multiple= > > occurrences of the same layer of =A0header in the packet., but maybe > > I hav= e it wrong. =A0Does the IETF have a formal definition for > > this?

>>>
That is > > probably a good question= .
Personally, I would like to put it > > "for investigation." I.e.= , I don't think we
know > > enough about the use cases and requirements = to answer your question > > at this
stage.

But if enough people show up on the list > > saying that they onl= y want to handle
one categorisation, then > > perhaps we can limit from day = one.
> class=3D"gmail_extra">>>>
> >
I think it would make sense to > > add som= ething explicit to the charter about this.
> class=3D"gmail_extra">=
Since I > > have been asked the question o= ffline, I will go ahead and explain > > what I mean by transparent vs non-trans= parent appliances. =A0With a > > non-transparent appliance, the appliance appea= rs as a > > "router" in the path of the data. =A0As far as I'm aw= > > are this is how load balancers are deployed and this is how firewalls > > are c= ommonly deployed. =A0In the non-transparent case, the address > > of the applia= nce does not appear in the packet; instead packets are > > diverted to the appl= iance using PBR. =A0This used sometimes for > > IDS/IPS type appliances.
> class=3D"gmail_extra">
> class=3D"gmail_extra">Anoop
> r>
On Sun, Sep 22, 2013 at 6:11 AM, Adrian > > r>Farrel= > > < > target=3D"_bl= ank">adrian@olddog.co.uk> wrote:
> >
> 0.8ex;border-= > > left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so > > lid;p= > > adding-left:1ex">Hi Anoop,
> >

> > > My interpretation of the following line:
>>>
> > > A document will describe the single service-level encapsulation > > protoc= ol for
> conveying the service function chain and the > > service function path
>>>
>
> is that there > > will be a single encapsulation protocol at the "ser= vice > > layer".
Are
> we saying that there could be more than > > one way of carrying this heade= r but
> that the contents would > > be the same?

That is my interpretation.

I.e., > > this is an encapsulation that can be placed between the "transpo= > > rt" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.
> class=3D"im">
> Would the output of this WG would allow the > > creation of a service chai= n even
> when overlays are not in > > use? =A0(This is not clear from reading the c= harter.)

> >
Well, erm, what is an "overlay"?
Isn't an > > overlay just a network that happens to be running over another= > > network?
Why would that need to be mentioned explicitly?
Why > > would you assume it is ruled out if it is not mentioned?
> class=3D"im">
> Finally, is the work intended to support chains > > of both transparent an= d non-
> transparent appliances, or is > > the focus mainly on transparent applianc= es? =A0I
> ask > > because there may be interesting layering issues with respect to t= > > he
> placement of this header, especially if we have a > > combination of trans= parent
> and non-transparent > > appliances.

That is probably a good question.
> > Personally, I would like to put it "for investigation." > > I.e., I d= on't think we
know enough about the use cases and > > requirements to answer your question at= this
stage.

But > > if enough people show up on the list saying that they only want to > > hand= le
one categorisation, then perhaps we can limit from day > > one.

Cheers,
Adrian

> >

> > > --001a11c227eea3624604e6fb76cb-- > > > --===============0224793606959901704== > > Content-Type: text/plain; charset="us-ascii" > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > > --===============0224793606959901704==-- > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From david.i.allan@ericsson.com Wed Sep 25 09:21: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 1C1E221F92B2 for ; Wed, 25 Sep 2013 09:21:44 -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 OzRwepHxcNB9 for ; Wed, 25 Sep 2013 09:21:38 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8720D21F9DF0 for ; Wed, 25 Sep 2013 09:21:38 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-2d-52430d916465 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9D.1D.03458.19D03425; Wed, 25 Sep 2013 18:21:38 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Wed, 25 Sep 2013 12:20:48 -0400 From: David Allan I To: Jerome Moisand , Thomas Nadeau , Linda Dunbar Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAD+gvAABXPISAADiaowAAN2LngAAJNV2AAAKlHIAAAzxbAAAV2qSA Date: Wed, 25 Sep 2013 16:20:48 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> <583789CD-C183-451C-B4DD-8944A1DC03B1@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPrO4kXucggykLOCx+9NxgtuhbFWxx t2Uik8XxffvZLB5OvsTuwOrRcuQtq8eSJT+ZPK43XWX32PpkCbvHis0rGQNYo7hsUlJzMstS i/TtErgyurb3MRbcVKnoOODawPhbtouRk0NCwERi0/6T7BC2mMSFe+vZuhi5OIQEjjJK9E+/ xgjhLGeU2P7gIBNIFZuAgcSe/1+AEhwcIgI1EhuPhYKEmQX8JA5NXc8IYgsLWErs2/iVGcQW EbCS2PB3MTvIHBGBJkaJtZvmgs1hEVCVmPRtHwuIzSvgK/Fp2zJmiGU3WSXmXO1gBUlwCoRJ /Dv9Bew8RqDzvp9awwSxTVzi1pP5TBBnC0gs2XOeGcIWlXj5+B8rhK0sseTJfhaIeh2JBbs/ sUHY2hLLFr5mhlgsKHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxi5CgtTi3LTTcy3MQIjLBj EmyOOxgXfLI8xCjNwaIkzrtB70ygkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaGDwx5beUr XrXfqzkVHrvkuzOPI8PRL/4xp7zuRb1+8D7fR2Oqt8uZTS23bx8q0bEzZfB29q+SuJ7v8WiC aB3X8daJ51ZlFs5xOsNcMF/v/a+q+sDwVofKxytdVqZP6/LdvuTyzXluzLyRhR1eDYpn5q8/ tjdFLYpz7ybDqZOuFet37v7MfE+JpTgj0VCLuag4EQBcg6yXfgIAAA== Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] 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: Wed, 25 Sep 2013 16:21:44 -0000 I'm not a fan of encapsulating the frame in a database before forwarding...= . I understand Joel's use case of carrying the subscriber ID (assuming the en= tire frame presented to a BNG is not preserved), and the need for a chain I= D as a forwarding "helper". These two items strike me as both "necessary an= d sufficient". Cheers Dave=20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jerom= e Moisand Sent: Tuesday, September 24, 2013 6:51 PM To: Thomas Nadeau; Linda Dunbar Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 There are definitely quite a few additional candidates for metadata fields = of interest... But I believe we need much more work on the PROBLEM STATEMEN= T, and not jump to solution design.=20 We really need to work much more on use cases. Some use cases may imply mor= e 'metadata' than others. Simple problems may be solved by simple means. Mo= re complex problems may require more complex elements of solutions. Some ca= ses could be solved by signaling means instead of data plane means. Or the = reverse way around. Etc. Let me suggest we give more priority to refining the problem statement(s) f= irst... And not rush the design process. -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Nadeau Sent: Tuesday, September 24, 2013 8:18 PM To: Linda Dunbar Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 On Sep 24, 2013:7:02 PM, at 7:02 PM, Linda Dunbar = wrote: > Adrian, >=20 > Very good analysis. Thank you.=20 >=20 > "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 examp= les of the information required to be exchanged among those "Service Functi= ons" given by the draft-quinn-nsc-arch-00? Some examples might be OAM, other stats, service chain descriptions, etc..= . --Tom > 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. =09 >=20 >=20 > Thanks, Linda >=20 >> -----Original Message----- >>=20 >> I think "metadata" is a particularly poor term to use here because it=20 >> 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. >>=20 >> 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=20 >> service node (e.g. about how to perform given some state >> information) >>=20 >> We should also look at what you mean by out-of-band. I think here you=20 >> mean "using some information exchange protocol." >=20 > [Linda] Since each Service-Chain ID represents a list of service function= s, it is possible to use "out-of-band" control channel to pass the informat= ion on the sequence of Service Functions associated with the ID.=20 >=20 >=20 >>=20 >> The charter says: >>=20 >> | 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 protocols=20 >> | or protocol extensions to convey the service path and for=20 >> | communication between nodes that implement service functions >>=20 >> and: >>=20 >> | 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. >>=20 >> This feels like out-of-band exchange of information is expected. >>=20 >> Adrian >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From adrian@olddog.co.uk Wed Sep 25 09:43: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 AFC4221F9E26 for ; Wed, 25 Sep 2013 09:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 wFFNkLER32P5 for ; Wed, 25 Sep 2013 09:43:33 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 9D83621F997D for ; Wed, 25 Sep 2013 09:43:33 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8PGhTi5023379; Wed, 25 Sep 2013 17:43:29 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8PGhSMR023366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Sep 2013 17:43:29 +0100 From: "Adrian Farrel" To: Date: Wed, 25 Sep 2013 17:43:27 +0100 Message-ID: <066301ceba0e$5c717150$155453f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac66Dh1vE6D3d9AKSBiTvp5XksBMBA== Content-Language: en-gb Cc: stbryant@cisco.com Subject: [nsc] BoF chairs X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:43:39 -0000 Hi, Stewart and I have appointed Jim and Thomas to chair the SFC BoF in Vancouver (they seemed to get out of Berlin without being stoned to death). Please take your dreams and aspirations to them for discussion. Adrian From paulq@cisco.com Wed Sep 25 10:07: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 5F74A21F9344 for ; Wed, 25 Sep 2013 10:07:05 -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 yRkQa9XRXpmJ for ; Wed, 25 Sep 2013 10:07:00 -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 A888621F9A16 for ; Wed, 25 Sep 2013 10:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13626; q=dns/txt; s=iport; t=1380128809; x=1381338409; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bBVL+7m289tKDk5fPezi0Dew+vsttMV0+UB9NGHxc8I=; b=EBrHk3rZuXohqSFJmILKX6iWBvqqE3+NFMB18BbnpGBMehJ/UsRvv9Jf BCI6ILu7HaY4nOxAkbDGcmHQGxmGBuqnJIm6691pwKLiLGI7zHay7/PAK vJOr+ViIu1E1/Z+WR2ZeV748+k6QKINmUxeiJF4rawmc7IixctzuddfmT Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFANsWQ1KtJV2d/2dsb2JhbABbgwc4UsBHgR4WdIIlAQEBAwEBAQE3KwkGBQUHBAIBCBEEAQEBChQFBAcnCxQJCAIECgQFCId4Bgy8AQSOE4ELAjEHBoMXgQADqXOBZoE+gWlB X-IronPort-AV: E=Sophos;i="4.90,979,1371081600"; d="scan'208";a="261387731" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 25 Sep 2013 17:06:44 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8PH6iTW016288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 17:06:44 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 12:06:44 -0500 From: "Paul Quinn (paulq)" To: "" Thread-Topic: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3] Thread-Index: AQHOugY4BY28kcaVSUOpO28tjUrIV5nXAw+A Date: Wed, 25 Sep 2013 17:06:43 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> <064001ceba06$27012680$75037380$@olddog.co.uk> In-Reply-To: <064001ceba06$27012680$75037380$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.172.246] Content-Type: text/plain; charset="us-ascii" Content-ID: <00E769DC686553449EEB88A59261A6CF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "" , Anoop Ghanwani , Ron Parker Subject: Re: [nsc] transparent vs. non-transparent services [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: Wed, 25 Sep 2013 17:07:05 -0000 Hi, I think there's a further nuance, at least in the service world that is dif= ferent separate from native path vs. diversion/steering discussion. A tran= sparent service acts a "bump in the wire", the most common example. A non-= transparent service terminates the traffic (e.g. the original TCP session),= performs some action, then forwards the traffic via a new connection or mi= micking the original one. Thanks Paul On Sep 25, 2013, at 8:44 AM, Adrian Farrel wrote: > I *think* the distinction being made is... >=20 > Does the packet follow the path it would have followed absent the imposit= ion of > a service function? If so, the service function is applied transparently.= If > not, the packet is somehow diverted (e.g. down a tunnel, by stealing the > destination address field, etc.) and the service function is applied > non-transparently. >=20 > If I am right in this, then I think it is not helpful to talk about trans= parent > or non-transparent services (or service functions), but how they are appl= ied or > realised for a particular flow. >=20 > Adrian >=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: 25 September 2013 15:53 >> To: Thomas Narten; Anoop Ghanwani >> Cc: nsc@ietf.org; Adrian Farrel >> Subject: RE: [nsc] transparent vs. non-transparent services [was Re: New= NSC >> WG Charter - charter bullet #3] >>=20 >> Thomas, Anoop, >>=20 >> It strikes me that this transparency is not wrt to the originator or add= ressee > of the >> traffic, but rather between the SFC classifier and the SFC service nodes > (SNs). In >> particular, whether an encapsulating "transport" header (e.g., IPv4/UDP)= is >> applied in front of the NSC/SFC "service header" (which is in front of t= he > original >> packet), or not. >>=20 >> If an IP-layer encapsulation is applied, for example, the packets are >> routed/switched normally amongst the SFC classifier and SN's because the >> packets are explicitly IP addressed at each hop (given that the SN's wou= ld > need to >> change the destination IP in the encapsulating header to select the "nex= t" > SN). >> However, if a "transport" header is not applied, policy-based > routing/switching >> would need to be used to steer the traffic in such a way that did not > necessarily >> conform to traditional routing/switching decisions. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Th= omas >> Narten >> Sent: Wednesday, September 25, 2013 10:35 AM >> To: Anoop Ghanwani >> Cc: nsc@ietf.org; Adrian Farrel >> Subject: [nsc] transparent vs. non-transparent services [was Re: New NSC= WG >> Charter - charter bullet #3] >>=20 >> Hi Anoop. >>=20 >> Anoop Ghanwani writes: >>=20 >>> Since I have been asked the question offline, I will go ahead and >>> explain what I mean by transparent vs non-transparent appliances. >>> With a non-transparent appliance, the appliance appears as a "router" >>> in the path of the data. As far as I'm aware this is how load >>> balancers are deployed and this is how firewalls are commonly >>> deployed. In the non-transparent case, the address of the appliance >>> does not appear in the packet; instead packets are diverted to the >>> appliance using PBR. This used sometimes for IDS/IPS type appliances. >>=20 >> I don't quite get this. To me, SFC is all about applying service functio= ns to > traffic >> flows -- but in a way that is transparent to those traffic flows and the= end > points >> originating them. That is, "applications" generating traffic aren't gene= rally > aware >> of these service functions and they aren't really asking for them. They = are > applied >> as the result of network policy/operations, not because the applications= need >> them (for correctness). E.g., load balancing and firewalls. Those sorts= of > things >> are applied by network operators whether the applications want them or n= ot. So >> the kinds of service functions this group is interested in are in some s= ense > by >> definition "transparent" to applications. >>=20 >> [BTW, it would be useful to have a term for the endpoints of a chain >> -- that is what I mean by "application" above. These are the components = of the >> overall service that are doing the work, i.e., the DB, the application s= erver, > etc. >> They are *NOT* service functions, in my mind.] >>=20 >> Service functions aren't going to be addressed by the traffic - traffic = is > between >> the "applications", i.e., the end points of a service chain. >>=20 >> Today, service functions are deployed along the path between application= s -- >> because that is how we know how to do it. Going forward, we don't want t= o >> *require* that anymore. >>=20 >> So back to your example of an appliance, I would call such appliances >> "transparent" because they are not explicitely addressed by the traffic = flows > and >> are in fact transparent to the applications. >>=20 >> Thomas >>=20 >>=20 >>=20 >>> Anoop >>=20 >>> On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel wr= ote: >>=20 >>>> Hi Anoop, >>>>=20 >>>>> My interpretation of the following line: >>>>>>>=20 >>>>> A document will describe the single service-level encapsulation >>>>> protocol >>>> for >>>>> conveying the service function chain and the service function path >>>>>>>=20 >>>>>=20 >>>>> is that there will be a single encapsulation protocol at the >>>>> "service >>>> layer". >>>> Are >>>>> we saying that there could be more than one way of carrying this >>>>> header >>>> but >>>>> that the contents would be the same? >>>>=20 >>>> That is my interpretation. >>>>=20 >>>> I.e., this is an encapsulation that can be placed between the "transpo= rt" >>>> (e.g., >>>> IP, MPLS, TCP, HTTP....) and the payload. >>>>=20 >>>>> Would the output of this WG would allow the creation of a service >>>>> chain >>>> even >>>>> when overlays are not in use? (This is not clear from reading the >>>> charter.) >>>>=20 >>>> Well, erm, what is an "overlay"? >>>> Isn't an overlay just a network that happens to be running over >>>> another network? >>>> Why would that need to be mentioned explicitly? >>>> Why would you assume it is ruled out if it is not mentioned? >>>>=20 >>>>> Finally, is the work intended to support chains of both >>>>> transparent and >>>> non- >>>>> transparent appliances, or is the focus mainly on transparent >>>> appliances? I >>>>> ask because there may be interesting layering issues with respect >>>>> to the placement of this header, especially if we have a >>>>> combination of >>>> transparent >>>>> and non-transparent appliances. >>>>=20 >>>> That is probably a good question. >>>> Personally, I would like to put it "for investigation." I.e., I >>>> don't think we know enough about the use cases and requirements to >>>> answer your question at this stage. >>>>=20 >>>> But if enough people show up on the list saying that they only want >>>> to handle one categorisation, then perhaps we can limit from day >>>> one. >>>>=20 >>>> Cheers, >>>> Adrian >>>>=20 >>>>=20 >>=20 >>> --001a11c227eea3624604e6fb76cb >>> Content-Type: text/html; charset=3DISO-8859-1 >>> Content-Transfer-Encoding: quoted-printable >>=20 >>>
Hi >>> Adrian,

>>>
That =3D is my >>> interpretation.

I.e., this is an encapsulation that can be pla= =3D >>> ced between the "transport" (e.g.,
IP, MPLS, TCP, >>> HTTP....) an=3D d the payload.
>>>
>>>

OK, I think that's a >>> bit dif=3D ferent from what Uri was arguing >>> for.

>>>=3D >>>
Well, erm, what is an "overlay"?
Isn't an >>> overl=3D ay just a network that happens to be running over another >>> network?
Why would that need to be mentioned explicitly?
Why >>> would you assume it =3D is ruled out if it is not >>> mentioned?
>>>
<=3D >>> br>
I tend to think of an overlay as one where there are >>> br>multiple=3D >>> occurrences of the same layer of =3DA0header in the packet., but maybe >>> I hav=3D e it wrong. =3DA0Does the IETF have a formal definition for >>> this?

>>>
That is >>> probably a good question=3D .
Personally, I would like to put it >>> "for investigation." I.e.=3D , I don't think we
know >>> enough about the use cases and requirements =3D to answer your question >>> at this
stage.

But if enough people show up on the list >>> saying that they onl=3D y want to handle
one categorisation, then >>> perhaps we can limit from day =3D one.
>> class=3D3D"gmail_extra">>>>
>>>
I think it would make sense to >>> add som=3D ething explicit to the charter about this.
>> class=3D3D"gmail_extra">=3D
Sinc= e I >>> have been asked the question o=3D ffline, I will go ahead and explain >>> what I mean by transparent vs non-trans=3D parent appliances. =3DA0With= a >>> non-transparent appliance, the appliance appea=3D rs as a >>> "router" in the path of the data. =3DA0As far as I'm aw= =3D >>> are this is how load balancers are deployed and this is how firewalls >>> are c=3D ommonly deployed. =3DA0In the non-transparent case, the addres= s >>> of the applia=3D nce does not appear in the packet; instead packets are >>> diverted to the appl=3D iance using PBR. =3DA0This used sometimes for >>> IDS/IPS type appliances.
>> class=3D3D"gmail_extra">
>> class=3D3D"gmail_extra">Anoop
>> r>
On Sun, Sep 22, 2013 at 6:11 AM, Adrian >>> r>Farrel=3D >>> <>> target=3D3D"_bl=3D ank">adrian@olddog.co.uk> wrote:
>>>
>> 0.8ex;border-=3D >>> left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so >>> lid;p=3D >>> adding-left:1ex">Hi Anoop,
>>>

>>> > My interpretation of the following line:
>>>
>>> > A document will describe the single service-level encapsulation >>> protoc=3D ol for
> conveying the service function chain and the >>> service function path
>>>
>
> is that there >>> will be a single encapsulation protocol at the "ser=3D vice >>> layer".
Are
> we saying that there could be more than >>> one way of carrying this heade=3D r but
> that the contents woul= d >>> be the same?

That is my interpretation.

I.e., >>> this is an encapsulation that can be placed between the "transpo= =3D >>> rt" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.
>> class=3D3D"im">
> Would the output of this WG would allow the >>> creation of a service chai=3D n even
> when overlays are not in >>> use? =3DA0(This is not clear from reading the c=3D harter.)

>>>
Well, erm, what is an "overlay"?
Isn't an >>> overlay just a network that happens to be running over another=3D >>> network?
Why would that need to be mentioned explicitly?
Why >>> would you assume it is ruled out if it is not mentioned?
>> class=3D3D"im">
> Finally, is the work intended to support chain= s >>> of both transparent an=3D d non-
> transparent appliances, or is >>> the focus mainly on transparent applianc=3D es? =3DA0I
> ask >>> because there may be interesting layering issues with respect to t=3D >>> he
> placement of this header, especially if we have a >>> combination of trans=3D parent
> and non-transparent >>> appliances.

That is probably a good question.
>>> Personally, I would like to put it "for investigation." >>> I.e., I d=3D on't think we
know enough about the use cases and >>> requirements to answer your question at=3D this
stage.

Bu= t >>> if enough people show up on the list saying that they only want to >>> hand=3D le
one categorisation, then perhaps we can limit from day >>> one.

Cheers,
Adrian

>>>

>>=20 >>> --001a11c227eea3624604e6fb76cb-- >>=20 >>> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0224793606959901704=3D= =3D >>> Content-Type: text/plain; charset=3D"us-ascii" >>> MIME-Version: 1.0 >>> Content-Transfer-Encoding: 7bit >>> Content-Disposition: inline >>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >>> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0224793606959901704=3D= =3D-- >>=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 Ron_Parker@affirmednetworks.com Wed Sep 25 10:18: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 6FC3611E80F3 for ; Wed, 25 Sep 2013 10:18:57 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4ghMLD0zYmg for ; Wed, 25 Sep 2013 10:18:52 -0700 (PDT) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7D93C11E8117 for ; Wed, 25 Sep 2013 10:18:52 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0123.003; Wed, 25 Sep 2013 10:18:50 -0700 From: Ron Parker To: "Paul Quinn (paulq)" , "" Thread-Topic: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3] Thread-Index: AQHOuhGhYF4LW1j8k0SVS9i6HT3XqJnWselw Date: Wed, 25 Sep 2013 17:18:50 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> <064001ceba06$27012680$75037380$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "" , Anoop Ghanwani Subject: Re: [nsc] transparent vs. non-transparent services [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: Wed, 25 Sep 2013 17:18:57 -0000 So is the definition of transparent -- packets are unchanged (headers, cont= ent, etc.) and routing/switching path is unaltered? Or is it just the for= mer? The mere diversion to a service node would seem to constitute "routi= ng/switching is altered".=20 Ron -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Wednesday, September 25, 2013 1:07 PM To: Cc: Ron Parker; Thomas Narten; Anoop Ghanwani; Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3] Hi, I think there's a further nuance, at least in the service world that is dif= ferent separate from native path vs. diversion/steering discussion. A tran= sparent service acts a "bump in the wire", the most common example. A non-= transparent service terminates the traffic (e.g. the original TCP session),= performs some action, then forwards the traffic via a new connection or mi= micking the original one. Thanks Paul On Sep 25, 2013, at 8:44 AM, Adrian Farrel wrote: > I *think* the distinction being made is... >=20 > Does the packet follow the path it would have followed absent the=20 > imposition of a service function? If so, the service function is=20 > applied transparently. If not, the packet is somehow diverted (e.g.=20 > down a tunnel, by stealing the destination address field, etc.) and=20 > the service function is applied non-transparently. >=20 > If I am right in this, then I think it is not helpful to talk about=20 > transparent or non-transparent services (or service functions), but=20 > how they are applied or realised for a particular flow. >=20 > Adrian >=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: 25 September 2013 15:53 >> To: Thomas Narten; Anoop Ghanwani >> Cc: nsc@ietf.org; Adrian Farrel >> Subject: RE: [nsc] transparent vs. non-transparent services [was Re:=20 >> New NSC WG Charter - charter bullet #3] >>=20 >> Thomas, Anoop, >>=20 >> It strikes me that this transparency is not wrt to the originator or=20 >> addressee > of the >> traffic, but rather between the SFC classifier and the SFC service=20 >> nodes > (SNs). In >> particular, whether an encapsulating "transport" header (e.g.,=20 >> IPv4/UDP) is applied in front of the NSC/SFC "service header" (which=20 >> is in front of the > original >> packet), or not. >>=20 >> If an IP-layer encapsulation is applied, for example, the packets are=20 >> routed/switched normally amongst the SFC classifier and SN's because=20 >> the packets are explicitly IP addressed at each hop (given that the=20 >> SN's would > need to >> change the destination IP in the encapsulating header to select the "nex= t" > SN). >> However, if a "transport" header is not applied, policy-based > routing/switching >> would need to be used to steer the traffic in such a way that did not > necessarily >> conform to traditional routing/switching decisions. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >> Thomas Narten >> Sent: Wednesday, September 25, 2013 10:35 AM >> To: Anoop Ghanwani >> Cc: nsc@ietf.org; Adrian Farrel >> Subject: [nsc] transparent vs. non-transparent services [was Re: New=20 >> NSC WG Charter - charter bullet #3] >>=20 >> Hi Anoop. >>=20 >> Anoop Ghanwani writes: >>=20 >>> Since I have been asked the question offline, I will go ahead and=20 >>> explain what I mean by transparent vs non-transparent appliances. >>> With a non-transparent appliance, the appliance appears as a "router" >>> in the path of the data. As far as I'm aware this is how load=20 >>> balancers are deployed and this is how firewalls are commonly=20 >>> deployed. In the non-transparent case, the address of the appliance=20 >>> does not appear in the packet; instead packets are diverted to the=20 >>> appliance using PBR. This used sometimes for IDS/IPS type appliances. >>=20 >> I don't quite get this. To me, SFC is all about applying service=20 >> functions to > traffic >> flows -- but in a way that is transparent to those traffic flows and=20 >> the end > points >> originating them. That is, "applications" generating traffic aren't=20 >> generally > aware >> of these service functions and they aren't really asking for them.=20 >> They are > applied >> as the result of network policy/operations, not because the=20 >> applications need them (for correctness). E.g., load balancing and=20 >> firewalls. Those sorts of > things >> are applied by network operators whether the applications want them=20 >> or not. So the kinds of service functions this group is interested in=20 >> are in some sense > by >> definition "transparent" to applications. >>=20 >> [BTW, it would be useful to have a term for the endpoints of a chain >> -- that is what I mean by "application" above. These are the=20 >> components of the overall service that are doing the work, i.e., the=20 >> DB, the application server, > etc. >> They are *NOT* service functions, in my mind.] >>=20 >> Service functions aren't going to be addressed by the traffic -=20 >> traffic is > between >> the "applications", i.e., the end points of a service chain. >>=20 >> Today, service functions are deployed along the path between=20 >> applications -- because that is how we know how to do it. Going=20 >> forward, we don't want to >> *require* that anymore. >>=20 >> So back to your example of an appliance, I would call such appliances=20 >> "transparent" because they are not explicitely addressed by the=20 >> traffic flows > and >> are in fact transparent to the applications. >>=20 >> Thomas >>=20 >>=20 >>=20 >>> Anoop >>=20 >>> On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel wr= ote: >>=20 >>>> Hi Anoop, >>>>=20 >>>>> My interpretation of the following line: >>>>>>>=20 >>>>> A document will describe the single service-level encapsulation=20 >>>>> protocol >>>> for >>>>> conveying the service function chain and the service function path >>>>>>>=20 >>>>>=20 >>>>> is that there will be a single encapsulation protocol at the=20 >>>>> "service >>>> layer". >>>> Are >>>>> we saying that there could be more than one way of carrying this=20 >>>>> header >>>> but >>>>> that the contents would be the same? >>>>=20 >>>> That is my interpretation. >>>>=20 >>>> I.e., this is an encapsulation that can be placed between the "transpo= rt" >>>> (e.g., >>>> IP, MPLS, TCP, HTTP....) and the payload. >>>>=20 >>>>> Would the output of this WG would allow the creation of a service=20 >>>>> chain >>>> even >>>>> when overlays are not in use? (This is not clear from reading the >>>> charter.) >>>>=20 >>>> Well, erm, what is an "overlay"? >>>> Isn't an overlay just a network that happens to be running over=20 >>>> another network? >>>> Why would that need to be mentioned explicitly? >>>> Why would you assume it is ruled out if it is not mentioned? >>>>=20 >>>>> Finally, is the work intended to support chains of both=20 >>>>> transparent and >>>> non- >>>>> transparent appliances, or is the focus mainly on transparent >>>> appliances? I >>>>> ask because there may be interesting layering issues with respect=20 >>>>> to the placement of this header, especially if we have a=20 >>>>> combination of >>>> transparent >>>>> and non-transparent appliances. >>>>=20 >>>> That is probably a good question. >>>> Personally, I would like to put it "for investigation." I.e., I=20 >>>> don't think we know enough about the use cases and requirements to=20 >>>> answer your question at this stage. >>>>=20 >>>> But if enough people show up on the list saying that they only want=20 >>>> to handle one categorisation, then perhaps we can limit from day=20 >>>> one. >>>>=20 >>>> Cheers, >>>> Adrian >>>>=20 >>>>=20 >>=20 >>> --001a11c227eea3624604e6fb76cb >>> Content-Type: text/html; charset=3DISO-8859-1 >>> Content-Transfer-Encoding: quoted-printable >>=20 >>>
Hi >>> Adrian,

>>>
That =3D is my=20 >>> interpretation.

I.e., this is an encapsulation that can be=20 >>> pla=3D ced between the "transport" (e.g.,
IP, MPLS, TCP, >>> HTTP....) an=3D d the payload.
>>>
>>>

OK, I think that's a=20 >>> bit dif=3D ferent from what Uri was arguing=20 >>> for.

>>>=3D >>>
Well, erm, what is an "overlay"?
Isn't=20 >>> an overl=3D ay just a network that happens to be running over another=20 >>> network?
Why would that need to be mentioned explicitly?
Why=20 >>> would you assume it =3D is ruled out if it is not=20 >>> mentioned?
>>>
<=3D >>> br>
I tend to think of an overlay as one where there are=20 >>> br>multiple=3D >>> occurrences of the same layer of =3DA0header in the packet., but maybe= =20 >>> I hav=3D e it wrong. =3DA0Does the IETF have a formal definition for=20 >>> this?

>>>
That is=20 >>> probably a good question=3D .
Personally, I would like to put it=20 >>> "for investigation." I.e.=3D , I don't think we
know=20 >>> enough about the use cases and requirements =3D to answer your=20 >>> question at this
stage.

But if enough people show up on=20 >>> the list saying that they onl=3D y want to handle
one=20 >>> categorisation, then perhaps we can limit from day =3D one.
>> class=3D3D"gmail_extra">>>>
>> tra">
I think it would make=20 >>> sense to add som=3D ething explicit to the charter about=20 >>> this.
=3D
>> class=3D3D"gmail_extra">Since I have been asked the question o=3D=20 >>> ffline, I will go ahead and explain what I mean by transparent vs=20 >>> non-trans=3D parent appliances. =3DA0With a non-transparent appliance,= =20 >>> the appliance appea=3D rs as a "router" in the path of the=20 >>> data. =3DA0As far as I'm aw=3D are this is how load balancers are=20 >>> deployed and this is how firewalls are c=3D ommonly deployed. =3DA0In=20 >>> the non-transparent case, the address of the applia=3D nce does not=20 >>> appear in the packet; instead packets are diverted to the appl=3D=20 >>> iance using PBR. =3DA0This used sometimes for IDS/IPS type=20 >>> appliances.

>> class=3D3D"gmail_extra">Anoop
>> r>
On Sun, Sep 22, 2013 at 6:11 AM, Adrian= =20 >>> r>Farrel=3D >>> <>> target=3D3D"_bl=3D ank">adrian@olddog.co.uk> wrote:
=20 >>>
>> 0.8ex;border-=3D=20 >>> left-width:1px;border-left-color:rgb(204,204,204);border-left-style: >>> so >>> lid;p=3D >>> adding-left:1ex">Hi Anoop,
>>>

>>> > My interpretation of the following line:
>>>
=20 >>> > A document will describe the single service-level encapsulation=20 >>> protoc=3D ol for
> conveying the service function chain and the= =20 >>> service function path
>>>
>
> is that=20 >>> there will be a single encapsulation protocol at the "ser=3D vice= =20 >>> layer".
Are
> we saying that there could be more=20 >>> than one way of carrying this heade=3D r but
> that the=20 >>> contents would be the same?

That is my=20 >>> interpretation.

I.e., this is an encapsulation that can be=20 >>> placed between the "transpo=3D rt" (e.g.,
IP, MPLS, TCP,= =20 >>> HTTP....) and the payload.

> Would the= =20 >>> output of this WG would allow the creation of a service chai=3D n=20 >>> even
> when overlays are not in use? =3DA0(This is not clear=20 >>> from reading the c=3D harter.)

Well, erm, what is an=20 >>> "overlay"?
Isn't an overlay just a network that=20 >>> happens to be running over another=3D network?
Why would that need= =20 >>> to be mentioned explicitly?
Why would you assume it is ruled out=20 >>> if it is not mentioned?

> Finally, is=20 >>> the work intended to support chains of both transparent an=3D d=20 >>> non-
> transparent appliances, or is the focus mainly on=20 >>> transparent applianc=3D es? =3DA0I
> ask because there may be=20 >>> interesting layering issues with respect to t=3D he
> placement= =20 >>> of this header, especially if we have a combination of trans=3D=20 >>> parent
> and non-transparent appliances.

That=20 >>> is probably a good question.
Personally, I would like to put it=20 >>> "for investigation." I.e., I d=3D on't think we
know= =20 >>> enough about the use cases and requirements to answer your question=20 >>> at=3D this
stage.

But if enough people show up on the=20 >>> list saying that they only want to hand=3D le
one categorisation,=20 >>> then perhaps we can limit from day one.

Cheers,
=20 >>> Adrian


>>=20 >>> --001a11c227eea3624604e6fb76cb-- >>=20 >>> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0224793606959901704=3D= =3D >>> Content-Type: text/plain; charset=3D"us-ascii" >>> MIME-Version: 1.0 >>> Content-Transfer-Encoding: 7bit >>> Content-Disposition: inline >>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >>> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0224793606959901704=3D= =3D-- >>=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 narten@us.ibm.com Wed Sep 25 10:24: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 3649A21F9EC8 for ; Wed, 25 Sep 2013 10:24:24 -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 gR0oeR7iottA for ; Wed, 25 Sep 2013 10:24:17 -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 765BE21F94FA for ; Wed, 25 Sep 2013 10:24:17 -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 ; Wed, 25 Sep 2013 11:24:16 -0600 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 25 Sep 2013 11:24:14 -0600 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 2066EC90042 for ; Wed, 25 Sep 2013 13:24:13 -0400 (EDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by b01cxnp23034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8PHODc961866092 for ; Wed, 25 Sep 2013 17:24:13 GMT Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r8PHOCf4014131 for ; Wed, 25 Sep 2013 11:24:12 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-228-93.mts.ibm.com [9.65.228.93]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r8PHOARM013924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 11:24:11 -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 r8PHO9hk031606; Wed, 25 Sep 2013 13:24:09 -0400 Message-Id: <201309251724.r8PHO9hk031606@cichlid.raleigh.ibm.com> To: Ron Parker In-reply-to: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> <064001ceba06$27012680$75037380$@olddog.co.uk> Comments: In-reply-to Ron Parker message dated "Wed, 25 Sep 2013 17:18:50 -0000." Date: Wed, 25 Sep 2013 13:24:09 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13092517-9332-0000-0000-0000018A7E10 Cc: "" , "" , Anoop Ghanwani , "Paul Quinn \(paulq\)" Subject: Re: [nsc] transparent vs. non-transparent services [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: Wed, 25 Sep 2013 17:24:24 -0000 Ron, > So is the definition of transparent -- packets are unchanged > (headers, content, etc.) and routing/switching path is unaltered? > Or is it just the former? The mere diversion to a service node > would seem to constitute "routing/switching is altered". I think the point is we don't exactly have an agreed to defintion of "transparent" in the NSC context, so it's not particularly helpful to use it in describing NSC behavior without being clear about what is meant. For services in NSC, packets clearly will get modified in some cases (e.g. NAT or proxies) but won't in others. So distinguishing types of services by how much they change the packets they inspect is probably not helpful for NSC. NSC doesn't really care *what* the services does, just that the service exists and packets need to be steered to travel through the service. Thomas From I.Smith@F5.com Wed Sep 25 10:26: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 0F7F721F9633 for ; Wed, 25 Sep 2013 10:26:56 -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 3iBpbTvO8jRk for ; Wed, 25 Sep 2013 10:26:51 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 07B9A21F99DE for ; Wed, 25 Sep 2013 10:26:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,979,1371081600"; d="scan'208";a="82720033" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 25 Sep 2013 17:26:48 +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; Wed, 25 Sep 2013 10:26:47 -0700 From: Ian Smith To: Ron Parker , "Paul Quinn (paulq)" , "" Thread-Topic: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3] Thread-Index: AQHOuhGtUgqpvnwF9UW0nE6Wx0sWdZnXJ88A//+K5Gc= Date: Wed, 25 Sep 2013 17:26:46 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A6EF5E1@SEAEMBX02.olympus.F5Net.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> <064001ceba06$27012680$75037380$@olddog.co.uk> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "" , Anoop Ghanwani Subject: Re: [nsc] transparent vs. non-transparent services [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: Wed, 25 Sep 2013 17:26:56 -0000 In practice it is the latter, since those are the detectable alterations. = =0A= =0A= While the state of the forwarding table is dynamic and subject to change in= packet switched networks, the state of the headers of the packets on those= networks are typically static unless they are specifically altered per-hop= , so in the context of traffic steering, and by extension, steering that tr= affic into a service chain, if the headers aren't modified in an unusual ma= nner for a particular OSI layer, that steering is deemed "transparent" beca= use the traffic steering isn't detectable by peers/endpoints at that layer = of the OSI.=0A= =0A= =0A= ________________________________________=0A= From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Ron Parker [= Ron_Parker@affirmednetworks.com]=0A= Sent: Wednesday, September 25, 2013 1:18 PM=0A= To: Paul Quinn (paulq); =0A= Cc: Thomas Narten; ; Anoop Ghanwani=0A= Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New = NSC WG Charter - charter bullet #3]=0A= =0A= So is the definition of transparent -- packets are unchanged (headers, cont= ent, etc.) and routing/switching path is unaltered? Or is it just the for= mer? The mere diversion to a service node would seem to constitute "routi= ng/switching is altered".=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=0A= Sent: Wednesday, September 25, 2013 1:07 PM=0A= To: =0A= Cc: Ron Parker; Thomas Narten; Anoop Ghanwani; =0A= Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3]=0A= =0A= Hi,=0A= =0A= I think there's a further nuance, at least in the service world that is dif= ferent separate from native path vs. diversion/steering discussion. A tran= sparent service acts a "bump in the wire", the most common example. A non-= transparent service terminates the traffic (e.g. the original TCP session),= performs some action, then forwards the traffic via a new connection or mi= micking the original one.=0A= =0A= Thanks=0A= Paul=0A= =0A= On Sep 25, 2013, at 8:44 AM, Adrian Farrel wrote:=0A= =0A= > I *think* the distinction being made is...=0A= >=0A= > Does the packet follow the path it would have followed absent the=0A= > imposition of a service function? If so, the service function is=0A= > applied transparently. If not, the packet is somehow diverted (e.g.=0A= > down a tunnel, by stealing the destination address field, etc.) and=0A= > the service function is applied non-transparently.=0A= >=0A= > If I am right in this, then I think it is not helpful to talk about=0A= > transparent or non-transparent services (or service functions), but=0A= > how they are applied or realised for a particular flow.=0A= >=0A= > Adrian=0A= >=0A= >> -----Original Message-----=0A= >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= >> Sent: 25 September 2013 15:53=0A= >> To: Thomas Narten; Anoop Ghanwani=0A= >> Cc: nsc@ietf.org; Adrian Farrel=0A= >> Subject: RE: [nsc] transparent vs. non-transparent services [was Re:=0A= >> New NSC WG Charter - charter bullet #3]=0A= >>=0A= >> Thomas, Anoop,=0A= >>=0A= >> It strikes me that this transparency is not wrt to the originator or=0A= >> addressee=0A= > of the=0A= >> traffic, but rather between the SFC classifier and the SFC service=0A= >> nodes=0A= > (SNs). In=0A= >> particular, whether an encapsulating "transport" header (e.g.,=0A= >> IPv4/UDP) is applied in front of the NSC/SFC "service header" (which=0A= >> is in front of the=0A= > original=0A= >> packet), or not.=0A= >>=0A= >> If an IP-layer encapsulation is applied, for example, the packets are=0A= >> routed/switched normally amongst the SFC classifier and SN's because=0A= >> the packets are explicitly IP addressed at each hop (given that the=0A= >> SN's would=0A= > need to=0A= >> change the destination IP in the encapsulating header to select the "nex= t"=0A= > SN).=0A= >> However, if a "transport" header is not applied, policy-based=0A= > routing/switching=0A= >> would need to be used to steer the traffic in such a way that did not=0A= > necessarily=0A= >> conform to traditional routing/switching decisions.=0A= >>=0A= >> Ron=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=0A= >> Thomas Narten=0A= >> Sent: Wednesday, September 25, 2013 10:35 AM=0A= >> To: Anoop Ghanwani=0A= >> Cc: nsc@ietf.org; Adrian Farrel=0A= >> Subject: [nsc] transparent vs. non-transparent services [was Re: New=0A= >> NSC WG Charter - charter bullet #3]=0A= >>=0A= >> Hi Anoop.=0A= >>=0A= >> Anoop Ghanwani writes:=0A= >>=0A= >>> Since I have been asked the question offline, I will go ahead and=0A= >>> explain what I mean by transparent vs non-transparent appliances.=0A= >>> With a non-transparent appliance, the appliance appears as a "router"= =0A= >>> in the path of the data. As far as I'm aware this is how load=0A= >>> balancers are deployed and this is how firewalls are commonly=0A= >>> deployed. In the non-transparent case, the address of the appliance=0A= >>> does not appear in the packet; instead packets are diverted to the=0A= >>> appliance using PBR. This used sometimes for IDS/IPS type appliances.= =0A= >>=0A= >> I don't quite get this. To me, SFC is all about applying service=0A= >> functions to=0A= > traffic=0A= >> flows -- but in a way that is transparent to those traffic flows and=0A= >> the end=0A= > points=0A= >> originating them. That is, "applications" generating traffic aren't=0A= >> generally=0A= > aware=0A= >> of these service functions and they aren't really asking for them.=0A= >> They are=0A= > applied=0A= >> as the result of network policy/operations, not because the=0A= >> applications need them (for correctness). E.g., load balancing and=0A= >> firewalls. Those sorts of=0A= > things=0A= >> are applied by network operators whether the applications want them=0A= >> or not. So the kinds of service functions this group is interested in=0A= >> are in some sense=0A= > by=0A= >> definition "transparent" to applications.=0A= >>=0A= >> [BTW, it would be useful to have a term for the endpoints of a chain=0A= >> -- that is what I mean by "application" above. These are the=0A= >> components of the overall service that are doing the work, i.e., the=0A= >> DB, the application server,=0A= > etc.=0A= >> They are *NOT* service functions, in my mind.]=0A= >>=0A= >> Service functions aren't going to be addressed by the traffic -=0A= >> traffic is=0A= > between=0A= >> the "applications", i.e., the end points of a service chain.=0A= >>=0A= >> Today, service functions are deployed along the path between=0A= >> applications -- because that is how we know how to do it. Going=0A= >> forward, we don't want to=0A= >> *require* that anymore.=0A= >>=0A= >> So back to your example of an appliance, I would call such appliances=0A= >> "transparent" because they are not explicitely addressed by the=0A= >> traffic flows=0A= > and=0A= >> are in fact transparent to the applications.=0A= >>=0A= >> Thomas=0A= >>=0A= >>=0A= >>=0A= >>> Anoop=0A= >>=0A= >>> On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel wr= ote:=0A= >>=0A= >>>> Hi Anoop,=0A= >>>>=0A= >>>>> My interpretation of the following line:=0A= >>>>>>>=0A= >>>>> A document will describe the single service-level encapsulation=0A= >>>>> protocol=0A= >>>> for=0A= >>>>> conveying the service function chain and the service function path=0A= >>>>>>>=0A= >>>>>=0A= >>>>> is that there will be a single encapsulation protocol at the=0A= >>>>> "service=0A= >>>> layer".=0A= >>>> Are=0A= >>>>> we saying that there could be more than one way of carrying this=0A= >>>>> header=0A= >>>> but=0A= >>>>> that the contents would be the same?=0A= >>>>=0A= >>>> That is my interpretation.=0A= >>>>=0A= >>>> I.e., this is an encapsulation that can be placed between the "transpo= rt"=0A= >>>> (e.g.,=0A= >>>> IP, MPLS, TCP, HTTP....) and the payload.=0A= >>>>=0A= >>>>> Would the output of this WG would allow the creation of a service=0A= >>>>> chain=0A= >>>> even=0A= >>>>> when overlays are not in use? (This is not clear from reading the=0A= >>>> charter.)=0A= >>>>=0A= >>>> Well, erm, what is an "overlay"?=0A= >>>> Isn't an overlay just a network that happens to be running over=0A= >>>> another network?=0A= >>>> Why would that need to be mentioned explicitly?=0A= >>>> Why would you assume it is ruled out if it is not mentioned?=0A= >>>>=0A= >>>>> Finally, is the work intended to support chains of both=0A= >>>>> transparent and=0A= >>>> non-=0A= >>>>> transparent appliances, or is the focus mainly on transparent=0A= >>>> appliances? I=0A= >>>>> ask because there may be interesting layering issues with respect=0A= >>>>> to the placement of this header, especially if we have a=0A= >>>>> combination of=0A= >>>> transparent=0A= >>>>> and non-transparent appliances.=0A= >>>>=0A= >>>> That is probably a good question.=0A= >>>> Personally, I would like to put it "for investigation." I.e., I=0A= >>>> don't think we know enough about the use cases and requirements to=0A= >>>> answer your question at this stage.=0A= >>>>=0A= >>>> But if enough people show up on the list saying that they only want=0A= >>>> to handle one categorisation, then perhaps we can limit from day=0A= >>>> one.=0A= >>>>=0A= >>>> Cheers,=0A= >>>> Adrian=0A= >>>>=0A= >>>>=0A= >>=0A= >>> --001a11c227eea3624604e6fb76cb=0A= >>> Content-Type: text/html; charset=3DISO-8859-1=0A= >>> Content-Transfer-Encoding: quoted-printable=0A= >>=0A= >>>
Hi=0A= >>> Adrian,

>>>
That =3D is my=0A= >>> interpretation.

I.e., this is an encapsulation that can be=0A= >>> pla=3D ced between the "transport" (e.g.,
IP, MPLS, TCP,= =0A= >>> HTTP....) an=3D d the payload.
=0A= >>>
>>>

OK, I think that's a=0A= >>> bit dif=3D ferent from what Uri was arguing=0A= >>> for.

>>>=3D=0A= >>>
Well, erm, what is an "overlay"?
Isn't=0A= >>> an overl=3D ay just a network that happens to be running over another= =0A= >>> network?
Why would that need to be mentioned explicitly?
Why=0A= >>> would you assume it =3D is ruled out if it is not=0A= >>> mentioned?
>>>
<=3D=0A= >>> br>
I tend to think of an overlay as one where there are=0A= >>> br>multiple=3D=0A= >>> occurrences of the same layer of =3DA0header in the packet., but maybe= =0A= >>> I hav=3D e it wrong. =3DA0Does the IETF have a formal definition for=0A= >>> this?

>>>
That is=0A= >>> probably a good question=3D .
Personally, I would like to put it=0A= >>> "for investigation." I.e.=3D , I don't think we
know= =0A= >>> enough about the use cases and requirements =3D to answer your=0A= >>> question at this
stage.

But if enough people show up on=0A= >>> the list saying that they onl=3D y want to handle
one=0A= >>> categorisation, then perhaps we can limit from day =3D one.
>> class=3D3D"gmail_extra">>>>
>> tra">
I think it would make=0A= >>> sense to add som=3D ething explicit to the charter about=0A= >>> this.
=3D
>> class=3D3D"gmail_extra">Since I have been asked the question o=3D=0A= >>> ffline, I will go ahead and explain what I mean by transparent vs=0A= >>> non-trans=3D parent appliances. =3DA0With a non-transparent appliance,= =0A= >>> the appliance appea=3D rs as a "router" in the path of the=0A= >>> data. =3DA0As far as I'm aw=3D are this is how load balancers are= =0A= >>> deployed and this is how firewalls are c=3D ommonly deployed. =3DA0In= =0A= >>> the non-transparent case, the address of the applia=3D nce does not=0A= >>> appear in the packet; instead packets are diverted to the appl=3D=0A= >>> iance using PBR. =3DA0This used sometimes for IDS/IPS type=0A= >>> appliances.

>> class=3D3D"gmail_extra">Anoop
>> r>
On Sun, Sep 22, 2013 at 6:11 AM, Adrian= =0A= >>> r>Farrel=3D=0A= >>> <>> target=3D3D"_bl=3D ank">adrian@olddog.co.uk> wrote:
= =0A= >>>
>> 0.8ex;border-=3D=0A= >>> left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=0A= >>> so=0A= >>> lid;p=3D=0A= >>> adding-left:1ex">Hi Anoop,
=0A= >>>

=0A= >>> > My interpretation of the following line:
>>>
=0A= >>> > A document will describe the single service-level encapsulation=0A= >>> protoc=3D ol for
> conveying the service function chain and the= =0A= >>> service function path
>>>
>
> is that=0A= >>> there will be a single encapsulation protocol at the "ser=3D vice= =0A= >>> layer".
Are
> we saying that there could be more=0A= >>> than one way of carrying this heade=3D r but
> that the=0A= >>> contents would be the same?

That is my=0A= >>> interpretation.

I.e., this is an encapsulation that can be=0A= >>> placed between the "transpo=3D rt" (e.g.,
IP, MPLS, TCP,= =0A= >>> HTTP....) and the payload.

> Would the= =0A= >>> output of this WG would allow the creation of a service chai=3D n=0A= >>> even
> when overlays are not in use? =3DA0(This is not clear=0A= >>> from reading the c=3D harter.)

Well, erm, what is an=0A= >>> "overlay"?
Isn't an overlay just a network that=0A= >>> happens to be running over another=3D network?
Why would that need= =0A= >>> to be mentioned explicitly?
Why would you assume it is ruled out=0A= >>> if it is not mentioned?

> Finally, is= =0A= >>> the work intended to support chains of both transparent an=3D d=0A= >>> non-
> transparent appliances, or is the focus mainly on=0A= >>> transparent applianc=3D es? =3DA0I
> ask because there may be=0A= >>> interesting layering issues with respect to t=3D he
> placement= =0A= >>> of this header, especially if we have a combination of trans=3D=0A= >>> parent
> and non-transparent appliances.

That=0A= >>> is probably a good question.
Personally, I would like to put it=0A= >>> "for investigation." I.e., I d=3D on't think we
know= =0A= >>> enough about the use cases and requirements to answer your question=0A= >>> at=3D this
stage.

But if enough people show up on the=0A= >>> list saying that they only want to hand=3D le
one categorisation,= =0A= >>> then perhaps we can limit from day one.

Cheers,
=0A= >>> Adrian


=0A= >>=0A= >>> --001a11c227eea3624604e6fb76cb--=0A= >>=0A= >>> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0224793606959901704=3D= =3D=0A= >>> Content-Type: text/plain; charset=3D"us-ascii"=0A= >>> MIME-Version: 1.0=0A= >>> Content-Transfer-Encoding: 7bit=0A= >>> Content-Disposition: inline=0A= >>=0A= >>> _______________________________________________=0A= >>> nsc mailing list=0A= >>> nsc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>=0A= >>> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0224793606959901704=3D= =3D--=0A= >>=0A= >> _______________________________________________=0A= >> nsc mailing list=0A= >> nsc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/nsc=0A= >=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= =0A= _______________________________________________=0A= nsc mailing list=0A= nsc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nsc=0A= From Ron_Parker@affirmednetworks.com Wed Sep 25 10:27: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 0809B21F9950 for ; Wed, 25 Sep 2013 10:27:10 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocUILGNEyjME for ; Wed, 25 Sep 2013 10:27:05 -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 2D8E721F9C13 for ; Wed, 25 Sep 2013 10:27:05 -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; Wed, 25 Sep 2013 10:27:05 -0700 From: Ron Parker To: David Allan I , Jerome Moisand , Thomas Nadeau , Linda Dunbar Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAFjGCAABXPIWAACmS74AARmqagAAGAzmgAAXXQIAAAzxbAAAeZMoAAAyXAYA= Date: Wed, 25 Sep 2013 17:27:04 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> <583789CD-C183-451C-B4DD-8944A1DC03B1@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] 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: Wed, 25 Sep 2013 17:27:10 -0000 I agree with Dave that subscriber ID and those fields necessary to complete= the chain forwarding (may or may not end up being a simple chain id) are t= he most important metadata. However, there may be other interesting field= s to consider such as location of the subscriber (e.g., cell id in a 3gpp = network). =20 But other less universally useful fields may prove too troublesome to incor= porate. Take DPI conclusions as a counter example. How are they describ= ed? Where is the central registry of known protocols/applications and the= strings and/or integers used to identify them? It would be an ongoing ba= ttle to try to communicate DPI conclusions between SF's in such a way that = all could agree on the interpretation. Thanks. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of David= Allan I Sent: Wednesday, September 25, 2013 12:21 PM To: Jerome Moisand; Thomas Nadeau; Linda Dunbar Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 I'm not a fan of encapsulating the frame in a database before forwarding...= . I understand Joel's use case of carrying the subscriber ID (assuming the en= tire frame presented to a BNG is not preserved), and the need for a chain I= D as a forwarding "helper". These two items strike me as both "necessary an= d sufficient". Cheers Dave=20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jerom= e Moisand Sent: Tuesday, September 24, 2013 6:51 PM To: Thomas Nadeau; Linda Dunbar Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 There are definitely quite a few additional candidates for metadata fields = of interest... But I believe we need much more work on the PROBLEM STATEMEN= T, and not jump to solution design.=20 We really need to work much more on use cases. Some use cases may imply mor= e 'metadata' than others. Simple problems may be solved by simple means. Mo= re complex problems may require more complex elements of solutions. Some ca= ses could be solved by signaling means instead of data plane means. Or the = reverse way around. Etc. Let me suggest we give more priority to refining the problem statement(s) f= irst... And not rush the design process. -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Nadeau Sent: Tuesday, September 24, 2013 8:18 PM To: Linda Dunbar Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 On Sep 24, 2013:7:02 PM, at 7:02 PM, Linda Dunbar = wrote: > Adrian, >=20 > Very good analysis. Thank you.=20 >=20 > "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 examp= les of the information required to be exchanged among those "Service Functi= ons" given by the draft-quinn-nsc-arch-00? Some examples might be OAM, other stats, service chain descriptions, etc..= . --Tom > 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. =09 >=20 >=20 > Thanks, Linda >=20 >> -----Original Message----- >>=20 >> I think "metadata" is a particularly poor term to use here because it=20 >> 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. >>=20 >> 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=20 >> service node (e.g. about how to perform given some state >> information) >>=20 >> We should also look at what you mean by out-of-band. I think here you=20 >> mean "using some information exchange protocol." >=20 > [Linda] Since each Service-Chain ID represents a list of service function= s, it is possible to use "out-of-band" control channel to pass the informat= ion on the sequence of Service Functions associated with the ID.=20 >=20 >=20 >>=20 >> The charter says: >>=20 >> | 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 protocols=20 >> | or protocol extensions to convey the service path and for=20 >> | communication between nodes that implement service functions >>=20 >> and: >>=20 >> | 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. >>=20 >> This feels like out-of-band exchange of information is expected. >>=20 >> Adrian >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Wed Sep 25 10:28: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 4A77F11E8126 for ; Wed, 25 Sep 2013 10:28:48 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nfcbXbXj4kl for ; Wed, 25 Sep 2013 10:28:42 -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 5948211E8124 for ; Wed, 25 Sep 2013 10:28:32 -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.0123.003; Wed, 25 Sep 2013 10:28:31 -0700 From: Ron Parker To: Thomas Narten Thread-Topic: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3] Thread-Index: AQHOuhQSfnCKKtB2XUGomy24ku5GVpnWtOdA Date: Wed, 25 Sep 2013 17:28:30 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> <064001ceba06$27012680$75037380$@olddog.co.uk> <201309251724.r8PHO9hk031606@cichlid.raleigh.ibm.com> In-Reply-To: <201309251724.r8PHO9hk031606@cichlid.raleigh.ibm.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: "" , "" , Anoop Ghanwani , "Paul Quinn \(paulq\)" Subject: Re: [nsc] transparent vs. non-transparent services [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: Wed, 25 Sep 2013 17:28:48 -0000 Thomas, I agree that the notion of transparent service is not necessary to incorpor= ate in our work. Ron -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com]=20 Sent: Wednesday, September 25, 2013 1:24 PM To: Ron Parker Cc: Paul Quinn (paulq); ; Anoop Ghanwani; Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3] Ron, > So is the definition of transparent -- packets are unchanged (headers,=20 > content, etc.) and routing/switching path is unaltered? > Or is it just the former? The mere diversion to a service node would=20 > seem to constitute "routing/switching is altered". I think the point is we don't exactly have an agreed to defintion of "trans= parent" in the NSC context, so it's not particularly helpful to use it in d= escribing NSC behavior without being clear about what is meant. For services in NSC, packets clearly will get modified in some cases (e.g. = NAT or proxies) but won't in others. So distinguishing types of services by= how much they change the packets they inspect is probably not helpful for = NSC. NSC doesn't really care *what* the services does, just that the servic= e exists and packets need to be steered to travel through the service. Thomas From I.Smith@F5.com Wed Sep 25 10:31: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 A92C711E8133 for ; Wed, 25 Sep 2013 10:31:24 -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 1wsvmnmrRl1y for ; Wed, 25 Sep 2013 10:31:20 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5614411E812C for ; Wed, 25 Sep 2013 10:31:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,979,1371081600"; d="scan'208";a="82720634" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 25 Sep 2013 17:31:20 +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; Wed, 25 Sep 2013 10:31:19 -0700 From: Ian Smith To: Ron Parker , David Allan I , Jerome Moisand , "Thomas Nadeau" , Linda Dunbar Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAFjGCAABXPIWAACmS74AARmqagAAGAzmgAAXXQIAAAzxbAAAeZMoAAAyXAYD//zjWNw== Date: Wed, 25 Sep 2013 17:31:18 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A6EF626@SEAEMBX02.olympus.F5Net.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> <583789CD-C183-451C-B4DD-8944A1DC03B1@lucidvision.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" , "adrian@olddog.co.uk" Subject: Re: [nsc] 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: Wed, 25 Sep 2013 17:31:24 -0000 This seems like an implementation detail. That said, this is also a proble= m that has been solved a number of times, so we probably don't need to re-i= nvent the when it does come time to address which meta data gets generated,= how it is formatted or encoded, and how to communicate it to the nodes tha= t need to know it.=0A= =0A= =0A= ________________________________________=0A= From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Ron Parker [= Ron_Parker@affirmednetworks.com]=0A= Sent: Wednesday, September 25, 2013 1:27 PM=0A= To: David Allan I; Jerome Moisand; Thomas Nadeau; Linda Dunbar=0A= Cc: nsc@ietf.org; adrian@olddog.co.uk=0A= Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=0A= =0A= I agree with Dave that subscriber ID and those fields necessary to complete= the chain forwarding (may or may not end up being a simple chain id) are t= he most important metadata. However, there may be other interesting field= s to consider such as location of the subscriber (e.g., cell id in a 3gpp = network).=0A= =0A= But other less universally useful fields may prove too troublesome to incor= porate. Take DPI conclusions as a counter example. How are they describ= ed? Where is the central registry of known protocols/applications and the= strings and/or integers used to identify them? It would be an ongoing ba= ttle to try to communicate DPI conclusions between SF's in such a way that = all could agree on the interpretation.=0A= =0A= Thanks.=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of David= Allan I=0A= Sent: Wednesday, September 25, 2013 12:21 PM=0A= To: Jerome Moisand; Thomas Nadeau; Linda Dunbar=0A= Cc: nsc@ietf.org; adrian@olddog.co.uk=0A= Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=0A= =0A= I'm not a fan of encapsulating the frame in a database before forwarding...= .=0A= =0A= I understand Joel's use case of carrying the subscriber ID (assuming the en= tire frame presented to a BNG is not preserved), and the need for a chain I= D as a forwarding "helper". These two items strike me as both "necessary an= d sufficient".=0A= =0A= Cheers=0A= Dave=0A= =0A= -----Original Message-----=0A= From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jerom= e Moisand=0A= Sent: Tuesday, September 24, 2013 6:51 PM=0A= To: Thomas Nadeau; Linda Dunbar=0A= Cc: nsc@ietf.org; adrian@olddog.co.uk=0A= Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=0A= =0A= There are definitely quite a few additional candidates for metadata fields = of interest... But I believe we need much more work on the PROBLEM STATEMEN= T, and not jump to solution design.=0A= =0A= We really need to work much more on use cases. Some use cases may imply mor= e 'metadata' than others. Simple problems may be solved by simple means. Mo= re complex problems may require more complex elements of solutions. Some ca= ses could be solved by signaling means instead of data plane means. Or the = reverse way around. Etc.=0A= =0A= Let me suggest we give more priority to refining the problem statement(s) f= irst... And not rush the design process.=0A= =0A= -----Original Message-----=0A= From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Nadeau=0A= Sent: Tuesday, September 24, 2013 8:18 PM=0A= To: Linda Dunbar=0A= Cc: nsc@ietf.org; adrian@olddog.co.uk=0A= Subject: Re: [nsc] New NSC WG Charter - charter bullet #3=0A= =0A= =0A= On Sep 24, 2013:7:02 PM, at 7:02 PM, Linda Dunbar = wrote:=0A= =0A= > Adrian,=0A= >=0A= > Very good analysis. Thank you.=0A= >=0A= > "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 examp= les of the information required to be exchanged among those "Service Functi= ons" given by the draft-quinn-nsc-arch-00?=0A= =0A= Some examples might be OAM, other stats, service chain descriptions= , etc...=0A= =0A= --Tom=0A= =0A= =0A= > A non-exhaustive list of Service Functions includes: firewalls, WAN=0A= > and application acceleration, Deep Packet Inspection (DPI), server=0A= > load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID injection,=0A= > HTTP Header Enrichment functions, TCP optimizer, etc.=0A= =0A= =0A= =0A= >=0A= >=0A= > Thanks, Linda=0A= >=0A= >> -----Original Message-----=0A= >>=0A= >> I think "metadata" is a particularly poor term to use here because it=0A= >> actually directly means "additional data attached to something=0A= >> specific". So, it is metadata when you put it in the encapsulation=0A= >> header on a packet, but if it is out of band, it is what it is.=0A= >>=0A= >> So, let's look at what you might be talking about for "metadata":=0A= >> - The details of the service chain itself (e.g. the service path)=0A= >> - Information that one service node wants to communicate with another=0A= >> service node (e.g. about how to perform given some state=0A= >> information)=0A= >>=0A= >> We should also look at what you mean by out-of-band. I think here you=0A= >> mean "using some information exchange protocol."=0A= >=0A= > [Linda] Since each Service-Chain ID represents a list of service function= s, it is possible to use "out-of-band" control channel to pass the informat= ion on the sequence of Service Functions associated with the ID.=0A= >=0A= >=0A= >>=0A= >> The charter says:=0A= >>=0A= >> | The Service Function Chaining (SFC) working group will develop new=0A= >> | approaches to service delivery and deployment, by providing a=0A= >> | framework for service function chaining and the necessary protocols=0A= >> | or protocol extensions to convey the service path and for=0A= >> | communication between nodes that implement service functions=0A= >>=0A= >> and:=0A= >>=0A= >> | 4) Control Plane Mechanisms: A set of documents will be developed=0A= >> | to describe requirements and protocols necessary to convey=0A= >> | information to service function implementation points. Where=0A= >> | possible, existing IETF protocols will be used and extended.=0A= >>=0A= >> This feels like out-of-band exchange of information is expected.=0A= >>=0A= >> Adrian=0A= >>=0A= >>=0A= >>=0A= >>=0A= >>=0A= >=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= >=0A= =0A= =0A= _______________________________________________=0A= nsc mailing list=0A= nsc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nsc=0A= _______________________________________________=0A= nsc mailing list=0A= nsc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nsc=0A= _______________________________________________=0A= nsc mailing list=0A= nsc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nsc=0A= From ghanwani@gmail.com Wed Sep 25 11:10: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 120D821F9D52 for ; Wed, 25 Sep 2013 11:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Mf6BSGL4vDKT for ; Wed, 25 Sep 2013 11:10:51 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1E30721F9D0C for ; Wed, 25 Sep 2013 11:10:49 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id x12so34935wgg.8 for ; Wed, 25 Sep 2013 11:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gjM9m6ZgX2w0kN77LjqzlWAHPMUi2T7EnCBMr+Kdwsw=; b=yS6FH8fGvi49jS3eowx5pw0gkzOBDIhjjbmoxsI0FzSPEea6XCwFMamRWJgkAm30sj QEgN65Pr2qPsksvZ/ohG6yyptO8Ad0eo3TMJFwjsDjKIDnTJ2eWSvqJGg+5zHISBmIJw dutll0ExSuotGlH3JoRXUmGF6IuOKDtkHhYylwCXGoqAJL+Czc9khorcBrHCLOuWWz5Y /ShixmKoNqTdtd68tOK/IT53blIbtEvaeVCDsylana8x6MEU1O80HZ4XbXWfwuv8GuN1 swy3s6mEnIN1gY8wcDf9k2Wo9HKqrE74RlSezaT1RIuOK7rRX9p1qm21d5QIPl5CT3mc Yreg== MIME-Version: 1.0 X-Received: by 10.194.134.97 with SMTP id pj1mr2638684wjb.58.1380132649172; Wed, 25 Sep 2013 11:10:49 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.217.54.6 with HTTP; Wed, 25 Sep 2013 11:10:49 -0700 (PDT) In-Reply-To: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> <064001ceba06$27012680$75037380$@olddog.co.uk> <201309251724.r8PHO9hk031606@cichlid.raleigh.ibm.com> Date: Wed, 25 Sep 2013 11:10:49 -0700 X-Google-Sender-Auth: VAh2IjC3_fd5vRheBjTWHJi_4rA Message-ID: From: Anoop Ghanwani To: Ron Parker Content-Type: multipart/alternative; boundary=089e012280584c099604e7392c6c Cc: Thomas Narten , "" , "Paul Quinn \(paulq\)" , "" Subject: Re: [nsc] transparent vs. non-transparent services [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: Wed, 25 Sep 2013 18:10:52 -0000 --089e012280584c099604e7392c6c Content-Type: text/plain; charset=ISO-8859-1 When I mentioned transparent/non-transparent, I meant that there was some change in the packet headers (whether at the IP, MAC, or TCP layers) for packets that were going to be subject to the service in question, in the non-transparent case. In other words, for the transparent case, I cannot tell by looking at the packet headers whether or not the packet would be subject to that service. Clearly, there are others who think transparent/non-transparent mean something else. And that's just simply because there is not standard terminology, which perhaps the WG can help define. I think this also plays into where in the packet the NSC header goes, and whether there can be multiple instances of the NSC header in the packet. If a certain layer's header is terminated at a service box, it would be a layering violation to carry the NSC header beyond that point. For instance, if the NSC header is located between the MAC and IP header, and the packet hits a load balancer that changes the IP & MAC headers, that device would need to create a new NSC header. It may be that as Thomas says, we are not going to worry about non-transparent appliances at all, but then I'm not sure how we even implement something like a load balancer. Finally, I do think the problem statement needs a lot of work before we get to solutions. I think it would be useful to state somewhere in the charter that solutions would only be considered after the problem statement is in a reasonable shape and the WG participants are in agreement about what needs to be solved. Anoop On Wed, Sep 25, 2013 at 10:28 AM, Ron Parker < Ron_Parker@affirmednetworks.com> wrote: > Thomas, > > I agree that the notion of transparent service is not necessary to > incorporate in our work. > > Ron > > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Wednesday, September 25, 2013 1:24 PM > To: Ron Parker > Cc: Paul Quinn (paulq); ; Anoop Ghanwani; < > nsc@ietf.org> > Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New > NSC WG Charter - charter bullet #3] > > Ron, > > > So is the definition of transparent -- packets are unchanged (headers, > > content, etc.) and routing/switching path is unaltered? > > Or is it just the former? The mere diversion to a service node would > > seem to constitute "routing/switching is altered". > > I think the point is we don't exactly have an agreed to defintion of > "transparent" in the NSC context, so it's not particularly helpful to use > it in describing NSC behavior without being clear about what is meant. > > For services in NSC, packets clearly will get modified in some cases (e.g. > NAT or proxies) but won't in others. So distinguishing types of services by > how much they change the packets they inspect is probably not helpful for > NSC. NSC doesn't really care *what* the services does, just that the > service exists and packets need to be steered to travel through the service. > > Thomas > > --089e012280584c099604e7392c6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
When I mentioned transparent/non-transparent, I meant= that there was some change in the packet headers (whether at the IP, MAC, = or TCP layers) for packets that were going to be subject to the service in = question, in the non-transparent case. =A0In other words, for the transpare= nt case, I cannot tell by looking at the packet headers whether or not the = packet would be subject to that service. =A0Clearly, there are others who t= hink transparent/non-transparent mean something else. =A0And that's jus= t simply because there is not standard terminology, which perhaps the WG ca= n help define.

I think this also plays into where in the packet the NSC hea= der goes, and whether there can be multiple instances of the NSC header in = the packet.

If a certain layer's header is terminate= d at a service box, it would be a layering violation to carry the NSC heade= r beyond that point.

For instance, if the NSC header is located between the = MAC and IP header, and the packet hits a load balancer that changes the IP = & MAC headers, that device would need to create a new NSC header.

It may be that as Thomas says, we are not going to worr= y about non-transparent appliances at all, but then I'm not sure how we= even implement something like a load balancer.

Finally, I do think the problem statement needs a lot of work before we get= to solutions. =A0I think it would be useful to state somewhere in the char= ter that solutions would only be considered after the problem statement is = in a reasonable shape and the WG participants are in agreement about what n= eeds to be solved.

Anoop


On Wed, Sep 25, 2013 at 10:28 AM, Ron Parker <Ron_Parker@affirmednetworks.com> wrote:
Thomas,

I agree that the notion of transparent service is not necessary to incorpor= ate in our work.

=A0 =A0Ron

-----Original Message-----
From: Thomas Narten [mailto:narten@us.= ibm.com]
Sent: Wednesday, September 25, 2013 1:24 PM
To: Ron Parker
Cc: Paul Quinn (paulq); <adrian@o= lddog.co.uk>; Anoop Ghanwani; <ns= c@ietf.org>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3]

Ron,

> So is the definition of transparent -- packets are unchanged (headers,=
> content, etc.) and routing/switching path is unaltered?
> Or is it just the former? =A0The mere diversion to a service node woul= d
> seem to constitute "routing/switching is altered".

I think the point is we don't exactly have an agreed to defintion of &q= uot;transparent" in the NSC context, so it's not particularly help= ful to use it in describing NSC behavior without being clear about what is = meant.

For services in NSC, packets clearly will get modified in some cases (e.g. = NAT or proxies) but won't in others. So distinguishing types of service= s by how much they change the packets they inspect is probably not helpful = for NSC. NSC doesn't really care *what* the services does, just that th= e service exists and packets need to be steered to travel through the servi= ce.

Thomas


--089e012280584c099604e7392c6c-- From narten@us.ibm.com Wed Sep 25 13:10:36 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06BA21E804D for ; Wed, 25 Sep 2013 13:10:36 -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 RplKYOCfw6r8 for ; Wed, 25 Sep 2013 13:10:30 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id F2EAB21F9FA3 for ; Wed, 25 Sep 2013 13:10:29 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Sep 2013 16:10:28 -0400 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 25 Sep 2013 16:10:27 -0400 Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 47F95C90045 for ; Wed, 25 Sep 2013 16:10:26 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by b01cxnp22036.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8PKAQXY4981174 for ; Wed, 25 Sep 2013 20:10:26 GMT Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r8PKAQ87029457 for ; Wed, 25 Sep 2013 16:10:26 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-228-93.mts.ibm.com [9.65.228.93]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r8PKAPFc029438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 16:10:26 -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 r8PKAOFW023454; Wed, 25 Sep 2013 16:10:24 -0400 Message-Id: <201309252010.r8PKAOFW023454@cichlid.raleigh.ibm.com> To: "Jim Guichard (jguichar)" In-reply-to: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> Comments: In-reply-to "Jim Guichard (jguichar)" message dated "Fri, 13 Sep 2013 14:08:03 -0000." Date: Wed, 25 Sep 2013 16:10:24 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13092520-7182-0000-0000-000008868F28 Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 20:10:37 -0000 Jim et al, Here are some specific suggestions on the charter (this is from the version posted Sept. 13). I think they are all editorial, crisping up the language used and consistent with the discussion on the list. > Proposed Service Function Chaining (SFC) WG Charter > Networks, servers, storage technologies, and applications, have all > undergone significant change in recent years with the introduction > of virtualization, network overlays, and orchestration. The process > of service delivery is changing from the physical insertion of > equipment on the path into a mechanism for causing the path or data > to transit specific physical or virtual nodes on which the service > functions are performed. Services are typically implemented by the > ordered combination of a number of service functions that may be > implemented at different points within the network. Service delivery > is currently both a technical and organisational challenge that > involves significant modification to the network configuration. Suggest changing the above as follows: 1) change sentence: The process of service delivery is changing from the physical insertion of equipment on the path into a mechanism for causing the path or data to transit specific physical or virtual nodes on which the service functions are performed. To: Today, a common deployment model has service functions physically inserted on the data forwarding path between communicating peers. Going forward, however, there is a desire to move to a different model, where service functions are not required to reside on the default data path and traffic is instead steered through services, wherever they are deployed. 2) Reorder the existing text in the pargraph so that teh revised text goes at end of first paragraph, i.e., resulting in: Networks, servers, storage technologies, and applications, have all undergone significant change in recent years with the introduction of virtualization, network overlays, and orchestration. Service delivery is currently both a technical and organisational challenge that involves significant modification to the network configuration. Services are typically implemented by the ordered chaining of a number of service functions (e.g., firewalls, load-balancers, etc.) that are implemented at different points within the network. Today, a common deployment model has service functions physically inserted on the data forwarding path between communicating peers. Going forward, however, there is a desire to move to a different model, where service functions are not required to reside on the default data path and traffic is instead steered through services, wherever they are deployed. > For a given service, the abstracted view of the required service > functions and the order in which they are to be invoked is called a s/invoked/applied/ ??? > Service Function Chain (SFC). Since a given service function may be > available on more than one node within a network, a ServiceFunction > Chain is instantiated via the selection of specific service function > instances and the network nodes on which they are provided, thereby > forming a servicetopology: this is called a Service Function Path. The > service functions may be applied at a specific layer within the > network protocol stack (network layer, application layer, etc.). I think talking about "layers" here is confusing and not really needed. SFC doesn't really care about what layer is used. It only cares about steering traffic to a service -- what that service does with that traffic is the service's own business. Suggest tweaking: Old: > The service functions may be applied at a specific layer within the > network protocol stack (network layer, application layer, etc.). better: Service functions are applied to the traffic flows that are directed through them. What the service function actually does to such traffic is service-specific and not of concern to SFC. > 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. 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. The above doesn't actually include the "steering" part. Suggest: Old: 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. New: 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 service path and service path information to nodes that implement service functions, as well as mechanisms for steering traffic through service functions. > Specifically, the SFC WG is chartered to deliver the following: > 1) Problem Statement: This document will provide a summary of the > problem space to be addressed by the WG including example high-level > use cases. Additionally, the WG will normalize nomenclature and > definitions for service function chaining. > 2) Architecture: This document will provide a description of the > architectural building blocks and their relationships including > interconnection, placement of capabilities, management, diagnostics, > and security models, as well as requirements on the protocol > mechanisms. > 3) Generic Service Function Chaining Encapsulation: A document will > describe the single service-level encapsulation protocol for conveying > communicating information between nodes that implement service > functions. Better: 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path associated with data packets, and for carrying context information between nodes that implement service functions. > It is intended that the encapsulation be agnostic to > the network layer at which it is applied and the service that is being > constructed. That is, the same encapsulation may be used on a service > function path realised at the network layer or at any other layer, and > the same encapsulation willapply for the construction of service > function paths regardless of the actual service. If I understand the list discussion, I think the above really just means: It is intended that the encapsulation be agnostic to the underlying network technology (i.e,. IP, MPLS, etc.) being used for transport as well to the specific services being supported. > 4) Control Plane Mechanisms: A set of documents will be developed to > describe requirements and protocols necessary to convey information to > service function implementation points. Where possible, existing IETF > protocols will be used and extended. All protocol extensions work > should be carried out in the working groups responsible for the > protocols being modified in coordination with this working group, but > may be done in this working group after agreement with all the > relevant WG chairs and responsible ADs. > 5) Manageability: This document will address the management of service > function chaining includingrelevant MIBs and YANG data modules, and > service function chaining diagnostics. > Proposed Milestones (all dates TBD): > Request the IESG for publication of an Informational document defining > the problem statement and core use cases for Service Function Chaining > Request the IESG for publication of Informational documents defining > the architecture for SFC and describing the framework and requirements > for a generic service function chaining encapsulation protocol. > Request the IESG for publication of a Standards Track document > specifying the generic service function chaining encapsulation > protocol. > Request the IESG for publication of Informational documents specifying > control plane requirements in support of specific SFC use cases. > Request the IESG for publication of an Informational document defining > SFC manageability including diagnostics, and MIB and YANG data models > to IESG > Request the IESG for publication of Informational applicability > documents defining how the protocol elements developed by the WG may > be combined with other IETF protocols to satisfy the use cases. Thomas From paulq@cisco.com Wed Sep 25 13:21: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 35F6621E8063 for ; Wed, 25 Sep 2013 13:21:27 -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 aweytJaUs4W3 for ; Wed, 25 Sep 2013 13:21: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 40FE221E8088 for ; Wed, 25 Sep 2013 13:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15535; q=dns/txt; s=iport; t=1380140481; x=1381350081; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=j6pibpyTJkPzWMDWur5LE/keoxLpPUFiWWtwI+xCTa0=; b=L6HzqPdv8SexocOBgylJWlTnWIrXqdWdfyTDiSOL5Gc5kwkfAKnVjA1e jnfK06HN6HcpFuLekh4K0CwmzPhAyTJ/VfUI6rlxaVu+oA+OPPrly5Sja 5y+AXwack7uSPZA/bDI9Rdfwoe/VljBYSnS9GZLQkq/4G9Yq9ClXC1Z41 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAIpEQ1KtJXG//2dsb2JhbABbgwc4UsBUgSAWdIIlAQEBAwEBAQE3KwkGBQUHBAIBCBEEAQEBChQFBAcnCxQJCAIECgQFCId4Bgy8KQSOE4ELAgYrBwaDF4EAA6lzgWaBPoFpQQ X-IronPort-AV: E=Sophos;i="4.90,980,1371081600"; d="scan'208";a="264468852" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 25 Sep 2013 20:21:20 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8PKLKqK026349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 20:21:20 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; Wed, 25 Sep 2013 15:21:19 -0500 From: "Paul Quinn (paulq)" To: Ron Parker Thread-Topic: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3] Thread-Index: AQHOugY4BY28kcaVSUOpO28tjUrIV5nXAw+AgAADUACAADMWgA== Date: Wed, 25 Sep 2013 20:21:19 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> <064001ceba06$27012680$75037380$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.172.246] Content-Type: text/plain; charset="us-ascii" Content-ID: <7BBB998D54DB494F83D466CBA894A1D3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "" , Anoop Ghanwani , "" Subject: Re: [nsc] transparent vs. non-transparent services [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: Wed, 25 Sep 2013 20:21:27 -0000 Hi Ron, Using the definition I suggested below, the difference between transparent = and not center around termination. In either case, the service may, or may= not alter the original packets. Only a non-transarant service, will for e= xample, open new connections in response to the original session. A good e= xample is a server load balancer: it can terminate incoming TCP session, in= spect traffic, then open new sessions. To the end user, the service isn't= visible. Paul On Sep 25, 2013, at 10:18 AM, Ron Parker = wrote: > So is the definition of transparent -- packets are unchanged (headers, co= ntent, etc.) and routing/switching path is unaltered? Or is it just the f= ormer? The mere diversion to a service node would seem to constitute "rou= ting/switching is altered".=20 >=20 > Ron >=20 >=20 > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 > Sent: Wednesday, September 25, 2013 1:07 PM > To: > Cc: Ron Parker; Thomas Narten; Anoop Ghanwani; > Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New = NSC WG Charter - charter bullet #3] >=20 > Hi, >=20 > I think there's a further nuance, at least in the service world that is d= ifferent separate from native path vs. diversion/steering discussion. A tr= ansparent service acts a "bump in the wire", the most common example. A no= n-transparent service terminates the traffic (e.g. the original TCP session= ), performs some action, then forwards the traffic via a new connection or = mimicking the original one. >=20 > Thanks > Paul >=20 > On Sep 25, 2013, at 8:44 AM, Adrian Farrel wrote: >=20 >> I *think* the distinction being made is... >>=20 >> Does the packet follow the path it would have followed absent the=20 >> imposition of a service function? If so, the service function is=20 >> applied transparently. If not, the packet is somehow diverted (e.g.=20 >> down a tunnel, by stealing the destination address field, etc.) and=20 >> the service function is applied non-transparently. >>=20 >> If I am right in this, then I think it is not helpful to talk about=20 >> transparent or non-transparent services (or service functions), but=20 >> how they are applied or realised for a particular flow. >>=20 >> Adrian >>=20 >>> -----Original Message----- >>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> Sent: 25 September 2013 15:53 >>> To: Thomas Narten; Anoop Ghanwani >>> Cc: nsc@ietf.org; Adrian Farrel >>> Subject: RE: [nsc] transparent vs. non-transparent services [was Re:=20 >>> New NSC WG Charter - charter bullet #3] >>>=20 >>> Thomas, Anoop, >>>=20 >>> It strikes me that this transparency is not wrt to the originator or=20 >>> addressee >> of the >>> traffic, but rather between the SFC classifier and the SFC service=20 >>> nodes >> (SNs). In >>> particular, whether an encapsulating "transport" header (e.g.,=20 >>> IPv4/UDP) is applied in front of the NSC/SFC "service header" (which=20 >>> is in front of the >> original >>> packet), or not. >>>=20 >>> If an IP-layer encapsulation is applied, for example, the packets are=20 >>> routed/switched normally amongst the SFC classifier and SN's because=20 >>> the packets are explicitly IP addressed at each hop (given that the=20 >>> SN's would >> need to >>> change the destination IP in the encapsulating header to select the "ne= xt" >> SN). >>> However, if a "transport" header is not applied, policy-based >> routing/switching >>> would need to be used to steer the traffic in such a way that did not >> necessarily >>> conform to traditional routing/switching decisions. >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >>> Thomas Narten >>> Sent: Wednesday, September 25, 2013 10:35 AM >>> To: Anoop Ghanwani >>> Cc: nsc@ietf.org; Adrian Farrel >>> Subject: [nsc] transparent vs. non-transparent services [was Re: New=20 >>> NSC WG Charter - charter bullet #3] >>>=20 >>> Hi Anoop. >>>=20 >>> Anoop Ghanwani writes: >>>=20 >>>> Since I have been asked the question offline, I will go ahead and=20 >>>> explain what I mean by transparent vs non-transparent appliances. >>>> With a non-transparent appliance, the appliance appears as a "router" >>>> in the path of the data. As far as I'm aware this is how load=20 >>>> balancers are deployed and this is how firewalls are commonly=20 >>>> deployed. In the non-transparent case, the address of the appliance=20 >>>> does not appear in the packet; instead packets are diverted to the=20 >>>> appliance using PBR. This used sometimes for IDS/IPS type appliances. >>>=20 >>> I don't quite get this. To me, SFC is all about applying service=20 >>> functions to >> traffic >>> flows -- but in a way that is transparent to those traffic flows and=20 >>> the end >> points >>> originating them. That is, "applications" generating traffic aren't=20 >>> generally >> aware >>> of these service functions and they aren't really asking for them.=20 >>> They are >> applied >>> as the result of network policy/operations, not because the=20 >>> applications need them (for correctness). E.g., load balancing and=20 >>> firewalls. Those sorts of >> things >>> are applied by network operators whether the applications want them=20 >>> or not. So the kinds of service functions this group is interested in=20 >>> are in some sense >> by >>> definition "transparent" to applications. >>>=20 >>> [BTW, it would be useful to have a term for the endpoints of a chain >>> -- that is what I mean by "application" above. These are the=20 >>> components of the overall service that are doing the work, i.e., the=20 >>> DB, the application server, >> etc. >>> They are *NOT* service functions, in my mind.] >>>=20 >>> Service functions aren't going to be addressed by the traffic -=20 >>> traffic is >> between >>> the "applications", i.e., the end points of a service chain. >>>=20 >>> Today, service functions are deployed along the path between=20 >>> applications -- because that is how we know how to do it. Going=20 >>> forward, we don't want to >>> *require* that anymore. >>>=20 >>> So back to your example of an appliance, I would call such appliances=20 >>> "transparent" because they are not explicitely addressed by the=20 >>> traffic flows >> and >>> are in fact transparent to the applications. >>>=20 >>> Thomas >>>=20 >>>=20 >>>=20 >>>> Anoop >>>=20 >>>> On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel w= rote: >>>=20 >>>>> Hi Anoop, >>>>>=20 >>>>>> My interpretation of the following line: >>>>>>>>=20 >>>>>> A document will describe the single service-level encapsulation=20 >>>>>> protocol >>>>> for >>>>>> conveying the service function chain and the service function path >>>>>>>>=20 >>>>>>=20 >>>>>> is that there will be a single encapsulation protocol at the=20 >>>>>> "service >>>>> layer". >>>>> Are >>>>>> we saying that there could be more than one way of carrying this=20 >>>>>> header >>>>> but >>>>>> that the contents would be the same? >>>>>=20 >>>>> That is my interpretation. >>>>>=20 >>>>> I.e., this is an encapsulation that can be placed between the "transp= ort" >>>>> (e.g., >>>>> IP, MPLS, TCP, HTTP....) and the payload. >>>>>=20 >>>>>> Would the output of this WG would allow the creation of a service=20 >>>>>> chain >>>>> even >>>>>> when overlays are not in use? (This is not clear from reading the >>>>> charter.) >>>>>=20 >>>>> Well, erm, what is an "overlay"? >>>>> Isn't an overlay just a network that happens to be running over=20 >>>>> another network? >>>>> Why would that need to be mentioned explicitly? >>>>> Why would you assume it is ruled out if it is not mentioned? >>>>>=20 >>>>>> Finally, is the work intended to support chains of both=20 >>>>>> transparent and >>>>> non- >>>>>> transparent appliances, or is the focus mainly on transparent >>>>> appliances? I >>>>>> ask because there may be interesting layering issues with respect=20 >>>>>> to the placement of this header, especially if we have a=20 >>>>>> combination of >>>>> transparent >>>>>> and non-transparent appliances. >>>>>=20 >>>>> That is probably a good question. >>>>> Personally, I would like to put it "for investigation." I.e., I=20 >>>>> don't think we know enough about the use cases and requirements to=20 >>>>> answer your question at this stage. >>>>>=20 >>>>> But if enough people show up on the list saying that they only want=20 >>>>> to handle one categorisation, then perhaps we can limit from day=20 >>>>> one. >>>>>=20 >>>>> Cheers, >>>>> Adrian >>>>>=20 >>>>>=20 >>>=20 >>>> --001a11c227eea3624604e6fb76cb >>>> Content-Type: text/html; charset=3DISO-8859-1 >>>> Content-Transfer-Encoding: quoted-printable >>>=20 >>>>
Hi >>>> Adrian,

>>>
That =3D is my=20 >>>> interpretation.

I.e., this is an encapsulation that can be=20 >>>> pla=3D ced between the "transport" (e.g.,
IP, MPLS, TCP, >>>> HTTP....) an=3D d the payload.
>>>>
>>>

OK, I think that's a=20 >>>> bit dif=3D ferent from what Uri was arguing=20 >>>> for.

>>>=3D >>>>
Well, erm, what is an "overlay"?
Isn't=20 >>>> an overl=3D ay just a network that happens to be running over another= =20 >>>> network?
Why would that need to be mentioned explicitly?
Why=20 >>>> would you assume it =3D is ruled out if it is not=20 >>>> mentioned?
>>>
<=3D >>>> br>
I tend to think of an overlay as one where there are=20 >>>> br>multiple=3D >>>> occurrences of the same layer of =3DA0header in the packet., but maybe= =20 >>>> I hav=3D e it wrong. =3DA0Does the IETF have a formal definition for=20 >>>> this?

>>>
That is=20 >>>> probably a good question=3D .
Personally, I would like to put it=20 >>>> "for investigation." I.e.=3D , I don't think we
know= =20 >>>> enough about the use cases and requirements =3D to answer your=20 >>>> question at this
stage.

But if enough people show up on=20 >>>> the list saying that they onl=3D y want to handle
one=20 >>>> categorisation, then perhaps we can limit from day =3D one.
>>> class=3D3D"gmail_extra">>>>
>>> tra">
I think it would make=20 >>>> sense to add som=3D ething explicit to the charter about=20 >>>> this.
=3D
>>> class=3D3D"gmail_extra">Since I have been asked the question o=3D=20 >>>> ffline, I will go ahead and explain what I mean by transparent vs=20 >>>> non-trans=3D parent appliances. =3DA0With a non-transparent appliance,= =20 >>>> the appliance appea=3D rs as a "router" in the path of the=20 >>>> data. =3DA0As far as I'm aw=3D are this is how load balancers are= =20 >>>> deployed and this is how firewalls are c=3D ommonly deployed. =3DA0In= =20 >>>> the non-transparent case, the address of the applia=3D nce does not=20 >>>> appear in the packet; instead packets are diverted to the appl=3D=20 >>>> iance using PBR. =3DA0This used sometimes for IDS/IPS type=20 >>>> appliances.

>>> class=3D3D"gmail_extra">Anoop
>>> r>
On Sun, Sep 22, 2013 at 6:11 AM, Adrian= =20 >>>> r>Farrel=3D >>>> <>>> target=3D3D"_bl=3D ank">adrian@olddog.co.uk> wrote:
= =20 >>>>
>>> 0.8ex;border-=3D=20 >>>> left-width:1px;border-left-color:rgb(204,204,204);border-left-style: >>>> so >>>> lid;p=3D >>>> adding-left:1ex">Hi Anoop,
>>>>

>>>> > My interpretation of the following line:
>>>
=20 >>>> > A document will describe the single service-level encapsulation=20 >>>> protoc=3D ol for
> conveying the service function chain and the= =20 >>>> service function path
>>>
>
> is that=20 >>>> there will be a single encapsulation protocol at the "ser=3D vice= =20 >>>> layer".
Are
> we saying that there could be more=20 >>>> than one way of carrying this heade=3D r but
> that the=20 >>>> contents would be the same?

That is my=20 >>>> interpretation.

I.e., this is an encapsulation that can be=20 >>>> placed between the "transpo=3D rt" (e.g.,
IP, MPLS, TCP,= =20 >>>> HTTP....) and the payload.

> Would the= =20 >>>> output of this WG would allow the creation of a service chai=3D n=20 >>>> even
> when overlays are not in use? =3DA0(This is not clear=20 >>>> from reading the c=3D harter.)

Well, erm, what is an=20 >>>> "overlay"?
Isn't an overlay just a network that=20 >>>> happens to be running over another=3D network?
Why would that need= =20 >>>> to be mentioned explicitly?
Why would you assume it is ruled out=20 >>>> if it is not mentioned?

> Finally, is= =20 >>>> the work intended to support chains of both transparent an=3D d=20 >>>> non-
> transparent appliances, or is the focus mainly on=20 >>>> transparent applianc=3D es? =3DA0I
> ask because there may be=20 >>>> interesting layering issues with respect to t=3D he
> placement= =20 >>>> of this header, especially if we have a combination of trans=3D=20 >>>> parent
> and non-transparent appliances.

That=20 >>>> is probably a good question.
Personally, I would like to put it=20 >>>> "for investigation." I.e., I d=3D on't think we
know= =20 >>>> enough about the use cases and requirements to answer your question=20 >>>> at=3D this
stage.

But if enough people show up on the=20 >>>> list saying that they only want to hand=3D le
one categorisation,= =20 >>>> then perhaps we can limit from day one.

Cheers,
=20 >>>> Adrian


>>>=20 >>>> --001a11c227eea3624604e6fb76cb-- >>>=20 >>>> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0224793606959901704=3D= =3D >>>> Content-Type: text/plain; charset=3D"us-ascii" >>>> MIME-Version: 1.0 >>>> Content-Transfer-Encoding: 7bit >>>> Content-Disposition: inline >>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>>> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0224793606959901704=3D= =3D-- >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >=20 From paulq@cisco.com Wed Sep 25 13:22: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 2CD0B21F9609 for ; Wed, 25 Sep 2013 13:22: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 T1mRsRlCLZ6q for ; Wed, 25 Sep 2013 13:22:25 -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 E7AE021F8421 for ; Wed, 25 Sep 2013 13:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1614; q=dns/txt; s=iport; t=1380140545; x=1381350145; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v3C7aoztbpWz/r+ARcJKpp6vnKD8Agtc4TjkYZfHGL8=; b=lDJ1to3v2bMRyvEAbqPRv9T+KMyTishIfaQVtb5wrtVbpEAEaUE8wJV4 ttI4wkOI1vV9XbpAaMUC9yQVA5E1FdwVwdGD+7rPw8YHAqOQXHtNKlA49 gTm1lgg0HkSQaUHYHRPO8sdG6+cy7grkC0NizoG9aaFMi22AtWf8uD7Ux Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAJtEQ1KtJV2Z/2dsb2JhbABbgweBCsBUgSAWdIIlAQEBAwE6PwUHBAIBCBEBAwEBCxQFBAcyFAMGCAIEDgUIE4dlBrw4jx4CBisHBoMXgQADqXOBZoE+gio X-IronPort-AV: E=Sophos;i="4.90,980,1371081600"; d="scan'208";a="264270636" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 25 Sep 2013 20:22:18 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8PKMIt1003766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 20:22:18 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 15:22:17 -0500 From: "Paul Quinn (paulq)" To: Ron Parker Thread-Topic: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3] Thread-Index: AQHOuhQTE7xmYsRQmUuk7orbOxe6DZnXCPcAgAAwqIA= Date: Wed, 25 Sep 2013 20:22:17 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> <064001ceba06$27012680$75037380$@olddog.co.uk> <201309251724.r8PHO9hk031606@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.172.246] Content-Type: text/plain; charset="us-ascii" Content-ID: <57EF6CB40A43D94D8D7FCA7E8F8B789F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "" , Anoop Ghanwani , "" Subject: Re: [nsc] transparent vs. non-transparent services [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: Wed, 25 Sep 2013 20:22:31 -0000 I agree, the problem, architecture and associated solutions should be appli= cable in either (any?) case. On Sep 25, 2013, at 10:28 AM, Ron Parker = wrote: > Thomas, >=20 > I agree that the notion of transparent service is not necessary to incorp= orate in our work. >=20 > Ron >=20 > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com]=20 > Sent: Wednesday, September 25, 2013 1:24 PM > To: Ron Parker > Cc: Paul Quinn (paulq); ; Anoop Ghanwani; > Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New = NSC WG Charter - charter bullet #3] >=20 > Ron, >=20 >> So is the definition of transparent -- packets are unchanged (headers,=20 >> content, etc.) and routing/switching path is unaltered? >> Or is it just the former? The mere diversion to a service node would=20 >> seem to constitute "routing/switching is altered". >=20 > I think the point is we don't exactly have an agreed to defintion of "tra= nsparent" in the NSC context, so it's not particularly helpful to use it in= describing NSC behavior without being clear about what is meant. >=20 > For services in NSC, packets clearly will get modified in some cases (e.g= . NAT or proxies) but won't in others. So distinguishing types of services = by how much they change the packets they inspect is probably not helpful fo= r NSC. NSC doesn't really care *what* the services does, just that the serv= ice exists and packets need to be steered to travel through the service. >=20 > Thomas >=20 From paulq@cisco.com Wed Sep 25 13:31: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 A874D21E8055 for ; Wed, 25 Sep 2013 13:31:56 -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 q03mDaoRCZ9O for ; Wed, 25 Sep 2013 13:31:51 -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 9F3D121F9649 for ; Wed, 25 Sep 2013 13:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6572; q=dns/txt; s=iport; t=1380141111; x=1381350711; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AAUCGxZ0gIpzEMNzB2VwCmOJB/s+vttMgDD6e3jw+fM=; b=GcDEynC6qpJUuNMSnMPErjWk05w/EmshicbN8jFb3x8E+iTBg6Nbsm6T 9UxIin3/wXSRF8xGYkJ8+MpF8Vfu1lJb7j9MSMUs1ByPppPU/3llEcEtS Qehs+FJkGk8L1NMH8KVtWqdXLL+6M5hcbBP6khgN61eM1v3AvFOHpMrZi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAOtGQ1KtJV2c/2dsb2JhbABRCoMHOFLAVIEhFnSCJQEBAQMBAQEBNysJCwUHBAIBCBEEAQEBChQJBycLFAkIAgQOBQgTh2UGDLwmBI4OgRACBisHAgSDF4EAA6lzgySCKg X-IronPort-AV: E=Sophos;i="4.90,980,1371081600"; d="scan'208";a="264275995" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 25 Sep 2013 20:31:51 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8PKVokh018789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 20:31:50 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 15:31:50 -0500 From: "Paul Quinn (paulq)" To: Ron Parker Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAEgCgAABXPIWAADiaogAAN2LngAAJNV2AAAKlHIAAAzxbAAAeZMoAAAJQeAAABncTgA== Date: Wed, 25 Sep 2013 20:31:49 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> <583789CD-C183-451C-B4DD-8944A1DC03B1@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.172.246] Content-Type: text/plain; charset="us-ascii" Content-ID: <164D8FFAE94E2949B8A9AA20286C1540@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , Thomas Nadeau , David Allan I , Linda Dunbar , "adrian@olddog.co.uk" Subject: Re: [nsc] 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: Wed, 25 Sep 2013 20:31:56 -0000 Ron, As you point out a central registry isn't really viable for all solutions. = In many environments, the "controller" will provide meaning for the contex= t headers. Thanks Paul On Sep 25, 2013, at 10:27 AM, Ron Parker wrote: > I agree with Dave that subscriber ID and those fields necessary to comple= te the chain forwarding (may or may not end up being a simple chain id) are= the most important metadata. However, there may be other interesting fie= lds to consider such as location of the subscriber (e.g., cell id in a 3gp= p network). =20 >=20 > But other less universally useful fields may prove too troublesome to inc= orporate. Take DPI conclusions as a counter example. How are they descr= ibed? Where is the central registry of known protocols/applications and t= he strings and/or integers used to identify them? It would be an ongoing = battle to try to communicate DPI conclusions between SF's in such a way tha= t all could agree on the interpretation. >=20 > Thanks. >=20 > Ron >=20 >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Dav= id Allan I > Sent: Wednesday, September 25, 2013 12:21 PM > To: Jerome Moisand; Thomas Nadeau; Linda Dunbar > Cc: nsc@ietf.org; adrian@olddog.co.uk > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 >=20 > I'm not a fan of encapsulating the frame in a database before forwarding.= ... >=20 > I understand Joel's use case of carrying the subscriber ID (assuming the = entire frame presented to a BNG is not preserved), and the need for a chain= ID as a forwarding "helper". These two items strike me as both "necessary = and sufficient". >=20 > Cheers > Dave=20 >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jer= ome Moisand > Sent: Tuesday, September 24, 2013 6:51 PM > To: Thomas Nadeau; Linda Dunbar > Cc: nsc@ietf.org; adrian@olddog.co.uk > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 >=20 > There are definitely quite a few additional candidates for metadata field= s of interest... But I believe we need much more work on the PROBLEM STATEM= ENT, and not jump to solution design.=20 >=20 > We really need to work much more on use cases. Some use cases may imply m= ore 'metadata' than others. Simple problems may be solved by simple means. = More complex problems may require more complex elements of solutions. Some = cases could be solved by signaling means instead of data plane means. Or th= e reverse way around. Etc. >=20 > Let me suggest we give more priority to refining the problem statement(s)= first... And not rush the design process. >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Tho= mas Nadeau > Sent: Tuesday, September 24, 2013 8:18 PM > To: Linda Dunbar > Cc: nsc@ietf.org; adrian@olddog.co.uk > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 >=20 >=20 > On Sep 24, 2013:7:02 PM, at 7:02 PM, Linda Dunbar wrote: >=20 >> Adrian, >>=20 >> Very good analysis. Thank you.=20 >>=20 >> "Metadata" has been used extensively in the NSC context. But beyond the = "service chain ID", I can't find any other necessary information required t= o 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 exam= ples of the information required to be exchanged among those "Service Funct= ions" given by the draft-quinn-nsc-arch-00? >=20 > Some examples might be OAM, other stats, service chain descriptions, etc= ... >=20 > --Tom >=20 >=20 >> 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. >=20 > =09 >=20 >>=20 >>=20 >> Thanks, Linda >>=20 >>> -----Original Message----- >>>=20 >>> I think "metadata" is a particularly poor term to use here because it=20 >>> 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. >>>=20 >>> 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=20 >>> service node (e.g. about how to perform given some state >>> information) >>>=20 >>> We should also look at what you mean by out-of-band. I think here you=20 >>> mean "using some information exchange protocol." >>=20 >> [Linda] Since each Service-Chain ID represents a list of service functio= ns, it is possible to use "out-of-band" control channel to pass the informa= tion on the sequence of Service Functions associated with the ID.=20 >>=20 >>=20 >>>=20 >>> The charter says: >>>=20 >>> | 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 protocols=20 >>> | or protocol extensions to convey the service path and for=20 >>> | communication between nodes that implement service functions >>>=20 >>> and: >>>=20 >>> | 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. >>>=20 >>> This feels like out-of-band exchange of information is expected. >>>=20 >>> Adrian >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >>=20 >=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing 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 mn1921@att.com Wed Sep 25 14:01:41 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 A091621F9B0E for ; Wed, 25 Sep 2013 14:01:41 -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 cITLkR4vERsu for ; Wed, 25 Sep 2013 14:01:35 -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 D0F5021F9E62 for ; Wed, 25 Sep 2013 14:01:33 -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 d2f43425.2aaad1c15940.8843742.00-527.24330414.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 25 Sep 2013 21:01:33 +0000 (UTC) X-MXL-Hash: 52434f2d153d505a-b8d2ab23a5dff6d279eb3ddb790056055351e0a5 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 c2f43425.0.8843711.00-367.24330333.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 25 Sep 2013 21:01:33 +0000 (UTC) X-MXL-Hash: 52434f2d404c63c2-967a90e9f6a1ec51fa2e58d6599e73bb97c0a19b 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 r8PL1W2p032560; Wed, 25 Sep 2013 17:01:32 -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 r8PL1H7P032339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 17:01:24 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (MISOUT7MSGHUB9C.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 25 Sep 2013 21:01:02 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.03.0158.001; Wed, 25 Sep 2013 17:01:02 -0400 From: "NAPIERALA, MARIA H" To: Thomas Narten , "Jim Guichard (jguichar)" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXOIIA///I2MA= Date: Wed, 25 Sep 2013 21:01:02 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012A32C0@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <201309252010.r8PKAOFW023454@cichlid.raleigh.ibm.com> In-Reply-To: <201309252010.r8PKAOFW023454@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=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=-s3I2kwCOWQA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=FFZ-zzI3G] X-AnalysisOut: [zMA:10 a=48vgC7mUAAAA:8 a=OOM0mwMUZ0S_rmJK-V0A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=N6U82jpL0wwT9Yeq:21 a=v9aUJs0] X-AnalysisOut: [FazHv12AG:21] Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 21:01:41 -0000 The group charter's write-up says that: "The Service Function Chaining (SFC= ) working group will develop new approaches to service delivery ..." (i.e.,= not one "approach" but "approaches", which means more than one).=20 But then is states that a document will be developed such that it "will de= scribe *the(?) single* service-level data plane encapsulation format for co= nveying the service function chain and the service function path associated= with data packets, and for carrying context information between nodes that= implement service functions".=20 How to do you reconcile those two statements? In my opinion, we should open the door for more than one solution to servic= e chaining. Maria > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Wednesday, September 25, 2013 4:10 PM > To: Jim Guichard (jguichar) > Cc: nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter >=20 > Jim et al, >=20 > Here are some specific suggestions on the charter (this is from the > version posted Sept. 13). I think they are all editorial, crisping up > the language used and consistent with the discussion on the list. >=20 > > Proposed Service Function Chaining (SFC) WG Charter >=20 > > Networks, servers, storage technologies, and applications, have all > > undergone significant change in recent years with the introduction > > of virtualization, network overlays, and orchestration. The process > > of service delivery is changing from the physical insertion of > > equipment on the path into a mechanism for causing the path or data > > to transit specific physical or virtual nodes on which the service > > functions are performed. Services are typically implemented by the > > ordered combination of a number of service functions that may be > > implemented at different points within the network. Service delivery > > is currently both a technical and organisational challenge that > > involves significant modification to the network configuration. >=20 >=20 > Suggest changing the above as follows: >=20 > 1) change sentence: >=20 > The process of service delivery is changing from the physical > insertion of equipment on the path into a mechanism for causing > the path or data to transit specific physical or virtual nodes on > which the service functions are performed. >=20 > To: >=20 >=20 > Today, a common deployment model has service functions > physically inserted on the data forwarding path between > communicating peers. Going forward, however, there is a desire to > move to a different model, where service functions are not > required to reside on the default data path and traffic is > instead steered through services, wherever they are deployed. >=20 >=20 > 2) Reorder the existing text in the pargraph so that teh revised text > goes at end of first paragraph, i.e., resulting in: >=20 > Networks, servers, storage technologies, and applications, have > all undergone significant change in recent years with the > introduction of virtualization, network overlays, and > orchestration. Service delivery is currently both a technical > and organisational challenge that involves significant > modification to the network configuration. Services are > typically implemented by the ordered chaining of a number of > service functions (e.g., firewalls, load-balancers, etc.) that > are implemented at different points within the network. Today, a > common deployment model has service functions physically inserted > on the data forwarding path between communicating peers. Going > forward, however, there is a desire to move to a different model, > where service functions are not required to reside on the default > data path and traffic is instead steered through services, > wherever they are deployed. >=20 > > For a given service, the abstracted view of the required service > > functions and the order in which they are to be invoked is called a >=20 > s/invoked/applied/ ??? >=20 > > Service Function Chain (SFC). Since a given service function may be > > available on more than one node within a network, a ServiceFunction > > Chain is instantiated via the selection of specific service function > > instances and the network nodes on which they are provided, thereby > > forming a servicetopology: this is called a Service Function Path. > The > > service functions may be applied at a specific layer within the > > network protocol stack (network layer, application layer, etc.). >=20 > I think talking about "layers" here is confusing and not really > needed. SFC doesn't really care about what layer is used. It only > cares about steering traffic to a service -- what that service does > with that traffic is the service's own business. Suggest tweaking: >=20 > Old: >=20 > > The service functions may be applied at a specific layer within the > > network protocol stack (network layer, application layer, etc.). >=20 > better: >=20 > Service functions are applied to the traffic flows that are directed > through them. What the service function actually does to such > traffic is service-specific and not of concern to SFC. >=20 >=20 > > 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. The working group > > will also examine what information needs to be gathered from the > > network and service functions in support of service function chaining > > and how that information may be made available to nodes that > implement > > the service functions. >=20 > The above doesn't actually include the "steering" part. Suggest: >=20 > Old: >=20 > 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. >=20 > New: >=20 > The Service Function Chaining (SFC) working group will develop new > approaches to service delivery and deployment. It will produce a > framework for service function chaining that includes the > necessary protocols or protocol extensions to convey service path > and service path information to nodes that implement service > functions, as well as mechanisms for steering traffic through > service functions. >=20 > > Specifically, the SFC WG is chartered to deliver the following: >=20 > > 1) Problem Statement: This document will provide a summary of the > > problem space to be addressed by the WG including example high-level > > use cases. Additionally, the WG will normalize nomenclature and > > definitions for service function chaining. >=20 > > 2) Architecture: This document will provide a description of the > > architectural building blocks and their relationships including > > interconnection, placement of capabilities, management, diagnostics, > > and security models, as well as requirements on the protocol > > mechanisms. >=20 > > 3) Generic Service Function Chaining Encapsulation: A document will > > describe the single service-level encapsulation protocol for > conveying > > communicating information between nodes that implement service > > functions. >=20 > Better: >=20 > 3) Generic Service Function Chaining Encapsulation: A document will > describe the single service-level data plane encapsulation format > for conveying the service function chain and the service function > path associated with data packets, and for carrying context > information > between nodes that implement service functions. >=20 > > It is intended that the encapsulation be agnostic to > > the network layer at which it is applied and the service that is > being > > constructed. That is, the same encapsulation may be used on a service > > function path realised at the network layer or at any other layer, > and > > the same encapsulation willapply for the construction of service > > function paths regardless of the actual service. >=20 > If I understand the list discussion, I think the above really just > means: >=20 > It is intended that the encapsulation be agnostic to the > underlying network technology (i.e,. IP, MPLS, etc.) being used > for transport as well to the specific services being supported. >=20 > > 4) Control Plane Mechanisms: A set of documents will be developed to > > describe requirements and protocols necessary to convey information > to > > service function implementation points. Where possible, existing IETF > > protocols will be used and extended. All protocol extensions work > > should be carried out in the working groups responsible for the > > protocols being modified in coordination with this working group, but > > may be done in this working group after agreement with all the > > relevant WG chairs and responsible ADs. >=20 > > 5) Manageability: This document will address the management of > service > > function chaining includingrelevant MIBs and YANG data modules, and > > service function chaining diagnostics. >=20 > > Proposed Milestones (all dates TBD): >=20 > > Request the IESG for publication of an Informational document > defining > > the problem statement and core use cases for Service Function > Chaining >=20 > > Request the IESG for publication of Informational documents defining > > the architecture for SFC and describing the framework and > requirements > > for a generic service function chaining encapsulation protocol. >=20 > > Request the IESG for publication of a Standards Track document > > specifying the generic service function chaining encapsulation > > protocol. >=20 > > Request the IESG for publication of Informational documents > specifying > > control plane requirements in support of specific SFC use cases. >=20 > > Request the IESG for publication of an Informational document > defining > > SFC manageability including diagnostics, and MIB and YANG data models > > to IESG >=20 > > Request the IESG for publication of Informational applicability > > documents defining how the protocol elements developed by the WG may > > be combined with other IETF protocols to satisfy the use cases. >=20 >=20 > Thomas >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From I.Smith@F5.com Wed Sep 25 14:08: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 A072621F84EA for ; Wed, 25 Sep 2013 14:08:08 -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 l3nRWRluJG1J for ; Wed, 25 Sep 2013 14:08:04 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 6C61F21F9BD0 for ; Wed, 25 Sep 2013 14:07: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=1380143278; x=1411679278; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=98fPR9DESmXwhGz7SnRA5rbgPGpI5jxiEsS9G4TaSyA=; b=ON/sEybDZTwhj2yKb63s97H6RI0myHpT/UJdG3ZYmDIUVU/kGN7gtQqj bTk3Ll+cw7aJzYJXFEC8FhqT4OZFW+/TuMPwATGFQFXw5CBTBjJj119mt ftYoCspr55zJ27a8Uk0Ggc6b/bwLvLQOHv41S0JzOcDJ1rYPydEv/6qt+ w=; X-IronPort-AV: E=Sophos;i="4.90,980,1371081600"; d="scan'208";a="81973957" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 25 Sep 2013 21:07:43 +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; Wed, 25 Sep 2013 14:07:42 -0700 From: Ian Smith To: "NAPIERALA, MARIA H" , Thomas Narten , "Jim Guichard (jguichar)" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgD//4sTpA== Date: Wed, 25 Sep 2013 21:07:42 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A6EF92B@SEAEMBX02.olympus.F5Net.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <201309252010.r8PKAOFW023454@cichlid.raleigh.ibm.com>, <1D70D757A2C9D54D83B4CBD7625FA80E012A32C0@MISOUT7MSGUSR9I.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012A32C0@MISOUT7MSGUSR9I.ITServices.sbc.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] New NSC 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: Wed, 25 Sep 2013 21:08:08 -0000 >In my opinion, we should open the door for more than one solution to servi= ce chaining.=0A= =0A= I concur. =0A= =0A= There are a number of ways to skin this particular cat, some of which don't= require a new on-the-wire protocol because they use protocols that are alr= eady defined today in their fullest capacity or in novel combinations. =0A= =0A= It seems to me that the key question that must be answered in the charter i= s whether or not this is a WG to deliver an architecture (which may or may = not include delivering a protocol) or a WG to merely deliver yet-another-ov= erlay-protocol.=0A= =0A= =0A= =0A= =0A= =0A= ________________________________________=0A= From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of NAPIERALA, M= ARIA H [mn1921@att.com]=0A= Sent: Wednesday, September 25, 2013 5:01 PM=0A= To: Thomas Narten; Jim Guichard (jguichar)=0A= Cc: nsc@ietf.org=0A= Subject: Re: [nsc] New NSC WG Charter=0A= =0A= The group charter's write-up says that: "The Service Function Chaining (SFC= ) working group will develop new approaches to service delivery ..." (i.e.,= not one "approach" but "approaches", which means more than one).=0A= =0A= But then is states that a document will be developed such that it "will de= scribe *the(?) single* service-level data plane encapsulation format for co= nveying the service function chain and the service function path associated= with data packets, and for carrying context information between nodes that= implement service functions".=0A= =0A= How to do you reconcile those two statements?=0A= In my opinion, we should open the door for more than one solution to servic= e chaining.=0A= =0A= Maria=0A= =0A= =0A= =0A= > -----Original Message-----=0A= > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=0A= > Thomas Narten=0A= > Sent: Wednesday, September 25, 2013 4:10 PM=0A= > To: Jim Guichard (jguichar)=0A= > Cc: nsc@ietf.org=0A= > Subject: Re: [nsc] New NSC WG Charter=0A= >=0A= > Jim et al,=0A= >=0A= > Here are some specific suggestions on the charter (this is from the=0A= > version posted Sept. 13). I think they are all editorial, crisping up=0A= > the language used and consistent with the discussion on the list.=0A= >=0A= > > Proposed Service Function Chaining (SFC) WG Charter=0A= >=0A= > > Networks, servers, storage technologies, and applications, have all=0A= > > undergone significant change in recent years with the introduction=0A= > > of virtualization, network overlays, and orchestration. The process=0A= > > of service delivery is changing from the physical insertion of=0A= > > equipment on the path into a mechanism for causing the path or data=0A= > > to transit specific physical or virtual nodes on which the service=0A= > > functions are performed. Services are typically implemented by the=0A= > > ordered combination of a number of service functions that may be=0A= > > implemented at different points within the network. Service delivery=0A= > > is currently both a technical and organisational challenge that=0A= > > involves significant modification to the network configuration.=0A= >=0A= >=0A= > Suggest changing the above as follows:=0A= >=0A= > 1) change sentence:=0A= >=0A= > The process of service delivery is changing from the physical=0A= > insertion of equipment on the path into a mechanism for causing=0A= > the path or data to transit specific physical or virtual nodes on=0A= > which the service functions are performed.=0A= >=0A= > To:=0A= >=0A= >=0A= > Today, a common deployment model has service functions=0A= > physically inserted on the data forwarding path between=0A= > communicating peers. Going forward, however, there is a desire to=0A= > move to a different model, where service functions are not=0A= > required to reside on the default data path and traffic is=0A= > instead steered through services, wherever they are deployed.=0A= >=0A= >=0A= > 2) Reorder the existing text in the pargraph so that teh revised text=0A= > goes at end of first paragraph, i.e., resulting in:=0A= >=0A= > Networks, servers, storage technologies, and applications, have=0A= > all undergone significant change in recent years with the=0A= > introduction of virtualization, network overlays, and=0A= > orchestration. Service delivery is currently both a technical=0A= > and organisational challenge that involves significant=0A= > modification to the network configuration. Services are=0A= > typically implemented by the ordered chaining of a number of=0A= > service functions (e.g., firewalls, load-balancers, etc.) that=0A= > are implemented at different points within the network. Today, a=0A= > common deployment model has service functions physically inserted=0A= > on the data forwarding path between communicating peers. Going=0A= > forward, however, there is a desire to move to a different model,=0A= > where service functions are not required to reside on the default=0A= > data path and traffic is instead steered through services,=0A= > wherever they are deployed.=0A= >=0A= > > For a given service, the abstracted view of the required service=0A= > > functions and the order in which they are to be invoked is called a=0A= >=0A= > s/invoked/applied/ ???=0A= >=0A= > > Service Function Chain (SFC). Since a given service function may be=0A= > > available on more than one node within a network, a ServiceFunction=0A= > > Chain is instantiated via the selection of specific service function=0A= > > instances and the network nodes on which they are provided, thereby=0A= > > forming a servicetopology: this is called a Service Function Path.=0A= > The=0A= > > service functions may be applied at a specific layer within the=0A= > > network protocol stack (network layer, application layer, etc.).=0A= >=0A= > I think talking about "layers" here is confusing and not really=0A= > needed. SFC doesn't really care about what layer is used. It only=0A= > cares about steering traffic to a service -- what that service does=0A= > with that traffic is the service's own business. Suggest tweaking:=0A= >=0A= > Old:=0A= >=0A= > > The service functions may be applied at a specific layer within the=0A= > > network protocol stack (network layer, application layer, etc.).=0A= >=0A= > better:=0A= >=0A= > Service functions are applied to the traffic flows that are directed=0A= > through them. What the service function actually does to such=0A= > traffic is service-specific and not of concern to SFC.=0A= >=0A= >=0A= > > The Service Function Chaining (SFC) working group will develop new=0A= > > approaches to service delivery and deployment, by providing a=0A= > > framework for service function chaining and the necessary protocols=0A= > or=0A= > > protocol extensions to convey the service path and for communication=0A= > > between nodes that implement service functions. The working group=0A= > > will also examine what information needs to be gathered from the=0A= > > network and service functions in support of service function chaining= =0A= > > and how that information may be made available to nodes that=0A= > implement=0A= > > the service functions.=0A= >=0A= > The above doesn't actually include the "steering" part. Suggest:=0A= >=0A= > Old:=0A= >=0A= > The Service Function Chaining (SFC) working group will develop new=0A= > approaches to service delivery and deployment, by providing a=0A= > framework for service function chaining and the necessary=0A= > protocols or protocol extensions to convey the service path and=0A= > for communication between nodes that implement service functions.=0A= >=0A= > New:=0A= >=0A= > The Service Function Chaining (SFC) working group will develop new=0A= > approaches to service delivery and deployment. It will produce a=0A= > framework for service function chaining that includes the=0A= > necessary protocols or protocol extensions to convey service path=0A= > and service path information to nodes that implement service=0A= > functions, as well as mechanisms for steering traffic through=0A= > service functions.=0A= >=0A= > > Specifically, the SFC WG is chartered to deliver the following:=0A= >=0A= > > 1) Problem Statement: This document will provide a summary of the=0A= > > problem space to be addressed by the WG including example high-level=0A= > > use cases. Additionally, the WG will normalize nomenclature and=0A= > > definitions for service function chaining.=0A= >=0A= > > 2) Architecture: This document will provide a description of the=0A= > > architectural building blocks and their relationships including=0A= > > interconnection, placement of capabilities, management, diagnostics,=0A= > > and security models, as well as requirements on the protocol=0A= > > mechanisms.=0A= >=0A= > > 3) Generic Service Function Chaining Encapsulation: A document will=0A= > > describe the single service-level encapsulation protocol for=0A= > conveying=0A= > > communicating information between nodes that implement service=0A= > > functions.=0A= >=0A= > Better:=0A= >=0A= > 3) Generic Service Function Chaining Encapsulation: A document will=0A= > describe the single service-level data plane encapsulation format=0A= > for conveying the service function chain and the service function=0A= > path associated with data packets, and for carrying context=0A= > information=0A= > between nodes that implement service functions.=0A= >=0A= > > It is intended that the encapsulation be agnostic to=0A= > > the network layer at which it is applied and the service that is=0A= > being=0A= > > constructed. That is, the same encapsulation may be used on a service= =0A= > > function path realised at the network layer or at any other layer,=0A= > and=0A= > > the same encapsulation willapply for the construction of service=0A= > > function paths regardless of the actual service.=0A= >=0A= > If I understand the list discussion, I think the above really just=0A= > means:=0A= >=0A= > It is intended that the encapsulation be agnostic to the=0A= > underlying network technology (i.e,. IP, MPLS, etc.) being used=0A= > for transport as well to the specific services being supported.=0A= >=0A= > > 4) Control Plane Mechanisms: A set of documents will be developed to=0A= > > describe requirements and protocols necessary to convey information=0A= > to=0A= > > service function implementation points. Where possible, existing IETF= =0A= > > protocols will be used and extended. All protocol extensions work=0A= > > should be carried out in the working groups responsible for the=0A= > > protocols being modified in coordination with this working group, but= =0A= > > may be done in this working group after agreement with all the=0A= > > relevant WG chairs and responsible ADs.=0A= >=0A= > > 5) Manageability: This document will address the management of=0A= > service=0A= > > function chaining includingrelevant MIBs and YANG data modules, and=0A= > > service function chaining diagnostics.=0A= >=0A= > > Proposed Milestones (all dates TBD):=0A= >=0A= > > Request the IESG for publication of an Informational document=0A= > defining=0A= > > the problem statement and core use cases for Service Function=0A= > Chaining=0A= >=0A= > > Request the IESG for publication of Informational documents defining=0A= > > the architecture for SFC and describing the framework and=0A= > requirements=0A= > > for a generic service function chaining encapsulation protocol.=0A= >=0A= > > Request the IESG for publication of a Standards Track document=0A= > > specifying the generic service function chaining encapsulation=0A= > > protocol.=0A= >=0A= > > Request the IESG for publication of Informational documents=0A= > specifying=0A= > > control plane requirements in support of specific SFC use cases.=0A= >=0A= > > Request the IESG for publication of an Informational document=0A= > defining=0A= > > SFC manageability including diagnostics, and MIB and YANG data models= =0A= > > to IESG=0A= >=0A= > > Request the IESG for publication of Informational applicability=0A= > > documents defining how the protocol elements developed by the WG may=0A= > > be combined with other IETF protocols to satisfy the use cases.=0A= >=0A= >=0A= > Thomas=0A= >=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= _______________________________________________=0A= nsc mailing list=0A= nsc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nsc=0A= From jmh@joelhalpern.com Wed Sep 25 14:14: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 E319821F9F1B for ; Wed, 25 Sep 2013 14:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 FeUtmbmuAkBy for ; Wed, 25 Sep 2013 14:14:26 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 2B54E21F9E2B for ; Wed, 25 Sep 2013 14:14:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D36B51E50CE; Wed, 25 Sep 2013 14:14:24 -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 6E23A1C0843; Wed, 25 Sep 2013 14:14:22 -0700 (PDT) Message-ID: <5243522B.4010104@joelhalpern.com> Date: Wed, 25 Sep 2013 17:14:19 -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: Ian Smith References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <201309252010.r8PKAOFW023454@cichlid.raleigh.ibm.com>, <1D70D757A2C9D54D83B4CBD7625FA80E012A32C0@MISOUT7MSGUSR9I.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A6EF92B@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A6EF92B@SEAEMBX02.olympus.F5Net.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "nsc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 21:14:31 -0000 I understand the sentiment expressed. I am however concerned that if we describe an architecture without specifying sufficiently prescriptive realization then we will not get interoperability. Yours, Joel On 9/25/13 5:07 PM, Ian Smith wrote: >> In my opinion, we should open the door for more than one solution to service chaining. > > I concur. > > There are a number of ways to skin this particular cat, some of which don't require a new on-the-wire protocol because they use protocols that are already defined today in their fullest capacity or in novel combinations. > > It seems to me that the key question that must be answered in the charter is whether or not this is a WG to deliver an architecture (which may or may not include delivering a protocol) or a WG to merely deliver yet-another-overlay-protocol. > > > > > > ________________________________________ > From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of NAPIERALA, MARIA H [mn1921@att.com] > Sent: Wednesday, September 25, 2013 5:01 PM > To: Thomas Narten; Jim Guichard (jguichar) > Cc: nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter > > The group charter's write-up says that: "The Service Function Chaining (SFC) working group will develop new approaches to service delivery ..." (i.e., not one "approach" but "approaches", which means more than one). > > But then is states that a document will be developed such that it "will describe *the(?) single* service-level data plane encapsulation format for conveying the service function chain and the service function path associated with data packets, and for carrying context information between nodes that implement service functions". > > How to do you reconcile those two statements? > In my opinion, we should open the door for more than one solution to service chaining. > > Maria > > > >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Thomas Narten >> Sent: Wednesday, September 25, 2013 4:10 PM >> To: Jim Guichard (jguichar) >> Cc: nsc@ietf.org >> Subject: Re: [nsc] New NSC WG Charter >> >> Jim et al, >> >> Here are some specific suggestions on the charter (this is from the >> version posted Sept. 13). I think they are all editorial, crisping up >> the language used and consistent with the discussion on the list. >> >>> Proposed Service Function Chaining (SFC) WG Charter >> >>> Networks, servers, storage technologies, and applications, have all >>> undergone significant change in recent years with the introduction >>> of virtualization, network overlays, and orchestration. The process >>> of service delivery is changing from the physical insertion of >>> equipment on the path into a mechanism for causing the path or data >>> to transit specific physical or virtual nodes on which the service >>> functions are performed. Services are typically implemented by the >>> ordered combination of a number of service functions that may be >>> implemented at different points within the network. Service delivery >>> is currently both a technical and organisational challenge that >>> involves significant modification to the network configuration. >> >> >> Suggest changing the above as follows: >> >> 1) change sentence: >> >> The process of service delivery is changing from the physical >> insertion of equipment on the path into a mechanism for causing >> the path or data to transit specific physical or virtual nodes on >> which the service functions are performed. >> >> To: >> >> >> Today, a common deployment model has service functions >> physically inserted on the data forwarding path between >> communicating peers. Going forward, however, there is a desire to >> move to a different model, where service functions are not >> required to reside on the default data path and traffic is >> instead steered through services, wherever they are deployed. >> >> >> 2) Reorder the existing text in the pargraph so that teh revised text >> goes at end of first paragraph, i.e., resulting in: >> >> Networks, servers, storage technologies, and applications, have >> all undergone significant change in recent years with the >> introduction of virtualization, network overlays, and >> orchestration. Service delivery is currently both a technical >> and organisational challenge that involves significant >> modification to the network configuration. Services are >> typically implemented by the ordered chaining of a number of >> service functions (e.g., firewalls, load-balancers, etc.) that >> are implemented at different points within the network. Today, a >> common deployment model has service functions physically inserted >> on the data forwarding path between communicating peers. Going >> forward, however, there is a desire to move to a different model, >> where service functions are not required to reside on the default >> data path and traffic is instead steered through services, >> wherever they are deployed. >> >>> For a given service, the abstracted view of the required service >>> functions and the order in which they are to be invoked is called a >> >> s/invoked/applied/ ??? >> >>> Service Function Chain (SFC). Since a given service function may be >>> available on more than one node within a network, a ServiceFunction >>> Chain is instantiated via the selection of specific service function >>> instances and the network nodes on which they are provided, thereby >>> forming a servicetopology: this is called a Service Function Path. >> The >>> service functions may be applied at a specific layer within the >>> network protocol stack (network layer, application layer, etc.). >> >> I think talking about "layers" here is confusing and not really >> needed. SFC doesn't really care about what layer is used. It only >> cares about steering traffic to a service -- what that service does >> with that traffic is the service's own business. Suggest tweaking: >> >> Old: >> >>> The service functions may be applied at a specific layer within the >>> network protocol stack (network layer, application layer, etc.). >> >> better: >> >> Service functions are applied to the traffic flows that are directed >> through them. What the service function actually does to such >> traffic is service-specific and not of concern to SFC. >> >> >>> 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. 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. >> >> The above doesn't actually include the "steering" part. Suggest: >> >> Old: >> >> 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. >> >> New: >> >> 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 service path >> and service path information to nodes that implement service >> functions, as well as mechanisms for steering traffic through >> service functions. >> >>> Specifically, the SFC WG is chartered to deliver the following: >> >>> 1) Problem Statement: This document will provide a summary of the >>> problem space to be addressed by the WG including example high-level >>> use cases. Additionally, the WG will normalize nomenclature and >>> definitions for service function chaining. >> >>> 2) Architecture: This document will provide a description of the >>> architectural building blocks and their relationships including >>> interconnection, placement of capabilities, management, diagnostics, >>> and security models, as well as requirements on the protocol >>> mechanisms. >> >>> 3) Generic Service Function Chaining Encapsulation: A document will >>> describe the single service-level encapsulation protocol for >> conveying >>> communicating information between nodes that implement service >>> functions. >> >> Better: >> >> 3) Generic Service Function Chaining Encapsulation: A document will >> describe the single service-level data plane encapsulation format >> for conveying the service function chain and the service function >> path associated with data packets, and for carrying context >> information >> between nodes that implement service functions. >> >>> It is intended that the encapsulation be agnostic to >>> the network layer at which it is applied and the service that is >> being >>> constructed. That is, the same encapsulation may be used on a service >>> function path realised at the network layer or at any other layer, >> and >>> the same encapsulation willapply for the construction of service >>> function paths regardless of the actual service. >> >> If I understand the list discussion, I think the above really just >> means: >> >> It is intended that the encapsulation be agnostic to the >> underlying network technology (i.e,. IP, MPLS, etc.) being used >> for transport as well to the specific services being supported. >> >>> 4) Control Plane Mechanisms: A set of documents will be developed to >>> describe requirements and protocols necessary to convey information >> to >>> service function implementation points. Where possible, existing IETF >>> protocols will be used and extended. All protocol extensions work >>> should be carried out in the working groups responsible for the >>> protocols being modified in coordination with this working group, but >>> may be done in this working group after agreement with all the >>> relevant WG chairs and responsible ADs. >> >>> 5) Manageability: This document will address the management of >> service >>> function chaining includingrelevant MIBs and YANG data modules, and >>> service function chaining diagnostics. >> >>> Proposed Milestones (all dates TBD): >> >>> Request the IESG for publication of an Informational document >> defining >>> the problem statement and core use cases for Service Function >> Chaining >> >>> Request the IESG for publication of Informational documents defining >>> the architecture for SFC and describing the framework and >> requirements >>> for a generic service function chaining encapsulation protocol. >> >>> Request the IESG for publication of a Standards Track document >>> specifying the generic service function chaining encapsulation >>> protocol. >> >>> Request the IESG for publication of Informational documents >> specifying >>> control plane requirements in support of specific SFC use cases. >> >>> Request the IESG for publication of an Informational document >> defining >>> SFC manageability including diagnostics, and MIB and YANG data models >>> to IESG >> >>> Request the IESG for publication of Informational applicability >>> documents defining how the protocol elements developed by the WG may >>> be combined with other IETF protocols to satisfy the use cases. >> >> >> 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 narten@us.ibm.com Wed Sep 25 14:24: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 2FE2C21F8FDC for ; Wed, 25 Sep 2013 14:24:19 -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 K5k0NHNxCWwb for ; Wed, 25 Sep 2013 14:24:12 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by ietfa.amsl.com (Postfix) with ESMTP id D20C311E8132 for ; Wed, 25 Sep 2013 14:24:11 -0700 (PDT) Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Sep 2013 15:24:10 -0600 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 25 Sep 2013 15:24:08 -0600 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 4AAA219D803E for ; Wed, 25 Sep 2013 15:24:06 -0600 (MDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8PLO7PL337300 for ; Wed, 25 Sep 2013 15:24:07 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r8PLO7GZ006119 for ; Wed, 25 Sep 2013 15:24:07 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-228-93.mts.ibm.com [9.65.228.93]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r8PLO54g006031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 15:24:06 -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 r8PLO5F5001572; Wed, 25 Sep 2013 17:24:05 -0400 Message-Id: <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com> To: "NAPIERALA, MARIA H" In-reply-to: <1D70D757A2C9D54D83B4CBD7625FA80E012A32C0@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <201309252010.r8PKAOFW023454@cichlid.raleigh.ibm.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A32C0@MISOUT7MSGUSR9I.ITServices.sbc.com> Comments: In-reply-to "NAPIERALA, MARIA H" message dated "Wed, 25 Sep 2013 21:01:02 -0000." Date: Wed, 25 Sep 2013 17:24:05 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13092521-1344-0000-0000-000001F054F5 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 21:24:19 -0000 "NAPIERALA, MARIA H" writes: > The group charter's write-up says that: "The Service Function > Chaining (SFC) working group will develop new approaches to service > delivery ..." (i.e., not one "approach" but "approaches", which > means more than one). > But then is states that a document will be developed such that it > "will describe *the(?) single* service-level data plane > encapsulation format for conveying the service function chain and > the service function path associated with data packets, and for > carrying context information between nodes that implement service > functions". > How to do you reconcile those two statements? Note: this inconsistency existed in the earlier charter, I didn't introduce it. :-) I think for the service plane data encapsulation, we should aim for one. I'm understand the concern about writing that into the charter in absolute terms, as I think the WG should have room to discuss and it may be too early to be definitive. But unless there is compelling reason, we should have one encap. (BTW, nothing new here.. this is normal IETF.) That said, I don't see the need for more than one encap. Does anyone think we do? And if so, why? > In my opinion, we should open the door for more than one solution to > service chaining. Ah, "solution to service chaining" (to me) is more than the encap, including the control plane and related stuff. So even if we develop one encap, that doesn't necessarily mean there is only one "solution". So the inconsistency may not be quite as strong as first seems. Suggestion. change: A document will describe the single service-level data plane encapsulation format ... To: A document will describe a service-level data plane encapsulation format ... this is a bit weaker, but still does (implicitely) suggest one encap. or, if folk think this is not good enough, we could add text saying we are aiming for one, and will only do more if ... But personally, I think it would be fine to have the charter say one encap, and if the WG concludes that one encap isn't what is needed, then recharter. We shouldn't look at rechartering as "impossible". We just need to be able to make the case that more than one encap is necessary. If we can do that, I wouldn't think rechartering would be a big deal. Thomas From dmm@1-4-5.net Wed Sep 25 14:32: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 CADAB21F8FB6 for ; Wed, 25 Sep 2013 14:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 0acTExvS8gKK for ; Wed, 25 Sep 2013 14:32:25 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id BD6E621F9371 for ; Wed, 25 Sep 2013 14:32:24 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id x12so189065qcv.36 for ; Wed, 25 Sep 2013 14:32:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/LgZdYRsqbmX59CmuXkKvkO9GU6UbUmLAr7FWRhxHA0=; b=ILfV3j9e7H1q3gOR1vXyQgnN71eyyiSzoAxP0mElywHLq1HX+aE0UUYEj4ebcjCVPR VsoyYi/D68PGpbiYyGc6MRVzvN5FiWge6tp4/fNLQsbSVZuGSNFUClQSe7yJCd0LaxQe LqmhRQO8hkoeH8fN5QtUe9argl2reKW+ug9Gn0FwdTazsgnhFxuf/DGGXqi8Dlu3f8ug ZUnz6oxdT0AWWpzDjSjeeBSpJrSndjHfnnkqFnim4dlP6bqRg8IwEvwQq6IWh/xk/pnf 3j8aTp4L6zF/bZrwvp/FnoXl0hTWxH+j7LWdUbPk/w025oqLQajPITqHoitGeDDxwozu 0iaQ== X-Gm-Message-State: ALoCoQmx5i+AVGyQJNBYKwjh12c8yFKbt2HbzmmNmdTFeOPyA0LOPOXQAi/6hUqJqmdBqg86kEtx MIME-Version: 1.0 X-Received: by 10.224.74.2 with SMTP id s2mr1784237qaj.79.1380144743170; Wed, 25 Sep 2013 14:32:23 -0700 (PDT) Received: by 10.140.80.135 with HTTP; Wed, 25 Sep 2013 14:32:23 -0700 (PDT) X-Originating-IP: [98.234.99.22] In-Reply-To: <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <201309252010.r8PKAOFW023454@cichlid.raleigh.ibm.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A32C0@MISOUT7MSGUSR9I.ITServices.sbc.com> <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com> Date: Wed, 25 Sep 2013 14:32:23 -0700 Message-ID: From: David Meyer To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "NAPIERALA, MARIA H" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 21:32:29 -0000 On Wed, Sep 25, 2013 at 2:24 PM, Thomas Narten wrote: > "NAPIERALA, MARIA H" writes: > >> The group charter's write-up says that: "The Service Function >> Chaining (SFC) working group will develop new approaches to service >> delivery ..." (i.e., not one "approach" but "approaches", which >> means more than one). > >> But then is states that a document will be developed such that it >> "will describe *the(?) single* service-level data plane >> encapsulation format for conveying the service function chain and >> the service function path associated with data packets, and for >> carrying context information between nodes that implement service >> functions". > >> How to do you reconcile those two statements? > > Note: this inconsistency existed in the earlier charter, I didn't > introduce it. :-) > > I think for the service plane data encapsulation, we should aim for > one. I'm understand the concern about writing that into the charter in > absolute terms, as I think the WG should have room to discuss and it > may be too early to be definitive. But unless there is compelling > reason, we should have one encap. (BTW, nothing new here.. this is > normal IETF.) > > That said, I don't see the need for more than one encap. Does anyone > think we do? And if so, why? > >> In my opinion, we should open the door for more than one solution to >> service chaining. > > Ah, "solution to service chaining" (to me) is more than the encap, > including the control plane and related stuff. So even if we develop > one encap, that doesn't necessarily mean there is only one > "solution". So the inconsistency may not be quite as strong as first > seems. > > Suggestion. change: > > A document will describe the single service-level data plane > encapsulation format ... > > To: > > A document will describe a service-level data plane encapsulation > format ... > > this is a bit weaker, but still does (implicitely) suggest one encap. > > or, if folk think this is not good enough, we could add text saying we > are aiming for one, and will only do more if ... > > But personally, I think it would be fine to have the charter say one > encap, and if the WG concludes that one encap isn't what is needed, > then recharter. We shouldn't look at rechartering as "impossible". We > just need to be able to make the case that more than one encap is > necessary. If we can do that, I wouldn't think rechartering would be a > big deal. This seems reasonable, and captures much of the sentiment/aspiration about service-plane encap. --dmm > > Thomas > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From I.Smith@F5.com Wed Sep 25 14:33: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 9B86D21F9DF1 for ; Wed, 25 Sep 2013 14:33: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 Yv3kKlRv-4CG for ; Wed, 25 Sep 2013 14:33:16 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0B521F9B8F for ; Wed, 25 Sep 2013 14:33:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,980,1371081600"; d="scan'208";a="82746497" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 25 Sep 2013 21:33:15 +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; Wed, 25 Sep 2013 14:33:15 -0700 From: Ian Smith To: "Joel M. Halpern" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgD//4sTpIAAeKOA//+K9Gk= Date: Wed, 25 Sep 2013 21:33:14 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A6EF9A8@SEAEMBX02.olympus.F5Net.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <201309252010.r8PKAOFW023454@cichlid.raleigh.ibm.com>, <1D70D757A2C9D54D83B4CBD7625FA80E012A32C0@MISOUT7MSGUSR9I.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A6EF92B@SEAEMBX02.olympus.F5Net.com>, <5243522B.4010104@joelhalpern.com> In-Reply-To: <5243522B.4010104@joelhalpern.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: Thomas Narten , "Jim Guichard \(jguichar\)" , "nsc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 21:33:20 -0000 I'd argue that defining an architecture permits you to include a prescripti= ve realization while defining a protocol doesn't permit you to define the p= rescriptive architectural elements that guarantee interoperability beyond t= he source-destination interpretation of the protocol.=0A= =0A= More to the point, and I guess this turns into a problem statement conversa= tion here, the problem that needs to be solved is only made partially bette= r by forcing everyone with the problem to use the same shim layer/encapsula= tion protocol/overlay networking methodology; interoperability is merely on= e part of the problem.=0A= =0A= The forwarding plane is the least interesting and least complicated part of= this. More critical to business success (and therefore the uptake that ju= stifies the effort) are the orchestration, policy, and reporting aspects be= cause the existing ways of doing this are far less mature and far less effi= cient than dynamic policy routing and options or encapsulation headers, whi= ch is something we've been able to do for decade or more with existing tech= nology (if somewhat painfully) and for which there are numerous rfcs to sho= w you the way already published. =0A= =0A= =0A= =0A= ________________________________________=0A= From: Joel M. Halpern [jmh@joelhalpern.com]=0A= Sent: Wednesday, September 25, 2013 5:14 PM=0A= To: Ian Smith=0A= Cc: NAPIERALA, MARIA H; Thomas Narten; Jim Guichard (jguichar); nsc@ietf.or= g=0A= Subject: Re: [nsc] New NSC WG Charter=0A= =0A= I understand the sentiment expressed.=0A= =0A= I am however concerned that if we describe an architecture without=0A= specifying sufficiently prescriptive realization then we will not get=0A= interoperability.=0A= =0A= Yours,=0A= Joel=0A= =0A= On 9/25/13 5:07 PM, Ian Smith wrote:=0A= >> In my opinion, we should open the door for more than one solution to ser= vice chaining.=0A= >=0A= > I concur.=0A= >=0A= > There are a number of ways to skin this particular cat, some of which don= 't require a new on-the-wire protocol because they use protocols that are a= lready defined today in their fullest capacity or in novel combinations.=0A= >=0A= > It seems to me that the key question that must be answered in the charter= is whether or not this is a WG to deliver an architecture (which may or ma= y not include delivering a protocol) or a WG to merely deliver yet-another-= overlay-protocol.=0A= >=0A= >=0A= >=0A= >=0A= >=0A= > ________________________________________=0A= > From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of NAPIERALA,= MARIA H [mn1921@att.com]=0A= > Sent: Wednesday, September 25, 2013 5:01 PM=0A= > To: Thomas Narten; Jim Guichard (jguichar)=0A= > Cc: nsc@ietf.org=0A= > Subject: Re: [nsc] New NSC WG Charter=0A= >=0A= > The group charter's write-up says that: "The Service Function Chaining (S= FC) working group will develop new approaches to service delivery ..." (i.e= ., not one "approach" but "approaches", which means more than one).=0A= >=0A= > But then is states that a document will be developed such that it "will = describe *the(?) single* service-level data plane encapsulation format for = conveying the service function chain and the service function path associat= ed with data packets, and for carrying context information between nodes th= at implement service functions".=0A= >=0A= > How to do you reconcile those two statements?=0A= > In my opinion, we should open the door for more than one solution to serv= ice chaining.=0A= >=0A= > Maria=0A= >=0A= >=0A= >=0A= >> -----Original Message-----=0A= >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=0A= >> Thomas Narten=0A= >> Sent: Wednesday, September 25, 2013 4:10 PM=0A= >> To: Jim Guichard (jguichar)=0A= >> Cc: nsc@ietf.org=0A= >> Subject: Re: [nsc] New NSC WG Charter=0A= >>=0A= >> Jim et al,=0A= >>=0A= >> Here are some specific suggestions on the charter (this is from the=0A= >> version posted Sept. 13). I think they are all editorial, crisping up=0A= >> the language used and consistent with the discussion on the list.=0A= >>=0A= >>> Proposed Service Function Chaining (SFC) WG Charter=0A= >>=0A= >>> Networks, servers, storage technologies, and applications, have all=0A= >>> undergone significant change in recent years with the introduction=0A= >>> of virtualization, network overlays, and orchestration. The process=0A= >>> of service delivery is changing from the physical insertion of=0A= >>> equipment on the path into a mechanism for causing the path or data=0A= >>> to transit specific physical or virtual nodes on which the service=0A= >>> functions are performed. Services are typically implemented by the=0A= >>> ordered combination of a number of service functions that may be=0A= >>> implemented at different points within the network. Service delivery=0A= >>> is currently both a technical and organisational challenge that=0A= >>> involves significant modification to the network configuration.=0A= >>=0A= >>=0A= >> Suggest changing the above as follows:=0A= >>=0A= >> 1) change sentence:=0A= >>=0A= >> The process of service delivery is changing from the physical=0A= >> insertion of equipment on the path into a mechanism for causing=0A= >> the path or data to transit specific physical or virtual nodes on= =0A= >> which the service functions are performed.=0A= >>=0A= >> To:=0A= >>=0A= >>=0A= >> Today, a common deployment model has service functions=0A= >> physically inserted on the data forwarding path between=0A= >> communicating peers. Going forward, however, there is a desire to= =0A= >> move to a different model, where service functions are not=0A= >> required to reside on the default data path and traffic is=0A= >> instead steered through services, wherever they are deployed.=0A= >>=0A= >>=0A= >> 2) Reorder the existing text in the pargraph so that teh revised text=0A= >> goes at end of first paragraph, i.e., resulting in:=0A= >>=0A= >> Networks, servers, storage technologies, and applications, have=0A= >> all undergone significant change in recent years with the=0A= >> introduction of virtualization, network overlays, and=0A= >> orchestration. Service delivery is currently both a technical=0A= >> and organisational challenge that involves significant=0A= >> modification to the network configuration. Services are=0A= >> typically implemented by the ordered chaining of a number of=0A= >> service functions (e.g., firewalls, load-balancers, etc.) that=0A= >> are implemented at different points within the network. Today, a= =0A= >> common deployment model has service functions physically inserted= =0A= >> on the data forwarding path between communicating peers. Going=0A= >> forward, however, there is a desire to move to a different model,= =0A= >> where service functions are not required to reside on the default= =0A= >> data path and traffic is instead steered through services,=0A= >> wherever they are deployed.=0A= >>=0A= >>> For a given service, the abstracted view of the required service=0A= >>> functions and the order in which they are to be invoked is called a=0A= >>=0A= >> s/invoked/applied/ ???=0A= >>=0A= >>> Service Function Chain (SFC). Since a given service function may be=0A= >>> available on more than one node within a network, a ServiceFunction=0A= >>> Chain is instantiated via the selection of specific service function=0A= >>> instances and the network nodes on which they are provided, thereby=0A= >>> forming a servicetopology: this is called a Service Function Path.=0A= >> The=0A= >>> service functions may be applied at a specific layer within the=0A= >>> network protocol stack (network layer, application layer, etc.).=0A= >>=0A= >> I think talking about "layers" here is confusing and not really=0A= >> needed. SFC doesn't really care about what layer is used. It only=0A= >> cares about steering traffic to a service -- what that service does=0A= >> with that traffic is the service's own business. Suggest tweaking:=0A= >>=0A= >> Old:=0A= >>=0A= >>> The service functions may be applied at a specific layer within the= =0A= >>> network protocol stack (network layer, application layer, etc.).=0A= >>=0A= >> better:=0A= >>=0A= >> Service functions are applied to the traffic flows that are directed= =0A= >> through them. What the service function actually does to such=0A= >> traffic is service-specific and not of concern to SFC.=0A= >>=0A= >>=0A= >>> The Service Function Chaining (SFC) working group will develop new=0A= >>> approaches to service delivery and deployment, by providing a=0A= >>> framework for service function chaining and the necessary protocols=0A= >> or=0A= >>> protocol extensions to convey the service path and for communication=0A= >>> between nodes that implement service functions. The working group=0A= >>> will also examine what information needs to be gathered from the=0A= >>> network and service functions in support of service function chaining= =0A= >>> and how that information may be made available to nodes that=0A= >> implement=0A= >>> the service functions.=0A= >>=0A= >> The above doesn't actually include the "steering" part. Suggest:=0A= >>=0A= >> Old:=0A= >>=0A= >> The Service Function Chaining (SFC) working group will develop new= =0A= >> approaches to service delivery and deployment, by providing a=0A= >> framework for service function chaining and the necessary=0A= >> protocols or protocol extensions to convey the service path and=0A= >> for communication between nodes that implement service functions.= =0A= >>=0A= >> New:=0A= >>=0A= >> The Service Function Chaining (SFC) working group will develop new= =0A= >> approaches to service delivery and deployment. It will produce a=0A= >> framework for service function chaining that includes the=0A= >> necessary protocols or protocol extensions to convey service path= =0A= >> and service path information to nodes that implement service=0A= >> functions, as well as mechanisms for steering traffic through=0A= >> service functions.=0A= >>=0A= >>> Specifically, the SFC WG is chartered to deliver the following:=0A= >>=0A= >>> 1) Problem Statement: This document will provide a summary of the=0A= >>> problem space to be addressed by the WG including example high-level=0A= >>> use cases. Additionally, the WG will normalize nomenclature and=0A= >>> definitions for service function chaining.=0A= >>=0A= >>> 2) Architecture: This document will provide a description of the=0A= >>> architectural building blocks and their relationships including=0A= >>> interconnection, placement of capabilities, management, diagnostics,=0A= >>> and security models, as well as requirements on the protocol=0A= >>> mechanisms.=0A= >>=0A= >>> 3) Generic Service Function Chaining Encapsulation: A document will=0A= >>> describe the single service-level encapsulation protocol for=0A= >> conveying=0A= >>> communicating information between nodes that implement service=0A= >>> functions.=0A= >>=0A= >> Better:=0A= >>=0A= >> 3) Generic Service Function Chaining Encapsulation: A document will=0A= >> describe the single service-level data plane encapsulation format=0A= >> for conveying the service function chain and the service function=0A= >> path associated with data packets, and for carrying context=0A= >> information=0A= >> between nodes that implement service functions.=0A= >>=0A= >>> It is intended that the encapsulation be agnostic to=0A= >>> the network layer at which it is applied and the service that is=0A= >> being=0A= >>> constructed. That is, the same encapsulation may be used on a service= =0A= >>> function path realised at the network layer or at any other layer,=0A= >> and=0A= >>> the same encapsulation willapply for the construction of service=0A= >>> function paths regardless of the actual service.=0A= >>=0A= >> If I understand the list discussion, I think the above really just=0A= >> means:=0A= >>=0A= >> It is intended that the encapsulation be agnostic to the=0A= >> underlying network technology (i.e,. IP, MPLS, etc.) being used=0A= >> for transport as well to the specific services being supported.=0A= >>=0A= >>> 4) Control Plane Mechanisms: A set of documents will be developed to=0A= >>> describe requirements and protocols necessary to convey information=0A= >> to=0A= >>> service function implementation points. Where possible, existing IETF= =0A= >>> protocols will be used and extended. All protocol extensions work=0A= >>> should be carried out in the working groups responsible for the=0A= >>> protocols being modified in coordination with this working group, but= =0A= >>> may be done in this working group after agreement with all the=0A= >>> relevant WG chairs and responsible ADs.=0A= >>=0A= >>> 5) Manageability: This document will address the management of=0A= >> service=0A= >>> function chaining includingrelevant MIBs and YANG data modules, and=0A= >>> service function chaining diagnostics.=0A= >>=0A= >>> Proposed Milestones (all dates TBD):=0A= >>=0A= >>> Request the IESG for publication of an Informational document=0A= >> defining=0A= >>> the problem statement and core use cases for Service Function=0A= >> Chaining=0A= >>=0A= >>> Request the IESG for publication of Informational documents defining=0A= >>> the architecture for SFC and describing the framework and=0A= >> requirements=0A= >>> for a generic service function chaining encapsulation protocol.=0A= >>=0A= >>> Request the IESG for publication of a Standards Track document=0A= >>> specifying the generic service function chaining encapsulation=0A= >>> protocol.=0A= >>=0A= >>> Request the IESG for publication of Informational documents=0A= >> specifying=0A= >>> control plane requirements in support of specific SFC use cases.=0A= >>=0A= >>> Request the IESG for publication of an Informational document=0A= >> defining=0A= >>> SFC manageability including diagnostics, and MIB and YANG data models= =0A= >>> to IESG=0A= >>=0A= >>> Request the IESG for publication of Informational applicability=0A= >>> documents defining how the protocol elements developed by the WG may=0A= >>> be combined with other IETF protocols to satisfy the use cases.=0A= >>=0A= >>=0A= >> Thomas=0A= >>=0A= >> _______________________________________________=0A= >> nsc mailing list=0A= >> nsc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/nsc=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= >=0A= From jguichar@cisco.com Wed Sep 25 14:39: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 3630521F9DF1 for ; Wed, 25 Sep 2013 14:39:44 -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=[AWL=0.000, 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 1Sfg8yVenuOq for ; Wed, 25 Sep 2013 14:39:38 -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 5CD7121F9E02 for ; Wed, 25 Sep 2013 14:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3184; q=dns/txt; s=iport; t=1380145177; x=1381354777; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Mwe+XMeaumqUTx2OYn/yN5Vgj4ERNK4eprYenc2FiOY=; b=Q7Y32WeHQGT/u7v285K8Hhj/Tz/8n2dR10Nr4qWucCqDEzrnHpR6wcjE UCfMaB4WM0lmNLPI4P3EZTjEEzzgta/D4uCbJJQKmnFKXOeXZQEZ4bgYJ dQrjQHm6S0CgRkRSWZtj+Ef4Q70RHZ/fDVciVqSQCPLydW8OMRQvNbX8M E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAMBXQ1KtJV2b/2dsb2JhbABbgweBCsBUgSIWdIInAQQ6PxIBCCIUQiUCBA4FCBOHa7xGjyAxB4MdgQADqXODJIIq X-IronPort-AV: E=Sophos;i="4.90,980,1371081600"; d="scan'208";a="264461296" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 25 Sep 2013 21:39:32 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8PLdWUg003978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 21:39:32 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 16:39:32 -0500 From: "Jim Guichard (jguichar)" To: Thomas Narten , "NAPIERALA, MARIA H" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXSUUAgAAOJgCAAAZxgP//wT+A Date: Wed, 25 Sep 2013 21:39:31 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6A0015@xmb-rcd-x01.cisco.com> In-Reply-To: <201309252124.r8PLO5F5001572@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.181] 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 NSC 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: Wed, 25 Sep 2013 21:39:44 -0000 Thomas et al, Let's be clear about what we mean by "service-level data plane encapsulation" as once the intent is clearly understood I see no issue with the way the current charter reads. Work item #3 states that the service-level data plane encapsulation is used "for conveying the service function chain and the service function path associated with data packets, and for carrying context information between nodes that implement service functions". This is *different* than specifying a solution that uses existing transport encapsulations for forwarding traffic through a set of service functions (for example a solution that uses an MPLS label stack). On 9/25/13 5:24 PM, "Thomas Narten" wrote: >"NAPIERALA, MARIA H" writes: > >> The group charter's write-up says that: "The Service Function >> Chaining (SFC) working group will develop new approaches to service >> delivery ..." (i.e., not one "approach" but "approaches", which >> means more than one). > >> But then is states that a document will be developed such that it >> "will describe *the(?) single* service-level data plane >> encapsulation format for conveying the service function chain and >> the service function path associated with data packets, and for >> carrying context information between nodes that implement service >> functions". > >> How to do you reconcile those two statements? > >Note: this inconsistency existed in the earlier charter, I didn't >introduce it. :-) > >I think for the service plane data encapsulation, we should aim for >one. I'm understand the concern about writing that into the charter in >absolute terms, as I think the WG should have room to discuss and it >may be too early to be definitive. But unless there is compelling >reason, we should have one encap. (BTW, nothing new here.. this is >normal IETF.) > >That said, I don't see the need for more than one encap. Does anyone >think we do? And if so, why? > >> In my opinion, we should open the door for more than one solution to >> service chaining. > >Ah, "solution to service chaining" (to me) is more than the encap, >including the control plane and related stuff. So even if we develop >one encap, that doesn't necessarily mean there is only one >"solution". So the inconsistency may not be quite as strong as first >seems. > >Suggestion. change: > > A document will describe the single service-level data plane > encapsulation format ... > >To: > > A document will describe a service-level data plane encapsulation > format ... > >this is a bit weaker, but still does (implicitely) suggest one encap. > >or, if folk think this is not good enough, we could add text saying we >are aiming for one, and will only do more if ... > >But personally, I think it would be fine to have the charter say one >encap, and if the WG concludes that one encap isn't what is needed, >then recharter. We shouldn't look at rechartering as "impossible". We >just need to be able to make the case that more than one encap is >necessary. If we can do that, I wouldn't think rechartering would be a >big deal. > >Thomas > From mn1921@att.com Wed Sep 25 14:49: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 7F68C21F9E11 for ; Wed, 25 Sep 2013 14:49:26 -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 MsR1IKzu+qyv for ; Wed, 25 Sep 2013 14:49:14 -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 4418421F97C7 for ; Wed, 25 Sep 2013 14:49:14 -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 a5a53425.71d72940.8875057.00-556.24418909.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 25 Sep 2013 21:49:14 +0000 (UTC) X-MXL-Hash: 52435a5a04abd428-c3ce4dec9a43b9a657067686cf172e8884333672 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 95a53425.0.8875050.00-139.24418882.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 25 Sep 2013 21:49:13 +0000 (UTC) X-MXL-Hash: 52435a593729b303-7fd23241cc67bfc309126b57451b25d61261d142 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 r8PLnCio015477; Wed, 25 Sep 2013 17:49:13 -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 r8PLn2te015374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 17:49:10 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 25 Sep 2013 21:48:46 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.03.0158.001; Wed, 25 Sep 2013 17:48:46 -0400 From: "NAPIERALA, MARIA H" To: Thomas Narten Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXOIIA///I2MCAAEu+gP//wPdw Date: Wed, 25 Sep 2013 21:48:46 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012A3351@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <201309252010.r8PKAOFW023454@cichlid.raleigh.ibm.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A32C0@MISOUT7MSGUSR9I.ITServices.sbc.com> <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com> In-Reply-To: <201309252124.r8PLO5F5001572@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=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=-s3I2kwCOWQA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=FFZ-zzI3G] X-AnalysisOut: [zMA:10 a=VnNF1IyMAAAA:8 a=48vgC7mUAAAA:8 a=eofk_CvhDKd31Cu] X-AnalysisOut: [llhcA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA] X-AnalysisOut: [:10] Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 21:49:26 -0000 I believe the NSC architecture should not preclude the service chain path/t= opology from being realized with some existing (and standard ;-) network ov= erlay (=3Dvirtual network) technique. But if the decision is made that it d= oes then this should be clearly stated in the charter. What must be common to the service chain path solutions is, IMO, the method= for carrying the metadata/context information. Maria > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Wednesday, September 25, 2013 5:24 PM > To: NAPIERALA, MARIA H > Cc: Jim Guichard (jguichar); nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter >=20 > "NAPIERALA, MARIA H" writes: >=20 > > The group charter's write-up says that: "The Service Function > > Chaining (SFC) working group will develop new approaches to service > > delivery ..." (i.e., not one "approach" but "approaches", which > > means more than one). >=20 > > But then is states that a document will be developed such that it > > "will describe *the(?) single* service-level data plane > > encapsulation format for conveying the service function chain and > > the service function path associated with data packets, and for > > carrying context information between nodes that implement service > > functions". >=20 > > How to do you reconcile those two statements? >=20 > Note: this inconsistency existed in the earlier charter, I didn't > introduce it. :-) >=20 > I think for the service plane data encapsulation, we should aim for > one. I'm understand the concern about writing that into the charter in > absolute terms, as I think the WG should have room to discuss and it > may be too early to be definitive. But unless there is compelling > reason, we should have one encap. (BTW, nothing new here.. this is > normal IETF.) >=20 > That said, I don't see the need for more than one encap. Does anyone > think we do? And if so, why? >=20 > > In my opinion, we should open the door for more than one solution to > > service chaining. >=20 > Ah, "solution to service chaining" (to me) is more than the encap, > including the control plane and related stuff. So even if we develop > one encap, that doesn't necessarily mean there is only one > "solution". So the inconsistency may not be quite as strong as first > seems. >=20 > Suggestion. change: >=20 > A document will describe the single service-level data plane > encapsulation format ... >=20 > To: >=20 > A document will describe a service-level data plane encapsulation > format ... >=20 > this is a bit weaker, but still does (implicitely) suggest one encap. >=20 > or, if folk think this is not good enough, we could add text saying we > are aiming for one, and will only do more if ... >=20 > But personally, I think it would be fine to have the charter say one > encap, and if the WG concludes that one encap isn't what is needed, > then recharter. We shouldn't look at rechartering as "impossible". We > just need to be able to make the case that more than one encap is > necessary. If we can do that, I wouldn't think rechartering would be a > big deal. >=20 > Thomas From I.Smith@F5.com Wed Sep 25 14:54:34 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 A037121F8E97 for ; Wed, 25 Sep 2013 14:54:34 -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 yYzA4k7Vmw9q for ; Wed, 25 Sep 2013 14:54:30 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 07EB121F960D for ; Wed, 25 Sep 2013 14:53:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,980,1371081600"; d="scan'208";a="82748154" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 25 Sep 2013 21:53:53 +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; Wed, 25 Sep 2013 14:53:52 -0700 From: Ian Smith To: "Jim Guichard (jguichar)" , Thomas Narten , "NAPIERALA, MARIA H" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABFCA//+Ms0w= Date: Wed, 25 Sep 2013 21:53:51 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A6EFA09@SEAEMBX02.olympus.F5Net.com> References: <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com>, <68B171751455884590F8E38E96416F363F6A0015@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6A0015@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: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 21:54:34 -0000 If that is the intent, then at some point someone needs to explain, probabl= y prior to Vancouver, in detail what functionality not already existing in = standardized overlay networking protocols, encapsulation protocols, and/or = options headers is required to solve the problem statement being addressed = (which also appears to be lacking consensus).=0A= =0A= =0A= =0A= =0A= ________________________________________=0A= From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim Guichard= (jguichar) [jguichar@cisco.com]=0A= Sent: Wednesday, September 25, 2013 5:39 PM=0A= To: Thomas Narten; NAPIERALA, MARIA H=0A= Cc: nsc@ietf.org=0A= Subject: Re: [nsc] New NSC WG Charter=0A= =0A= Thomas et al,=0A= =0A= Let's be clear about what we mean by "service-level data plane=0A= encapsulation" as once the intent is clearly understood I see no issue=0A= with the way the current charter reads. Work item #3 states that the=0A= service-level data plane encapsulation is used "for conveying the service= =0A= function chain and the service function path associated with data packets,= =0A= and for carrying context information between nodes that implement service= =0A= functions". This is *different* than specifying a solution that uses=0A= existing transport encapsulations for forwarding traffic through a set of= =0A= service functions (for example a solution that uses an MPLS label stack).= =0A= =0A= On 9/25/13 5:24 PM, "Thomas Narten" wrote:=0A= =0A= >"NAPIERALA, MARIA H" writes:=0A= >=0A= >> The group charter's write-up says that: "The Service Function=0A= >> Chaining (SFC) working group will develop new approaches to service=0A= >> delivery ..." (i.e., not one "approach" but "approaches", which=0A= >> means more than one).=0A= >=0A= >> But then is states that a document will be developed such that it=0A= >> "will describe *the(?) single* service-level data plane=0A= >> encapsulation format for conveying the service function chain and=0A= >> the service function path associated with data packets, and for=0A= >> carrying context information between nodes that implement service=0A= >> functions".=0A= >=0A= >> How to do you reconcile those two statements?=0A= >=0A= >Note: this inconsistency existed in the earlier charter, I didn't=0A= >introduce it. :-)=0A= >=0A= >I think for the service plane data encapsulation, we should aim for=0A= >one. I'm understand the concern about writing that into the charter in=0A= >absolute terms, as I think the WG should have room to discuss and it=0A= >may be too early to be definitive. But unless there is compelling=0A= >reason, we should have one encap. (BTW, nothing new here.. this is=0A= >normal IETF.)=0A= >=0A= >That said, I don't see the need for more than one encap. Does anyone=0A= >think we do? And if so, why?=0A= >=0A= >> In my opinion, we should open the door for more than one solution to=0A= >> service chaining.=0A= >=0A= >Ah, "solution to service chaining" (to me) is more than the encap,=0A= >including the control plane and related stuff. So even if we develop=0A= >one encap, that doesn't necessarily mean there is only one=0A= >"solution". So the inconsistency may not be quite as strong as first=0A= >seems.=0A= >=0A= >Suggestion. change:=0A= >=0A= > A document will describe the single service-level data plane=0A= > encapsulation format ...=0A= >=0A= >To:=0A= >=0A= > A document will describe a service-level data plane encapsulation=0A= > format ...=0A= >=0A= >this is a bit weaker, but still does (implicitely) suggest one encap.=0A= >=0A= >or, if folk think this is not good enough, we could add text saying we=0A= >are aiming for one, and will only do more if ...=0A= >=0A= >But personally, I think it would be fine to have the charter say one=0A= >encap, and if the WG concludes that one encap isn't what is needed,=0A= >then recharter. We shouldn't look at rechartering as "impossible". We=0A= >just need to be able to make the case that more than one encap is=0A= >necessary. If we can do that, I wouldn't think rechartering would be a=0A= >big deal.=0A= >=0A= >Thomas=0A= >=0A= =0A= _______________________________________________=0A= nsc mailing list=0A= nsc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nsc=0A= From jguichar@cisco.com Wed Sep 25 14:57:41 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 143BF21F9A05 for ; Wed, 25 Sep 2013 14:57:41 -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=[AWL=0.000, 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 gh9A0fuO0HCu for ; Wed, 25 Sep 2013 14:57:36 -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 EFF6C21F84B6 for ; Wed, 25 Sep 2013 14:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4465; q=dns/txt; s=iport; t=1380146247; x=1381355847; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pooJqX+hwpMuYrGiaBDx1UUsdFhP/nI0g6mU3CInFCA=; b=bbR6LgENk3gGEK1sm8MB7RdmdjAAcMhissXdMCgFBWYpLhLysAPrOof/ E3b4MGU2d+0FgW83q3kh2yGDU4d3mEpu4Pg0FT5NDXNh4wYMtV0/IYG2S qvsyNLVjE4sgEA6U+5IAHcoWTJVHZ498rv4a4JrzPolA/dXOoDoRMy7u4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAMZbQ1KtJV2Z/2dsb2JhbABbgwc4wSaBIhZ0giUBAQEDAQEBATc0CwULAgEIDgMEAQEBHhAnCx0IAgQOBRuHZQYMvD4Ejx4zBwKDG4EAA5d8kXeDJA X-IronPort-AV: E=Sophos;i="4.90,981,1371081600"; d="scan'208";a="264502305" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 25 Sep 2013 21:57:03 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8PLv3EU028779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 21:57:03 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 16:57:01 -0500 From: "Jim Guichard (jguichar)" To: Ian Smith Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXSUUAgAAOJgCAAAZxgP//wT+AgABHEoD//60RLA== Date: Wed, 25 Sep 2013 21:57:01 +0000 Message-ID: <76A38106-A99E-41C2-B133-DA13BC3F76E4@cisco.com> References: <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com>, <68B171751455884590F8E38E96416F363F6A0015@xmb-rcd-x01.cisco.com>, <419417C345CA5F48BF45F0A23955A0634A6EFA09@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A6EFA09@SEAEMBX02.olympus.F5Net.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: Thomas Narten , "nsc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 21:57:41 -0000 With all due respect Ian I think several people have on multiple occasions = on this alias as well as within several of the existing IDs associated with= the SFC (to be) WG. Sent from my iPhone > On Sep 25, 2013, at 5:54 PM, "Ian Smith" wrote: >=20 > If that is the intent, then at some point someone needs to explain, proba= bly prior to Vancouver, in detail what functionality not already existing i= n standardized overlay networking protocols, encapsulation protocols, and/o= r options headers is required to solve the problem statement being addresse= d (which also appears to be lacking consensus). >=20 >=20 >=20 >=20 > ________________________________________ > From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim Guicha= rd (jguichar) [jguichar@cisco.com] > Sent: Wednesday, September 25, 2013 5:39 PM > To: Thomas Narten; NAPIERALA, MARIA H > Cc: nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter >=20 > Thomas et al, >=20 > Let's be clear about what we mean by "service-level data plane > encapsulation" as once the intent is clearly understood I see no issue > with the way the current charter reads. Work item #3 states that the > service-level data plane encapsulation is used "for conveying the service > function chain and the service function path associated with data packets= , > and for carrying context information between nodes that implement service > functions". This is *different* than specifying a solution that uses > existing transport encapsulations for forwarding traffic through a set of > service functions (for example a solution that uses an MPLS label stack). >=20 >> On 9/25/13 5:24 PM, "Thomas Narten" wrote: >>=20 >> "NAPIERALA, MARIA H" writes: >>=20 >>> The group charter's write-up says that: "The Service Function >>> Chaining (SFC) working group will develop new approaches to service >>> delivery ..." (i.e., not one "approach" but "approaches", which >>> means more than one). >>=20 >>> But then is states that a document will be developed such that it >>> "will describe *the(?) single* service-level data plane >>> encapsulation format for conveying the service function chain and >>> the service function path associated with data packets, and for >>> carrying context information between nodes that implement service >>> functions". >>=20 >>> How to do you reconcile those two statements? >>=20 >> Note: this inconsistency existed in the earlier charter, I didn't >> introduce it. :-) >>=20 >> I think for the service plane data encapsulation, we should aim for >> one. I'm understand the concern about writing that into the charter in >> absolute terms, as I think the WG should have room to discuss and it >> may be too early to be definitive. But unless there is compelling >> reason, we should have one encap. (BTW, nothing new here.. this is >> normal IETF.) >>=20 >> That said, I don't see the need for more than one encap. Does anyone >> think we do? And if so, why? >>=20 >>> In my opinion, we should open the door for more than one solution to >>> service chaining. >>=20 >> Ah, "solution to service chaining" (to me) is more than the encap, >> including the control plane and related stuff. So even if we develop >> one encap, that doesn't necessarily mean there is only one >> "solution". So the inconsistency may not be quite as strong as first >> seems. >>=20 >> Suggestion. change: >>=20 >> A document will describe the single service-level data plane >> encapsulation format ... >>=20 >> To: >>=20 >> A document will describe a service-level data plane encapsulation >> format ... >>=20 >> this is a bit weaker, but still does (implicitely) suggest one encap. >>=20 >> or, if folk think this is not good enough, we could add text saying we >> are aiming for one, and will only do more if ... >>=20 >> But personally, I think it would be fine to have the charter say one >> encap, and if the WG concludes that one encap isn't what is needed, >> then recharter. We shouldn't look at rechartering as "impossible". We >> just need to be able to make the case that more than one encap is >> necessary. If we can do that, I wouldn't think rechartering would be a >> big deal. >>=20 >> Thomas >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From I.Smith@F5.com Wed Sep 25 15: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 AB5F321F9E11 for ; Wed, 25 Sep 2013 15:17:52 -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 86a-OJgmyYLW for ; Wed, 25 Sep 2013 15:17:48 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5207421F9E02 for ; Wed, 25 Sep 2013 15:17:47 -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=1380147468; x=1411683468; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ywqPmsMzs+SLyA3uUkjb4bqk3ZSA3F9wsA8LSCLDg8M=; b=fyYMlDeCUsOJNLGLrbpK72v6F5I+1NQGyDKcdDTENZ0NamvwXtpsZMXy gmDGn8TER+oiQZ8IXGpdiOIQ8EjDnSr8gEpT2lPZfwyQtMOEdsw85y2I4 nDtj96CFRqmsOR2hv1eE4q6S2eooMdSpdZ3ZZE4Y6m5qZaL8nZfVXrEaH k=; X-IronPort-AV: E=Sophos;i="4.90,981,1371081600"; d="scan'208";a="81980249" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 25 Sep 2013 22:17:37 +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; Wed, 25 Sep 2013 15:17:36 -0700 From: Ian Smith To: "Jim Guichard (jguichar)" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABFCA//+Ms0yAAHgwgP//iuM+ Date: Wed, 25 Sep 2013 22:17:35 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A6EFA72@SEAEMBX02.olympus.F5Net.com> References: <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com>, <68B171751455884590F8E38E96416F363F6A0015@xmb-rcd-x01.cisco.com>, <419417C345CA5F48BF45F0A23955A0634A6EFA09@SEAEMBX02.olympus.F5Net.com>, <76A38106-A99E-41C2-B133-DA13BC3F76E4@cisco.com> In-Reply-To: <76A38106-A99E-41C2-B133-DA13BC3F76E4@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: Thomas Narten , "nsc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 22:17:52 -0000 I'm not trying to be confrontational or an anchor, but I was at the BoF in = Berlin and I've read the three drafts that are getting the most traffic on = list - draft-quinn-nsc-problem-statement-02; draft-boucadair-network-functi= on-chaining-03; draft-boucadair-chaining-requirements-01 - and my reading o= f them, and my experience building dozens if not hundreds of solutions that= look an awful lot like what is being described, leave me wondering why a n= ew protocol is required when there are so many options already out there. = =0A= =0A= If what you need to do is identify an information stream or network flow, s= teer it into a particular set of ordered hops and convey some information i= n-band that a particular hop or hops will use along the way for on-node pro= cessing we have the protocols for that already and they are deployed, so I'= m presuming that the desire is to do more, but what "more" is doesn't seem = to be well communicated in the BoF presentations or the Charter or the thre= e drafts above. =0A= =0A= I know that using the existing protocols to do this is not as easy as it co= uld be, but those aren't problems with the protocol as much as they are pro= blems with the implementations, and they tend to be engulfed by the corolla= ry presumption that service chains will be used in Programmable, Elastic, V= irtualized infrastructure and that will force the complexity and manual nat= ure of their configuration to become automated and abstracted.=0A= =0A= =0A= ________________________________________=0A= From: Jim Guichard (jguichar) [jguichar@cisco.com]=0A= Sent: Wednesday, September 25, 2013 5:57 PM=0A= To: Ian Smith=0A= Cc: Thomas Narten; NAPIERALA, MARIA H; nsc@ietf.org=0A= Subject: Re: [nsc] New NSC WG Charter=0A= =0A= With all due respect Ian I think several people have on multiple occasions = on this alias as well as within several of the existing IDs associated with= the SFC (to be) WG.=0A= =0A= Sent from my iPhone=0A= =0A= > On Sep 25, 2013, at 5:54 PM, "Ian Smith" wrote:=0A= >=0A= > If that is the intent, then at some point someone needs to explain, proba= bly prior to Vancouver, in detail what functionality not already existing i= n standardized overlay networking protocols, encapsulation protocols, and/o= r options headers is required to solve the problem statement being addresse= d (which also appears to be lacking consensus).=0A= >=0A= >=0A= >=0A= >=0A= > ________________________________________=0A= > From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim Guicha= rd (jguichar) [jguichar@cisco.com]=0A= > Sent: Wednesday, September 25, 2013 5:39 PM=0A= > To: Thomas Narten; NAPIERALA, MARIA H=0A= > Cc: nsc@ietf.org=0A= > Subject: Re: [nsc] New NSC WG Charter=0A= >=0A= > Thomas et al,=0A= >=0A= > Let's be clear about what we mean by "service-level data plane=0A= > encapsulation" as once the intent is clearly understood I see no issue=0A= > with the way the current charter reads. Work item #3 states that the=0A= > service-level data plane encapsulation is used "for conveying the service= =0A= > function chain and the service function path associated with data packets= ,=0A= > and for carrying context information between nodes that implement service= =0A= > functions". This is *different* than specifying a solution that uses=0A= > existing transport encapsulations for forwarding traffic through a set of= =0A= > service functions (for example a solution that uses an MPLS label stack).= =0A= >=0A= >> On 9/25/13 5:24 PM, "Thomas Narten" wrote:=0A= >>=0A= >> "NAPIERALA, MARIA H" writes:=0A= >>=0A= >>> The group charter's write-up says that: "The Service Function=0A= >>> Chaining (SFC) working group will develop new approaches to service=0A= >>> delivery ..." (i.e., not one "approach" but "approaches", which=0A= >>> means more than one).=0A= >>=0A= >>> But then is states that a document will be developed such that it=0A= >>> "will describe *the(?) single* service-level data plane=0A= >>> encapsulation format for conveying the service function chain and=0A= >>> the service function path associated with data packets, and for=0A= >>> carrying context information between nodes that implement service=0A= >>> functions".=0A= >>=0A= >>> How to do you reconcile those two statements?=0A= >>=0A= >> Note: this inconsistency existed in the earlier charter, I didn't=0A= >> introduce it. :-)=0A= >>=0A= >> I think for the service plane data encapsulation, we should aim for=0A= >> one. I'm understand the concern about writing that into the charter in= =0A= >> absolute terms, as I think the WG should have room to discuss and it=0A= >> may be too early to be definitive. But unless there is compelling=0A= >> reason, we should have one encap. (BTW, nothing new here.. this is=0A= >> normal IETF.)=0A= >>=0A= >> That said, I don't see the need for more than one encap. Does anyone=0A= >> think we do? And if so, why?=0A= >>=0A= >>> In my opinion, we should open the door for more than one solution to=0A= >>> service chaining.=0A= >>=0A= >> Ah, "solution to service chaining" (to me) is more than the encap,=0A= >> including the control plane and related stuff. So even if we develop=0A= >> one encap, that doesn't necessarily mean there is only one=0A= >> "solution". So the inconsistency may not be quite as strong as first=0A= >> seems.=0A= >>=0A= >> Suggestion. change:=0A= >>=0A= >> A document will describe the single service-level data plane=0A= >> encapsulation format ...=0A= >>=0A= >> To:=0A= >>=0A= >> A document will describe a service-level data plane encapsulation=0A= >> format ...=0A= >>=0A= >> this is a bit weaker, but still does (implicitely) suggest one encap.=0A= >>=0A= >> or, if folk think this is not good enough, we could add text saying we= =0A= >> are aiming for one, and will only do more if ...=0A= >>=0A= >> But personally, I think it would be fine to have the charter say one=0A= >> encap, and if the WG concludes that one encap isn't what is needed,=0A= >> then recharter. We shouldn't look at rechartering as "impossible". We=0A= >> just need to be able to make the case that more than one encap is=0A= >> necessary. If we can do that, I wouldn't think rechartering would be a= =0A= >> big deal.=0A= >>=0A= >> Thomas=0A= >=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= From jguichar@cisco.com Wed Sep 25 15:21: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 2DD9421F894E for ; Wed, 25 Sep 2013 15:21:07 -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=[AWL=0.000, 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 qhYn1USNNqgj for ; Wed, 25 Sep 2013 15:21: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 4CC7521F9E11 for ; Wed, 25 Sep 2013 15:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6389; q=dns/txt; s=iport; t=1380147660; x=1381357260; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Q0y4OE8BJPodoihxJjA30PF63gRN4bKuwFj1Rbdo/OI=; b=GDhEdJHFrMwtZ2YXKgscrZ2LmGa4RVZo2pP5HJcODC/uxtC98zPhPdgk STCXviY/tgsPnIecvssMQfoBT2WRL2C966tXMiZ80rJBy3+lJAlkczZ3W HjHeK7bnndRVLM+rPoR+8eEUMH316d0w/jOdYS/MMhp6Mi6WHUr81we+C I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFACJhQ1KtJXG//2dsb2JhbABQCoMHOFLAVIEgFnSCJQEBAQQBAQE3NAsSAQgOAwQBAQEKFDcLHQgCBA4FCBOHawy8OASODoESMQcCgxuBAAOpc4Mkgio X-IronPort-AV: E=Sophos;i="4.90,981,1371081600"; d="scan'208";a="264526448" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 25 Sep 2013 22:20:52 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8PMKq18017494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 22:20:52 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 17:20:52 -0500 From: "Jim Guichard (jguichar)" To: Ian Smith Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXSUUAgAAOJgCAAAZxgP//wT+AgABHEoD//60RLIAAWZCA//+92YA= Date: Wed, 25 Sep 2013 22:20:51 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6A01FA@xmb-rcd-x01.cisco.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A6EFA72@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.181] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 22:21:07 -0000 Understood Ian. Take a look at draft-quinn-nsh as I think that may provide more insight.=20 On 9/25/13 6:17 PM, "Ian Smith" wrote: >I'm not trying to be confrontational or an anchor, but I was at the BoF >in Berlin and I've read the three drafts that are getting the most >traffic on list - draft-quinn-nsc-problem-statement-02; >draft-boucadair-network-function-chaining-03; >draft-boucadair-chaining-requirements-01 - and my reading of them, and my >experience building dozens if not hundreds of solutions that look an >awful lot like what is being described, leave me wondering why a new >protocol is required when there are so many options already out there. > >If what you need to do is identify an information stream or network flow, >steer it into a particular set of ordered hops and convey some >information in-band that a particular hop or hops will use along the way >for on-node processing we have the protocols for that already and they >are deployed, so I'm presuming that the desire is to do more, but what >"more" is doesn't seem to be well communicated in the BoF presentations >or the Charter or the three drafts above. > >I know that using the existing protocols to do this is not as easy as it >could be, but those aren't problems with the protocol as much as they are >problems with the implementations, and they tend to be engulfed by the >corollary presumption that service chains will be used in Programmable, >Elastic, Virtualized infrastructure and that will force the complexity >and manual nature of their configuration to become automated and >abstracted. > > >________________________________________ >From: Jim Guichard (jguichar) [jguichar@cisco.com] >Sent: Wednesday, September 25, 2013 5:57 PM >To: Ian Smith >Cc: Thomas Narten; NAPIERALA, MARIA H; nsc@ietf.org >Subject: Re: [nsc] New NSC WG Charter > >With all due respect Ian I think several people have on multiple >occasions on this alias as well as within several of the existing IDs >associated with the SFC (to be) WG. > >Sent from my iPhone > >> On Sep 25, 2013, at 5:54 PM, "Ian Smith" wrote: >> >> If that is the intent, then at some point someone needs to explain, >>probably prior to Vancouver, in detail what functionality not already >>existing in standardized overlay networking protocols, encapsulation >>protocols, and/or options headers is required to solve the problem >>statement being addressed (which also appears to be lacking consensus). >> >> >> >> >> ________________________________________ >> From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim >>Guichard (jguichar) [jguichar@cisco.com] >> Sent: Wednesday, September 25, 2013 5:39 PM >> To: Thomas Narten; NAPIERALA, MARIA H >> Cc: nsc@ietf.org >> Subject: Re: [nsc] New NSC WG Charter >> >> Thomas et al, >> >> Let's be clear about what we mean by "service-level data plane >> encapsulation" as once the intent is clearly understood I see no issue >> with the way the current charter reads. Work item #3 states that the >> service-level data plane encapsulation is used "for conveying the >>service >> function chain and the service function path associated with data >>packets, >> and for carrying context information between nodes that implement >>service >> functions". This is *different* than specifying a solution that uses >> existing transport encapsulations for forwarding traffic through a set >>of >> service functions (for example a solution that uses an MPLS label >>stack). >> >>> On 9/25/13 5:24 PM, "Thomas Narten" wrote: >>> >>> "NAPIERALA, MARIA H" writes: >>> >>>> The group charter's write-up says that: "The Service Function >>>> Chaining (SFC) working group will develop new approaches to service >>>> delivery ..." (i.e., not one "approach" but "approaches", which >>>> means more than one). >>> >>>> But then is states that a document will be developed such that it >>>> "will describe *the(?) single* service-level data plane >>>> encapsulation format for conveying the service function chain and >>>> the service function path associated with data packets, and for >>>> carrying context information between nodes that implement service >>>> functions". >>> >>>> How to do you reconcile those two statements? >>> >>> Note: this inconsistency existed in the earlier charter, I didn't >>> introduce it. :-) >>> >>> I think for the service plane data encapsulation, we should aim for >>> one. I'm understand the concern about writing that into the charter in >>> absolute terms, as I think the WG should have room to discuss and it >>> may be too early to be definitive. But unless there is compelling >>> reason, we should have one encap. (BTW, nothing new here.. this is >>> normal IETF.) >>> >>> That said, I don't see the need for more than one encap. Does anyone >>> think we do? And if so, why? >>> >>>> In my opinion, we should open the door for more than one solution to >>>> service chaining. >>> >>> Ah, "solution to service chaining" (to me) is more than the encap, >>> including the control plane and related stuff. So even if we develop >>> one encap, that doesn't necessarily mean there is only one >>> "solution". So the inconsistency may not be quite as strong as first >>> seems. >>> >>> Suggestion. change: >>> >>> A document will describe the single service-level data plane >>> encapsulation format ... >>> >>> To: >>> >>> A document will describe a service-level data plane encapsulation >>> format ... >>> >>> this is a bit weaker, but still does (implicitely) suggest one encap. >>> >>> or, if folk think this is not good enough, we could add text saying we >>> are aiming for one, and will only do more if ... >>> >>> But personally, I think it would be fine to have the charter say one >>> encap, and if the WG concludes that one encap isn't what is needed, >>> then recharter. We shouldn't look at rechartering as "impossible". We >>> just need to be able to make the case that more than one encap is >>> necessary. If we can do that, I wouldn't think rechartering would be a >>> big deal. >>> >>> Thomas >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc From diego@tid.es Wed Sep 25 15:30: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 613F511E80F2 for ; Wed, 25 Sep 2013 15:30:19 -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 g01wgk3wxpOx for ; Wed, 25 Sep 2013 15:30:15 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0977B11E80DF for ; Wed, 25 Sep 2013 15:30:09 -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 <0MTP00EWJD68J5@tid.hi.inet> for nsc@ietf.org; Thu, 26 Sep 2013 00:30:08 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id C8.D4.28420.0F363425; Thu, 26 Sep 2013 00:30:08 +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 <0MTP00EW6D67J5@tid.hi.inet> for nsc@ietf.org; Thu, 26 Sep 2013 00:30:07 +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; Thu, 26 Sep 2013 00:30:07 +0200 Date: Wed, 25 Sep 2013 22:30:06 +0000 From: "Diego R. Lopez" In-reply-to: <419417C345CA5F48BF45F0A23955A0634A6EFA72@SEAEMBX02.olympus.F5Net.com> X-Originating-IP: [10.95.64.115] To: Ian Smith Message-id: <221C951B-2325-44C5-8CCB-A8AD2702854F@tid.es> Content-id: <735DCE5C5447464C9CDC91C889463C32@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] New NSC WG Charter Thread-index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABFCA//+Ms0yAAHgwgP//iuM+///ne4A= X-AuditID: 0a5f4e69-b7fe58e000006f04-7d-524363f05a2d X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42Lhivcz1P2Q7BxksO0Kh8XxffvZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcefcdLaCLr+Kvf//MjUwdvh0MXJySAiYSFy68pgNwhaTuHBv PZDNxSEksJ1RYuf0RVDOd0aJo/e+skA4Mxklvl/ewtTFyMHBIqAqceEDL0g3G5D5qPk3O4gt DGRPapjMDFLCKRAqMbeDBWKBgsSfc4/BbBEBOYmeAw+ZQUYyC8xnlDh3fy1YglfAUuLH0WNg vcwCZhLrjoVBhAUlfky+xwIRVpeYMiUXJMwsIC7R3HqTBcJWlJi2qIERxGYUkJV4N38+K8Qq NYmZ638xQdgpEi9+32SHOEdAYsme88wQtqjEy8f/WCE+PMkk0d54gG0Co8QshCtmIbliFsIV s5BcMQvJFQsYWVcxihUnFWWmZ5TkJmbmpBsY6WVk6mXmpZZsYoREXOYOxuU7VQ4xCnAwKvHw HvjqFCTEmlhWXJl7iFGCg1lJhPebkXOQEG9KYmVValF+fFFpTmrxIUYmDk6pBkYmGwv3NUwX Qqv3Pd66gM+s2qjBRjTjceYGeYUJT/b821Ka7CWx79evRQtD1H8Ymb88PHl+j9EV2drdc15e yFB537VyT1L0t1ez5/U9OHNzj879iwq1y0S7Fizt+p20YJ/0O4HVU8suLMqXW1I2s5vjlahL ZfuDZ507rKMzeQSsLY/cfXA6oDNSiaU4I9FQi7moOBEAlRCZyZYCAAA= References: <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com> <68B171751455884590F8E38E96416F363F6A0015@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A6EFA09@SEAEMBX02.olympus.F5Net.com> <76A38106-A99E-41C2-B133-DA13BC3F76E4@cisco.com> <419417C345CA5F48BF45F0A23955A0634A6EFA72@SEAEMBX02.olympus.F5Net.com> Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "nsc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 22:30:19 -0000 TGV0IG1lIHNheSB0aGF0LCB1bmxlc3MgeW91IGFyZSBiZWluZyBzcGVjaWFsbHkgaXJvbmljYWws IHlvdSBzdW1tYXJpemVkIG9uZSBvZiB0aGUgbWFpbiBnb2FsczogdGhhdCBhdXRvbWF0ZWQgYW5k IGFic3RyYWN0ZWQgY29uZmlndXJhdGlvbi4gQmVzaWRlcyB0aGlzLCBJIHNlZSBjbGVhciBhZHZh bnRhZ2UgaW4gYSBjb21tb24gdW5kZXJzdGFuZGluZyBmb3IgYnVpbGRpbmcgc3VjaCBjaGFpbnMs IHdoZXRoZXIgYnkgbWVhbnMgb2YgYSBuZXcgcHJvdG9jb2wgb3IgYW4gYWdyZWVtZW50IG9uIHBh cnRpY3VsYXIgc2VtYW50aWNzIGluIGV4aXN0aW5nIG9uZXMuDQoNCk9uIDI2IFNlcCAyMDEzLCBh dCAwMDoxNyAsIElhbiBTbWl0aCB3cm90ZToNCg0KPiBJJ20gbm90IHRyeWluZyB0byBiZSBjb25m cm9udGF0aW9uYWwgb3IgYW4gYW5jaG9yLCBidXQgSSB3YXMgYXQgdGhlIEJvRiBpbiBCZXJsaW4g YW5kIEkndmUgcmVhZCB0aGUgdGhyZWUgZHJhZnRzIHRoYXQgYXJlIGdldHRpbmcgdGhlIG1vc3Qg dHJhZmZpYyBvbiBsaXN0IC0gZHJhZnQtcXVpbm4tbnNjLXByb2JsZW0tc3RhdGVtZW50LTAyOyBk cmFmdC1ib3VjYWRhaXItbmV0d29yay1mdW5jdGlvbi1jaGFpbmluZy0wMzsgZHJhZnQtYm91Y2Fk YWlyLWNoYWluaW5nLXJlcXVpcmVtZW50cy0wMSAtIGFuZCBteSByZWFkaW5nIG9mIHRoZW0sIGFu ZCBteSBleHBlcmllbmNlIGJ1aWxkaW5nIGRvemVucyBpZiBub3QgaHVuZHJlZHMgb2Ygc29sdXRp b25zIHRoYXQgbG9vayBhbiBhd2Z1bCBsb3QgbGlrZSB3aGF0IGlzIGJlaW5nIGRlc2NyaWJlZCwg bGVhdmUgbWUgd29uZGVyaW5nIHdoeSBhIG5ldyBwcm90b2NvbCBpcyByZXF1aXJlZCB3aGVuIHRo ZXJlIGFyZSBzbyBtYW55IG9wdGlvbnMgYWxyZWFkeSBvdXQgdGhlcmUuDQo+DQo+IElmIHdoYXQg eW91IG5lZWQgdG8gZG8gaXMgaWRlbnRpZnkgYW4gaW5mb3JtYXRpb24gc3RyZWFtIG9yIG5ldHdv cmsgZmxvdywgc3RlZXIgaXQgaW50byBhIHBhcnRpY3VsYXIgc2V0IG9mIG9yZGVyZWQgaG9wcyBh bmQgY29udmV5IHNvbWUgaW5mb3JtYXRpb24gaW4tYmFuZCB0aGF0IGEgcGFydGljdWxhciBob3Ag b3IgaG9wcyB3aWxsIHVzZSBhbG9uZyB0aGUgd2F5IGZvciBvbi1ub2RlIHByb2Nlc3Npbmcgd2Ug aGF2ZSB0aGUgcHJvdG9jb2xzIGZvciB0aGF0IGFscmVhZHkgYW5kIHRoZXkgYXJlIGRlcGxveWVk LCBzbyBJJ20gcHJlc3VtaW5nIHRoYXQgdGhlIGRlc2lyZSBpcyB0byBkbyBtb3JlLCBidXQgd2hh dCAibW9yZSIgaXMgZG9lc24ndCBzZWVtIHRvIGJlIHdlbGwgY29tbXVuaWNhdGVkIGluIHRoZSBC b0YgcHJlc2VudGF0aW9ucyBvciB0aGUgQ2hhcnRlciBvciB0aGUgdGhyZWUgZHJhZnRzIGFib3Zl Lg0KPg0KPiBJIGtub3cgdGhhdCB1c2luZyB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIHRvIGRvIHRo aXMgaXMgbm90IGFzIGVhc3kgYXMgaXQgY291bGQgYmUsIGJ1dCB0aG9zZSBhcmVuJ3QgcHJvYmxl bXMgd2l0aCB0aGUgcHJvdG9jb2wgYXMgbXVjaCBhcyB0aGV5IGFyZSBwcm9ibGVtcyB3aXRoIHRo ZSBpbXBsZW1lbnRhdGlvbnMsIGFuZCB0aGV5IHRlbmQgdG8gYmUgZW5ndWxmZWQgYnkgdGhlIGNv cm9sbGFyeSBwcmVzdW1wdGlvbiB0aGF0IHNlcnZpY2UgY2hhaW5zIHdpbGwgYmUgdXNlZCBpbiBQ cm9ncmFtbWFibGUsIEVsYXN0aWMsIFZpcnR1YWxpemVkIGluZnJhc3RydWN0dXJlIGFuZCB0aGF0 IHdpbGwgZm9yY2UgdGhlIGNvbXBsZXhpdHkgYW5kIG1hbnVhbCBuYXR1cmUgb2YgdGhlaXIgY29u ZmlndXJhdGlvbiB0byBiZWNvbWUgYXV0b21hdGVkIGFuZCBhYnN0cmFjdGVkLg0KPg0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IEppbSBHdWlj aGFyZCAoamd1aWNoYXIpIFtqZ3VpY2hhckBjaXNjby5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwg U2VwdGVtYmVyIDI1LCAyMDEzIDU6NTcgUE0NCj4gVG86IElhbiBTbWl0aA0KPiBDYzogVGhvbWFz IE5hcnRlbjsgTkFQSUVSQUxBLCBNQVJJQSBIOyBuc2NAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFtuc2NdIE5ldyBOU0MgV0cgQ2hhcnRlcg0KPg0KPiBXaXRoIGFsbCBkdWUgcmVzcGVjdCBJYW4g SSB0aGluayBzZXZlcmFsIHBlb3BsZSBoYXZlIG9uIG11bHRpcGxlIG9jY2FzaW9ucyBvbiB0aGlz IGFsaWFzIGFzIHdlbGwgYXMgd2l0aGluIHNldmVyYWwgb2YgdGhlIGV4aXN0aW5nIElEcyBhc3Nv Y2lhdGVkIHdpdGggdGhlIFNGQyAodG8gYmUpIFdHLg0KPg0KPiBTZW50IGZyb20gbXkgaVBob25l DQo+DQo+PiBPbiBTZXAgMjUsIDIwMTMsIGF0IDU6NTQgUE0sICJJYW4gU21pdGgiIDxJLlNtaXRo QEY1LmNvbT4gd3JvdGU6DQo+Pg0KPj4gSWYgdGhhdCBpcyB0aGUgaW50ZW50LCB0aGVuIGF0IHNv bWUgcG9pbnQgc29tZW9uZSBuZWVkcyB0byBleHBsYWluLCBwcm9iYWJseSBwcmlvciB0byBWYW5j b3V2ZXIsIGluIGRldGFpbCB3aGF0IGZ1bmN0aW9uYWxpdHkgbm90IGFscmVhZHkgZXhpc3Rpbmcg aW4gc3RhbmRhcmRpemVkIG92ZXJsYXkgbmV0d29ya2luZyBwcm90b2NvbHMsIGVuY2Fwc3VsYXRp b24gcHJvdG9jb2xzLCBhbmQvb3Igb3B0aW9ucyBoZWFkZXJzIGlzIHJlcXVpcmVkIHRvIHNvbHZl IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBiZWluZyBhZGRyZXNzZWQgKHdoaWNoIGFsc28gYXBwZWFy cyB0byBiZSBsYWNraW5nIGNvbnNlbnN1cykuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0 Zi5vcmcgW25zYy1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgSmltIEd1aWNoYXJkIChq Z3VpY2hhcikgW2pndWljaGFyQGNpc2NvLmNvbV0NCj4+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVt YmVyIDI1LCAyMDEzIDU6MzkgUE0NCj4+IFRvOiBUaG9tYXMgTmFydGVuOyBOQVBJRVJBTEEsIE1B UklBIEgNCj4+IENjOiBuc2NAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBOZXcgTlND IFdHIENoYXJ0ZXINCj4+DQo+PiBUaG9tYXMgZXQgYWwsDQo+Pg0KPj4gTGV0J3MgYmUgY2xlYXIg YWJvdXQgd2hhdCB3ZSBtZWFuIGJ5ICJzZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUNCj4+IGVuY2Fw c3VsYXRpb24iIGFzIG9uY2UgdGhlIGludGVudCBpcyBjbGVhcmx5IHVuZGVyc3Rvb2QgSSBzZWUg bm8gaXNzdWUNCj4+IHdpdGggdGhlIHdheSB0aGUgY3VycmVudCBjaGFydGVyIHJlYWRzLiBXb3Jr IGl0ZW0gIzMgc3RhdGVzIHRoYXQgdGhlDQo+PiBzZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUgZW5j YXBzdWxhdGlvbiBpcyB1c2VkICJmb3IgY29udmV5aW5nIHRoZSBzZXJ2aWNlDQo+PiBmdW5jdGlv biBjaGFpbiBhbmQgdGhlIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBhc3NvY2lhdGVkIHdpdGggZGF0 YSBwYWNrZXRzLA0KPj4gYW5kIGZvciBjYXJyeWluZyBjb250ZXh0IGluZm9ybWF0aW9uIGJldHdl ZW4gbm9kZXMgdGhhdCBpbXBsZW1lbnQgc2VydmljZQ0KPj4gZnVuY3Rpb25zIi4gVGhpcyBpcyAq ZGlmZmVyZW50KiB0aGFuIHNwZWNpZnlpbmcgYSBzb2x1dGlvbiB0aGF0IHVzZXMNCj4+IGV4aXN0 aW5nIHRyYW5zcG9ydCBlbmNhcHN1bGF0aW9ucyBmb3IgZm9yd2FyZGluZyB0cmFmZmljIHRocm91 Z2ggYSBzZXQgb2YNCj4+IHNlcnZpY2UgZnVuY3Rpb25zIChmb3IgZXhhbXBsZSBhIHNvbHV0aW9u IHRoYXQgdXNlcyBhbiBNUExTIGxhYmVsIHN0YWNrKS4NCj4+DQo+Pj4gT24gOS8yNS8xMyA1OjI0 IFBNLCAiVGhvbWFzIE5hcnRlbiIgPG5hcnRlbkB1cy5pYm0uY29tPiB3cm90ZToNCj4+Pg0KPj4+ ICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4gd3JpdGVzOg0KPj4+DQo+Pj4+ IFRoZSBncm91cCBjaGFydGVyJ3Mgd3JpdGUtdXAgc2F5cyB0aGF0OiAiVGhlIFNlcnZpY2UgRnVu Y3Rpb24NCj4+Pj4gQ2hhaW5pbmcgKFNGQykgd29ya2luZyBncm91cCB3aWxsIGRldmVsb3AgbmV3 IGFwcHJvYWNoZXMgdG8gc2VydmljZQ0KPj4+PiBkZWxpdmVyeSAuLi4iIChpLmUuLCBub3Qgb25l ICJhcHByb2FjaCIgYnV0ICJhcHByb2FjaGVzIiwgd2hpY2gNCj4+Pj4gbWVhbnMgbW9yZSB0aGFu IG9uZSkuDQo+Pj4NCj4+Pj4gQnV0IHRoZW4gaXMgc3RhdGVzIHRoYXQgYSBkb2N1bWVudCB3aWxs IGJlIGRldmVsb3BlZCBzdWNoIHRoYXQgaXQNCj4+Pj4gIndpbGwgZGVzY3JpYmUgKnRoZSg/KSBz aW5nbGUqIHNlcnZpY2UtbGV2ZWwgZGF0YSBwbGFuZQ0KPj4+PiBlbmNhcHN1bGF0aW9uIGZvcm1h dCBmb3IgY29udmV5aW5nIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGFuZA0KPj4+PiB0aGUg c2VydmljZSBmdW5jdGlvbiBwYXRoIGFzc29jaWF0ZWQgd2l0aCBkYXRhIHBhY2tldHMsIGFuZCBm b3INCj4+Pj4gY2FycnlpbmcgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuIG5vZGVzIHRoYXQg aW1wbGVtZW50IHNlcnZpY2UNCj4+Pj4gZnVuY3Rpb25zIi4NCj4+Pg0KPj4+PiBIb3cgdG8gZG8g eW91IHJlY29uY2lsZSB0aG9zZSB0d28gc3RhdGVtZW50cz8NCj4+Pg0KPj4+IE5vdGU6IHRoaXMg aW5jb25zaXN0ZW5jeSBleGlzdGVkIGluIHRoZSBlYXJsaWVyIGNoYXJ0ZXIsIEkgZGlkbid0DQo+ Pj4gaW50cm9kdWNlIGl0LiA6LSkNCj4+Pg0KPj4+IEkgdGhpbmsgZm9yIHRoZSBzZXJ2aWNlIHBs YW5lIGRhdGEgZW5jYXBzdWxhdGlvbiwgd2Ugc2hvdWxkIGFpbSBmb3INCj4+PiBvbmUuIEknbSB1 bmRlcnN0YW5kIHRoZSBjb25jZXJuIGFib3V0IHdyaXRpbmcgdGhhdCBpbnRvIHRoZSBjaGFydGVy IGluDQo+Pj4gYWJzb2x1dGUgdGVybXMsIGFzIEkgdGhpbmsgdGhlIFdHIHNob3VsZCBoYXZlIHJv b20gdG8gZGlzY3VzcyBhbmQgaXQNCj4+PiBtYXkgYmUgdG9vIGVhcmx5IHRvIGJlIGRlZmluaXRp dmUuIEJ1dCB1bmxlc3MgdGhlcmUgaXMgY29tcGVsbGluZw0KPj4+IHJlYXNvbiwgd2Ugc2hvdWxk IGhhdmUgb25lIGVuY2FwLiAoQlRXLCBub3RoaW5nIG5ldyBoZXJlLi4gdGhpcyBpcw0KPj4+IG5v cm1hbCBJRVRGLikNCj4+Pg0KPj4+IFRoYXQgc2FpZCwgSSBkb24ndCBzZWUgdGhlIG5lZWQgZm9y IG1vcmUgdGhhbiBvbmUgZW5jYXAuIERvZXMgYW55b25lDQo+Pj4gdGhpbmsgd2UgZG8/IEFuZCBp ZiBzbywgd2h5Pw0KPj4+DQo+Pj4+IEluIG15IG9waW5pb24sIHdlIHNob3VsZCBvcGVuIHRoZSBk b29yIGZvciBtb3JlIHRoYW4gb25lIHNvbHV0aW9uIHRvDQo+Pj4+IHNlcnZpY2UgY2hhaW5pbmcu DQo+Pj4NCj4+PiBBaCwgInNvbHV0aW9uIHRvIHNlcnZpY2UgY2hhaW5pbmciICh0byBtZSkgaXMg bW9yZSB0aGFuIHRoZSBlbmNhcCwNCj4+PiBpbmNsdWRpbmcgdGhlIGNvbnRyb2wgcGxhbmUgYW5k IHJlbGF0ZWQgc3R1ZmYuIFNvIGV2ZW4gaWYgd2UgZGV2ZWxvcA0KPj4+IG9uZSBlbmNhcCwgdGhh dCBkb2Vzbid0IG5lY2Vzc2FyaWx5IG1lYW4gdGhlcmUgaXMgb25seSBvbmUNCj4+PiAic29sdXRp b24iLiBTbyB0aGUgaW5jb25zaXN0ZW5jeSBtYXkgbm90IGJlIHF1aXRlIGFzIHN0cm9uZyBhcyBm aXJzdA0KPj4+IHNlZW1zLg0KPj4+DQo+Pj4gU3VnZ2VzdGlvbi4gY2hhbmdlOg0KPj4+DQo+Pj4g QSBkb2N1bWVudCB3aWxsIGRlc2NyaWJlIHRoZSBzaW5nbGUgc2VydmljZS1sZXZlbCBkYXRhIHBs YW5lDQo+Pj4gZW5jYXBzdWxhdGlvbiBmb3JtYXQgLi4uDQo+Pj4NCj4+PiBUbzoNCj4+Pg0KPj4+ IEEgZG9jdW1lbnQgd2lsbCBkZXNjcmliZSBhIHNlcnZpY2UtbGV2ZWwgZGF0YSBwbGFuZSBlbmNh cHN1bGF0aW9uDQo+Pj4gZm9ybWF0IC4uLg0KPj4+DQo+Pj4gdGhpcyBpcyBhIGJpdCB3ZWFrZXIs IGJ1dCBzdGlsbCBkb2VzIChpbXBsaWNpdGVseSkgc3VnZ2VzdCBvbmUgZW5jYXAuDQo+Pj4NCj4+ PiBvciwgaWYgZm9sayB0aGluayB0aGlzIGlzIG5vdCBnb29kIGVub3VnaCwgd2UgY291bGQgYWRk IHRleHQgc2F5aW5nIHdlDQo+Pj4gYXJlIGFpbWluZyBmb3Igb25lLCBhbmQgd2lsbCBvbmx5IGRv IG1vcmUgaWYgLi4uDQo+Pj4NCj4+PiBCdXQgcGVyc29uYWxseSwgSSB0aGluayBpdCB3b3VsZCBi ZSBmaW5lIHRvIGhhdmUgdGhlIGNoYXJ0ZXIgc2F5IG9uZQ0KPj4+IGVuY2FwLCBhbmQgaWYgdGhl IFdHIGNvbmNsdWRlcyB0aGF0IG9uZSBlbmNhcCBpc24ndCB3aGF0IGlzIG5lZWRlZCwNCj4+PiB0 aGVuIHJlY2hhcnRlci4gV2Ugc2hvdWxkbid0IGxvb2sgYXQgcmVjaGFydGVyaW5nIGFzICJpbXBv c3NpYmxlIi4gV2UNCj4+PiBqdXN0IG5lZWQgdG8gYmUgYWJsZSB0byBtYWtlIHRoZSBjYXNlIHRo YXQgbW9yZSB0aGFuIG9uZSBlbmNhcCBpcw0KPj4+IG5lY2Vzc2FyeS4gSWYgd2UgY2FuIGRvIHRo YXQsIEkgd291bGRuJ3QgdGhpbmsgcmVjaGFydGVyaW5nIHdvdWxkIGJlIGENCj4+PiBiaWcgZGVh bC4NCj4+Pg0KPj4+IFRob21hcw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBuc2MgbWFpbGluZyBsaXN0DQo+PiBuc2NAaWV0Zi5vcmcN Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5zYyBtYWlsaW5nIGxp c3QNCj4gbnNjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbnNjDQoNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8i DQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQu ZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMg MTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJp by4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nD s24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpv Lg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2Vl LiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJt cyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFz cHgNCg== From I.Smith@F5.com Wed Sep 25 15:39: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 943CF11E80F2 for ; Wed, 25 Sep 2013 15:39:21 -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 3JlMwUb9eE4f for ; Wed, 25 Sep 2013 15:39:13 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id BAE4021F9D34 for ; Wed, 25 Sep 2013 15:38:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,981,1371081600"; d="scan'208";a="82752211" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 25 Sep 2013 22:38:39 +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; Wed, 25 Sep 2013 15:38:38 -0700 From: Ian Smith To: "Jim Guichard (jguichar)" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABFCA//+Ms0yAAHgwgP//iuM+gAB7xoD//4+KIg== Date: Wed, 25 Sep 2013 22:38:37 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A6EFAD5@SEAEMBX02.olympus.F5Net.com> References: <419417C345CA5F48BF45F0A23955A0634A6EFA72@SEAEMBX02.olympus.F5Net.com>, <68B171751455884590F8E38E96416F363F6A01FA@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6A01FA@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: Thomas Narten , "nsc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 22:39:36 -0000 thanks. I'll take a look.=0A= ________________________________________=0A= From: Jim Guichard (jguichar) [jguichar@cisco.com]=0A= Sent: Wednesday, September 25, 2013 6:20 PM=0A= To: Ian Smith=0A= Cc: Thomas Narten; NAPIERALA, MARIA H; nsc@ietf.org=0A= Subject: Re: [nsc] New NSC WG Charter=0A= =0A= Understood Ian. Take a look at draft-quinn-nsh as I think that may provide= =0A= more insight.=0A= =0A= On 9/25/13 6:17 PM, "Ian Smith" wrote:=0A= =0A= >I'm not trying to be confrontational or an anchor, but I was at the BoF=0A= >in Berlin and I've read the three drafts that are getting the most=0A= >traffic on list - draft-quinn-nsc-problem-statement-02;=0A= >draft-boucadair-network-function-chaining-03;=0A= >draft-boucadair-chaining-requirements-01 - and my reading of them, and my= =0A= >experience building dozens if not hundreds of solutions that look an=0A= >awful lot like what is being described, leave me wondering why a new=0A= >protocol is required when there are so many options already out there.=0A= >=0A= >If what you need to do is identify an information stream or network flow,= =0A= >steer it into a particular set of ordered hops and convey some=0A= >information in-band that a particular hop or hops will use along the way= =0A= >for on-node processing we have the protocols for that already and they=0A= >are deployed, so I'm presuming that the desire is to do more, but what=0A= >"more" is doesn't seem to be well communicated in the BoF presentations=0A= >or the Charter or the three drafts above.=0A= >=0A= >I know that using the existing protocols to do this is not as easy as it= =0A= >could be, but those aren't problems with the protocol as much as they are= =0A= >problems with the implementations, and they tend to be engulfed by the=0A= >corollary presumption that service chains will be used in Programmable,=0A= >Elastic, Virtualized infrastructure and that will force the complexity=0A= >and manual nature of their configuration to become automated and=0A= >abstracted.=0A= >=0A= >=0A= >________________________________________=0A= >From: Jim Guichard (jguichar) [jguichar@cisco.com]=0A= >Sent: Wednesday, September 25, 2013 5:57 PM=0A= >To: Ian Smith=0A= >Cc: Thomas Narten; NAPIERALA, MARIA H; nsc@ietf.org=0A= >Subject: Re: [nsc] New NSC WG Charter=0A= >=0A= >With all due respect Ian I think several people have on multiple=0A= >occasions on this alias as well as within several of the existing IDs=0A= >associated with the SFC (to be) WG.=0A= >=0A= >Sent from my iPhone=0A= >=0A= >> On Sep 25, 2013, at 5:54 PM, "Ian Smith" wrote:=0A= >>=0A= >> If that is the intent, then at some point someone needs to explain,=0A= >>probably prior to Vancouver, in detail what functionality not already=0A= >>existing in standardized overlay networking protocols, encapsulation=0A= >>protocols, and/or options headers is required to solve the problem=0A= >>statement being addressed (which also appears to be lacking consensus).= =0A= >>=0A= >>=0A= >>=0A= >>=0A= >> ________________________________________=0A= >> From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim=0A= >>Guichard (jguichar) [jguichar@cisco.com]=0A= >> Sent: Wednesday, September 25, 2013 5:39 PM=0A= >> To: Thomas Narten; NAPIERALA, MARIA H=0A= >> Cc: nsc@ietf.org=0A= >> Subject: Re: [nsc] New NSC WG Charter=0A= >>=0A= >> Thomas et al,=0A= >>=0A= >> Let's be clear about what we mean by "service-level data plane=0A= >> encapsulation" as once the intent is clearly understood I see no issue= =0A= >> with the way the current charter reads. Work item #3 states that the=0A= >> service-level data plane encapsulation is used "for conveying the=0A= >>service=0A= >> function chain and the service function path associated with data=0A= >>packets,=0A= >> and for carrying context information between nodes that implement=0A= >>service=0A= >> functions". This is *different* than specifying a solution that uses=0A= >> existing transport encapsulations for forwarding traffic through a set= =0A= >>of=0A= >> service functions (for example a solution that uses an MPLS label=0A= >>stack).=0A= >>=0A= >>> On 9/25/13 5:24 PM, "Thomas Narten" wrote:=0A= >>>=0A= >>> "NAPIERALA, MARIA H" writes:=0A= >>>=0A= >>>> The group charter's write-up says that: "The Service Function=0A= >>>> Chaining (SFC) working group will develop new approaches to service=0A= >>>> delivery ..." (i.e., not one "approach" but "approaches", which=0A= >>>> means more than one).=0A= >>>=0A= >>>> But then is states that a document will be developed such that it=0A= >>>> "will describe *the(?) single* service-level data plane=0A= >>>> encapsulation format for conveying the service function chain and=0A= >>>> the service function path associated with data packets, and for=0A= >>>> carrying context information between nodes that implement service=0A= >>>> functions".=0A= >>>=0A= >>>> How to do you reconcile those two statements?=0A= >>>=0A= >>> Note: this inconsistency existed in the earlier charter, I didn't=0A= >>> introduce it. :-)=0A= >>>=0A= >>> I think for the service plane data encapsulation, we should aim for=0A= >>> one. I'm understand the concern about writing that into the charter in= =0A= >>> absolute terms, as I think the WG should have room to discuss and it=0A= >>> may be too early to be definitive. But unless there is compelling=0A= >>> reason, we should have one encap. (BTW, nothing new here.. this is=0A= >>> normal IETF.)=0A= >>>=0A= >>> That said, I don't see the need for more than one encap. Does anyone=0A= >>> think we do? And if so, why?=0A= >>>=0A= >>>> In my opinion, we should open the door for more than one solution to= =0A= >>>> service chaining.=0A= >>>=0A= >>> Ah, "solution to service chaining" (to me) is more than the encap,=0A= >>> including the control plane and related stuff. So even if we develop=0A= >>> one encap, that doesn't necessarily mean there is only one=0A= >>> "solution". So the inconsistency may not be quite as strong as first=0A= >>> seems.=0A= >>>=0A= >>> Suggestion. change:=0A= >>>=0A= >>> A document will describe the single service-level data plane=0A= >>> encapsulation format ...=0A= >>>=0A= >>> To:=0A= >>>=0A= >>> A document will describe a service-level data plane encapsulation=0A= >>> format ...=0A= >>>=0A= >>> this is a bit weaker, but still does (implicitely) suggest one encap.= =0A= >>>=0A= >>> or, if folk think this is not good enough, we could add text saying we= =0A= >>> are aiming for one, and will only do more if ...=0A= >>>=0A= >>> But personally, I think it would be fine to have the charter say one=0A= >>> encap, and if the WG concludes that one encap isn't what is needed,=0A= >>> then recharter. We shouldn't look at rechartering as "impossible". We= =0A= >>> just need to be able to make the case that more than one encap is=0A= >>> necessary. If we can do that, I wouldn't think rechartering would be a= =0A= >>> big deal.=0A= >>>=0A= >>> Thomas=0A= >>=0A= >> _______________________________________________=0A= >> nsc mailing list=0A= >> nsc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/nsc=0A= =0A= From I.Smith@F5.com Wed Sep 25 15:56: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 E2A8C21F9C4C for ; Wed, 25 Sep 2013 15:56: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 36CB0CSiXdc0 for ; Wed, 25 Sep 2013 15:56:11 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5653B21F9ECA for ; Wed, 25 Sep 2013 15:56:09 -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=1380149770; x=1411685770; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ppBs2G7ikh1uWe6TZbLahsYobZdsyz/kD+giXrllRoU=; b=Kea46EeQG4g9AWq7zzIIgGEJ8Q6E3W0Tjn/BFv5CqnjTwlWrEMdT8kwj xAjwDkYZTAkpMUpjllCRmUWj5RHmvSN5KBjiE/NB4W5iX81E03oPn2G77 8bleg9vx5Qt7YLiQFdXs1WWmjqIC0klisFoSIV1ry7WPpQOX3SfVh5L6U Y=; X-IronPort-AV: E=Sophos;i="4.90,981,1371081600"; d="scan'208";a="81982951" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 25 Sep 2013 22:56: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; Wed, 25 Sep 2013 15:56:07 -0700 From: Ian Smith To: "Diego R. Lopez" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABFCA//+Ms0yAAHgwgP//iuM+///ne4AABDiAeQ== Date: Wed, 25 Sep 2013 22:56:07 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A6EFB04@SEAEMBX02.olympus.F5Net.com> References: <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com> <68B171751455884590F8E38E96416F363F6A0015@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A6EFA09@SEAEMBX02.olympus.F5Net.com> <76A38106-A99E-41C2-B133-DA13BC3F76E4@cisco.com> <419417C345CA5F48BF45F0A23955A0634A6EFA72@SEAEMBX02.olympus.F5Net.com>, <221C951B-2325-44C5-8CCB-A8AD2702854F@tid.es> In-Reply-To: <221C951B-2325-44C5-8CCB-A8AD2702854F@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: Thomas Narten , "Jim Guichard \(jguichar\)" , "nsc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 22:56:16 -0000 I wasn't being ironic. What I've seen is that with enough abstraction and = automation, heterogeneity and polymorphism are possible, and will in fact c= ontribute to the maintainability and business value of complex systems. =0A= =0A= Instead of having to make decisions about what functional elements to inclu= de based on their familiarity to the operations staff, you can make them ba= sed on their actual functional utility because they are able to "plug into"= the system and be managed using a uniform tool kit and it brings with it t= he possibility of doing really hard things with far less risk and a lower l= evel of expertise. When you "layer up" your network management away from L= 2-4, you can be much more deliberate with what you do to the traffic better= and align it with business requirements. And when you have better visibil= ity at a macro level to the network, you can manage low level risk better, = which permits you to do things like source routing and name-based forwardin= g without creating gaping security problems on your LAN or WAN.=0A= =0A= =0A= ________________________________________=0A= From: Diego R. Lopez [diego@tid.es]=0A= Sent: Wednesday, September 25, 2013 6:30 PM=0A= To: Ian Smith=0A= Cc: Jim Guichard (jguichar); Thomas Narten; nsc@ietf.org; NAPIERALA, MARIA = H=0A= Subject: Re: [nsc] New NSC WG Charter=0A= =0A= Let me say that, unless you are being specially ironical, you summarized on= e of the main goals: that automated and abstracted configuration. Besides t= his, I see clear advantage in a common understanding for building such chai= ns, whether by means of a new protocol or an agreement on particular semant= ics in existing ones.=0A= =0A= On 26 Sep 2013, at 00:17 , Ian Smith wrote:=0A= =0A= > I'm not trying to be confrontational or an anchor, but I was at the BoF i= n Berlin and I've read the three drafts that are getting the most traffic o= n list - draft-quinn-nsc-problem-statement-02; draft-boucadair-network-func= tion-chaining-03; draft-boucadair-chaining-requirements-01 - and my reading= of them, and my experience building dozens if not hundreds of solutions th= at look an awful lot like what is being described, leave me wondering why a= new protocol is required when there are so many options already out there.= =0A= >=0A= > If what you need to do is identify an information stream or network flow,= steer it into a particular set of ordered hops and convey some information= in-band that a particular hop or hops will use along the way for on-node p= rocessing we have the protocols for that already and they are deployed, so = I'm presuming that the desire is to do more, but what "more" is doesn't see= m to be well communicated in the BoF presentations or the Charter or the th= ree drafts above.=0A= >=0A= > I know that using the existing protocols to do this is not as easy as it = could be, but those aren't problems with the protocol as much as they are p= roblems with the implementations, and they tend to be engulfed by the corol= lary presumption that service chains will be used in Programmable, Elastic,= Virtualized infrastructure and that will force the complexity and manual n= ature of their configuration to become automated and abstracted.=0A= >=0A= >=0A= > ________________________________________=0A= > From: Jim Guichard (jguichar) [jguichar@cisco.com]=0A= > Sent: Wednesday, September 25, 2013 5:57 PM=0A= > To: Ian Smith=0A= > Cc: Thomas Narten; NAPIERALA, MARIA H; nsc@ietf.org=0A= > Subject: Re: [nsc] New NSC WG Charter=0A= >=0A= > With all due respect Ian I think several people have on multiple occasion= s on this alias as well as within several of the existing IDs associated wi= th the SFC (to be) WG.=0A= >=0A= > Sent from my iPhone=0A= >=0A= >> On Sep 25, 2013, at 5:54 PM, "Ian Smith" wrote:=0A= >>=0A= >> If that is the intent, then at some point someone needs to explain, prob= ably prior to Vancouver, in detail what functionality not already existing = in standardized overlay networking protocols, encapsulation protocols, and/= or options headers is required to solve the problem statement being address= ed (which also appears to be lacking consensus).=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> ________________________________________=0A= >> From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim Guich= ard (jguichar) [jguichar@cisco.com]=0A= >> Sent: Wednesday, September 25, 2013 5:39 PM=0A= >> To: Thomas Narten; NAPIERALA, MARIA H=0A= >> Cc: nsc@ietf.org=0A= >> Subject: Re: [nsc] New NSC WG Charter=0A= >>=0A= >> Thomas et al,=0A= >>=0A= >> Let's be clear about what we mean by "service-level data plane=0A= >> encapsulation" as once the intent is clearly understood I see no issue= =0A= >> with the way the current charter reads. Work item #3 states that the=0A= >> service-level data plane encapsulation is used "for conveying the servic= e=0A= >> function chain and the service function path associated with data packet= s,=0A= >> and for carrying context information between nodes that implement servic= e=0A= >> functions". This is *different* than specifying a solution that uses=0A= >> existing transport encapsulations for forwarding traffic through a set o= f=0A= >> service functions (for example a solution that uses an MPLS label stack)= .=0A= >>=0A= >>> On 9/25/13 5:24 PM, "Thomas Narten" wrote:=0A= >>>=0A= >>> "NAPIERALA, MARIA H" writes:=0A= >>>=0A= >>>> The group charter's write-up says that: "The Service Function=0A= >>>> Chaining (SFC) working group will develop new approaches to service=0A= >>>> delivery ..." (i.e., not one "approach" but "approaches", which=0A= >>>> means more than one).=0A= >>>=0A= >>>> But then is states that a document will be developed such that it=0A= >>>> "will describe *the(?) single* service-level data plane=0A= >>>> encapsulation format for conveying the service function chain and=0A= >>>> the service function path associated with data packets, and for=0A= >>>> carrying context information between nodes that implement service=0A= >>>> functions".=0A= >>>=0A= >>>> How to do you reconcile those two statements?=0A= >>>=0A= >>> Note: this inconsistency existed in the earlier charter, I didn't=0A= >>> introduce it. :-)=0A= >>>=0A= >>> I think for the service plane data encapsulation, we should aim for=0A= >>> one. I'm understand the concern about writing that into the charter in= =0A= >>> absolute terms, as I think the WG should have room to discuss and it=0A= >>> may be too early to be definitive. But unless there is compelling=0A= >>> reason, we should have one encap. (BTW, nothing new here.. this is=0A= >>> normal IETF.)=0A= >>>=0A= >>> That said, I don't see the need for more than one encap. Does anyone=0A= >>> think we do? And if so, why?=0A= >>>=0A= >>>> In my opinion, we should open the door for more than one solution to= =0A= >>>> service chaining.=0A= >>>=0A= >>> Ah, "solution to service chaining" (to me) is more than the encap,=0A= >>> including the control plane and related stuff. So even if we develop=0A= >>> one encap, that doesn't necessarily mean there is only one=0A= >>> "solution". So the inconsistency may not be quite as strong as first=0A= >>> seems.=0A= >>>=0A= >>> Suggestion. change:=0A= >>>=0A= >>> A document will describe the single service-level data plane=0A= >>> encapsulation format ...=0A= >>>=0A= >>> To:=0A= >>>=0A= >>> A document will describe a service-level data plane encapsulation=0A= >>> format ...=0A= >>>=0A= >>> this is a bit weaker, but still does (implicitely) suggest one encap.= =0A= >>>=0A= >>> or, if folk think this is not good enough, we could add text saying we= =0A= >>> are aiming for one, and will only do more if ...=0A= >>>=0A= >>> But personally, I think it would be fine to have the charter say one=0A= >>> encap, and if the WG concludes that one encap isn't what is needed,=0A= >>> then recharter. We shouldn't look at rechartering as "impossible". We= =0A= >>> just need to be able to make the case that more than one encap is=0A= >>> necessary. If we can do that, I wouldn't think rechartering would be a= =0A= >>> big deal.=0A= >>>=0A= >>> Thomas=0A= >>=0A= >> _______________________________________________=0A= >> nsc mailing list=0A= >> nsc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/nsc=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= =0A= =0A= --=0A= "Esta vez no fallaremos, Doctor Infierno"=0A= =0A= Dr Diego R. Lopez=0A= Telefonica I+D=0A= http://people.tid.es/diego.lopez/=0A= =0A= e-mail: diego@tid.es=0A= Tel: +34 913 129 041=0A= Mobile: +34 682 051 091=0A= -----------------------------------------=0A= =0A= =0A= ________________________________=0A= =0A= Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.=0A= This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:=0A= http://www.tid.es/ES/PAGINAS/disclaimer.aspx=0A= From diego@tid.es Wed Sep 25 16:08:34 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 0757611E8117 for ; Wed, 25 Sep 2013 16:08:33 -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 FIRTT0srqTwj for ; Wed, 25 Sep 2013 16:08:28 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2E95311E810F for ; Wed, 25 Sep 2013 16:08:03 -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 <0MTP00EXTEX9J5@tid.hi.inet> for nsc@ietf.org; Thu, 26 Sep 2013 01:07:57 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 81.15.28420.DCC63425; Thu, 26 Sep 2013 01:07:57 +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 <0MTP00EXMEX9J5@tid.hi.inet> for nsc@ietf.org; Thu, 26 Sep 2013 01:07:57 +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; Thu, 26 Sep 2013 01:07:56 +0200 Date: Wed, 25 Sep 2013 23:07:55 +0000 From: "Diego R. Lopez" In-reply-to: <419417C345CA5F48BF45F0A23955A0634A6EFB04@SEAEMBX02.olympus.F5Net.com> X-Originating-IP: [10.95.64.115] To: Ian Smith Message-id: <02504B92-692C-4FD2-AD1F-5B16901CC2CE@tid.es> Content-id: <568BED8751E4EF4082F6ECDAD7533AEB@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, es-ES Thread-topic: [nsc] New NSC WG Charter Thread-index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABFCA//+Ms0yAAHgwgP//iuM+///ne4AABDiAef//6M6A X-AuditID: 0a5f4e69-b7fe58e000006f04-e2-52436ccdb785 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42Lhivcz1D2b4xxk0DdX3uL4vv1sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuP/lJmvBGv+K3a9esjQwnnXoYuTkkBAwkXh36QcrhC0mceHe erYuRi4OIYHtjBJr/x5lhnC+M0pc/v2IEcKZCeTsvQmU4eBgEVCVaLsgDNLNBmQ+av7NDmIL A9mTGiYzg9icAqESLy5/YYTYoCDx59xjFhBbREBOoufAQ7AFzALzGSUmLH3LBpLgFbCU+HX3 BivIfGYBM4nlM1UhwoISPybfA+tlFtCR6P3+jRnCFpdobr0JFdeWePLuAtg3jAKyEu/mz2eF 2KUmMXP9LyYIu0BiZfdmZoh7BCSW7DkPZYtKvHz8jxXix0PMEmfO/2WewCgxC+GMWUjOmIXk jFlIzpiF5IwFjKyrGMWKk4oy0zNKchMzc9INjPQyMvUy81JLNjFC4i5zB+PynSqHGAU4GJV4 eA98dQoSYk0sK67MPcQowcGsJML7zcg5SIg3JbGyKrUoP76oNCe1+BAjEwenVANjoeMHb+3F NTe7T18Wan+6WnKOibvP+6VJn8pSJxq+DHMJDP7zJG6q8E6HtfnyuUcnOMRZ+f/hr39ZoJzA xOjEGXb1zK1lp8TuHl8lc6NbY87KzZ9OhKpu9j55x7lN+2d30jG5h7M0F1tc4pwSFBzQapNv VXeJM9o134a9/dk+5aT7G3XNi3SUWIozEg21mIuKEwHHtiB9mQIAAA== References: <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com> <68B171751455884590F8E38E96416F363F6A0015@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A6EFA09@SEAEMBX02.olympus.F5Net.com> <76A38106-A99E-41C2-B133-DA13BC3F76E4@cisco.com> <419417C345CA5F48BF45F0A23955A0634A6EFA72@SEAEMBX02.olympus.F5Net.com> <221C951B-2325-44C5-8CCB-A8AD2702854F@tid.es> <419417C345CA5F48BF45F0A23955A0634A6EFB04@SEAEMBX02.olympus.F5Net.com> Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "nsc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [nsc] New NSC 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: Wed, 25 Sep 2013 23:08:37 -0000 Hi Ian, I happily see we are on the same page. As I tried to say in Berlin, for the= NFV use cases we are considering this "layering up" you mention is essenti= al to, first, being able of really taking advantage of a virtualized enviro= nment and, second, provide mechanisms to make NFV and non-NFV coexistence p= ossible. And this coexistence is going to last for a long long time. Be goode, On 26 Sep 2013, at 00:56 , Ian Smith wrote: > I wasn't being ironic. What I've seen is that with enough abstraction an= d automation, heterogeneity and polymorphism are possible, and will in fact= contribute to the maintainability and business value of complex systems. > > Instead of having to make decisions about what functional elements to inc= lude based on their familiarity to the operations staff, you can make them = based on their actual functional utility because they are able to "plug int= o" the system and be managed using a uniform tool kit and it brings with it= the possibility of doing really hard things with far less risk and a lower= level of expertise. When you "layer up" your network management away from= L2-4, you can be much more deliberate with what you do to the traffic bett= er and align it with business requirements. And when you have better visib= ility at a macro level to the network, you can manage low level risk better= , which permits you to do things like source routing and name-based forward= ing without creating gaping security problems on your LAN or WAN. > > > ________________________________________ > From: Diego R. Lopez [diego@tid.es] > Sent: Wednesday, September 25, 2013 6:30 PM > To: Ian Smith > Cc: Jim Guichard (jguichar); Thomas Narten; nsc@ietf.org; NAPIERALA, MARI= A H > Subject: Re: [nsc] New NSC WG Charter > > Let me say that, unless you are being specially ironical, you summarized = one of the main goals: that automated and abstracted configuration. Besides= this, I see clear advantage in a common understanding for building such ch= ains, whether by means of a new protocol or an agreement on particular sema= ntics in existing ones. > > On 26 Sep 2013, at 00:17 , Ian Smith wrote: > >> I'm not trying to be confrontational or an anchor, but I was at the BoF = in Berlin and I've read the three drafts that are getting the most traffic = on list - draft-quinn-nsc-problem-statement-02; draft-boucadair-network-fun= ction-chaining-03; draft-boucadair-chaining-requirements-01 - and my readin= g of them, and my experience building dozens if not hundreds of solutions t= hat look an awful lot like what is being described, leave me wondering why = a new protocol is required when there are so many options already out there= . >> >> If what you need to do is identify an information stream or network flow= , steer it into a particular set of ordered hops and convey some informatio= n in-band that a particular hop or hops will use along the way for on-node = processing we have the protocols for that already and they are deployed, so= I'm presuming that the desire is to do more, but what "more" is doesn't se= em to be well communicated in the BoF presentations or the Charter or the t= hree drafts above. >> >> I know that using the existing protocols to do this is not as easy as it= could be, but those aren't problems with the protocol as much as they are = problems with the implementations, and they tend to be engulfed by the coro= llary presumption that service chains will be used in Programmable, Elastic= , Virtualized infrastructure and that will force the complexity and manual = nature of their configuration to become automated and abstracted. >> >> >> ________________________________________ >> From: Jim Guichard (jguichar) [jguichar@cisco.com] >> Sent: Wednesday, September 25, 2013 5:57 PM >> To: Ian Smith >> Cc: Thomas Narten; NAPIERALA, MARIA H; nsc@ietf.org >> Subject: Re: [nsc] New NSC WG Charter >> >> With all due respect Ian I think several people have on multiple occasio= ns on this alias as well as within several of the existing IDs associated w= ith the SFC (to be) WG. >> >> Sent from my iPhone >> >>> On Sep 25, 2013, at 5:54 PM, "Ian Smith" wrote: >>> >>> If that is the intent, then at some point someone needs to explain, pro= bably prior to Vancouver, in detail what functionality not already existing= in standardized overlay networking protocols, encapsulation protocols, and= /or options headers is required to solve the problem statement being addres= sed (which also appears to be lacking consensus). >>> >>> >>> >>> >>> ________________________________________ >>> From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim Guic= hard (jguichar) [jguichar@cisco.com] >>> Sent: Wednesday, September 25, 2013 5:39 PM >>> To: Thomas Narten; NAPIERALA, MARIA H >>> Cc: nsc@ietf.org >>> Subject: Re: [nsc] New NSC WG Charter >>> >>> Thomas et al, >>> >>> Let's be clear about what we mean by "service-level data plane >>> encapsulation" as once the intent is clearly understood I see no issue >>> with the way the current charter reads. Work item #3 states that the >>> service-level data plane encapsulation is used "for conveying the servi= ce >>> function chain and the service function path associated with data packe= ts, >>> and for carrying context information between nodes that implement servi= ce >>> functions". This is *different* than specifying a solution that uses >>> existing transport encapsulations for forwarding traffic through a set = of >>> service functions (for example a solution that uses an MPLS label stack= ). >>> >>>> On 9/25/13 5:24 PM, "Thomas Narten" wrote: >>>> >>>> "NAPIERALA, MARIA H" writes: >>>> >>>>> The group charter's write-up says that: "The Service Function >>>>> Chaining (SFC) working group will develop new approaches to service >>>>> delivery ..." (i.e., not one "approach" but "approaches", which >>>>> means more than one). >>>> >>>>> But then is states that a document will be developed such that it >>>>> "will describe *the(?) single* service-level data plane >>>>> encapsulation format for conveying the service function chain and >>>>> the service function path associated with data packets, and for >>>>> carrying context information between nodes that implement service >>>>> functions". >>>> >>>>> How to do you reconcile those two statements? >>>> >>>> Note: this inconsistency existed in the earlier charter, I didn't >>>> introduce it. :-) >>>> >>>> I think for the service plane data encapsulation, we should aim for >>>> one. I'm understand the concern about writing that into the charter in >>>> absolute terms, as I think the WG should have room to discuss and it >>>> may be too early to be definitive. But unless there is compelling >>>> reason, we should have one encap. (BTW, nothing new here.. this is >>>> normal IETF.) >>>> >>>> That said, I don't see the need for more than one encap. Does anyone >>>> think we do? And if so, why? >>>> >>>>> In my opinion, we should open the door for more than one solution to >>>>> service chaining. >>>> >>>> Ah, "solution to service chaining" (to me) is more than the encap, >>>> including the control plane and related stuff. So even if we develop >>>> one encap, that doesn't necessarily mean there is only one >>>> "solution". So the inconsistency may not be quite as strong as first >>>> seems. >>>> >>>> Suggestion. change: >>>> >>>> A document will describe the single service-level data plane >>>> encapsulation format ... >>>> >>>> To: >>>> >>>> A document will describe a service-level data plane encapsulation >>>> format ... >>>> >>>> this is a bit weaker, but still does (implicitely) suggest one encap. >>>> >>>> or, if folk think this is not good enough, we could add text saying we >>>> are aiming for one, and will only do more if ... >>>> >>>> But personally, I think it would be fine to have the charter say one >>>> encap, and if the WG concludes that one encap isn't what is needed, >>>> then recharter. We shouldn't look at rechartering as "impossible". We >>>> just need to be able to make the case that more than one encap is >>>> necessary. If we can do that, I wouldn't think rechartering would be a >>>> big deal. >>>> >>>> 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 > > > -- > "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 e= nlace situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send and = receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc -- "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 Chuong.D.Pham@team.telstra.com Wed Sep 25 16:19: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 11E3B21F9E0B for ; Wed, 25 Sep 2013 16:19:52 -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 nOp5FL1edOfv for ; Wed, 25 Sep 2013 16:19:47 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCE321F92B7 for ; Wed, 25 Sep 2013 16:19:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,981,1371045600"; d="scan'208";a="157907646" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 26 Sep 2013 09:19:44 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7209"; a="161826251" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbvi.tcif.telstra.com.au with ESMTP; 26 Sep 2013 09:19:44 +1000 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Thu, 26 Sep 2013 09:19:43 +1000 From: "Pham, Chuong D" To: "Carlos Pignataro (cpignata)" , "Joel M. Halpern" Date: Thu, 26 Sep 2013 09:19:41 +1000 Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac65/vXgH9985phXSQKZxdGOoCwysAARZIaA Message-ID: <5602569641FB314FB4D9AD5659D41B9C25565D27CB@WSMSG3154V.srv.dir.telstra.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> <52428F89.4040006@joelhalpern.com> <95067C434CE250468B77282634C96ED325FA2181@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED325FA2181@xmb-aln-x02.cisco.com> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" , Linda Dunbar Subject: Re: [nsc] 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: Wed, 25 Sep 2013 23:19:58 -0000 X-List-Received-Date: Wed, 25 Sep 2013 23:19:58 -0000 Another example is in the case of Header Enrichment (HE) service in a Mobil= e network. A HE function inserts information elements into HTTP header. Wha= t to insert is dependent on the identification of the users i.e. the MSISDN= . Today, IP packets arriving at the HE function do not contain such non-IP-= address user identification. Other value-added-services such as Parental Control and certain flavours of= Video Optimisation also require such user identification. If the "cost" of carrying this user identification in metadata is justified= , I see great opportunity, especially for Mobile operators (and Fixed in th= e case of Fixed Mobile Convergence (FMC)). Regards, Chuong -----Original Message----- From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: Wednesday, 25 September 2013 10:07 PM To: Joel M. Halpern Cc: nsc@ietf.org; adrian@olddog.co.uk; Linda Dunbar Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 This, access/subscriber identification, is a good example. Another typical example is to use metadata to share the result of ingress c= lassification, or network information (as e.g., to be used in subscriber id= entification) to then be used for policy in a service function downstream t= he service path. One such example is VRF information. Thanks, -- Carlos. On Sep 25, 2013, at 3:23 AM, Joel M. Halpern wrote: > For me, the canonical example of metadata applies to the use case of a se= rvice chain providing residential gateway functionality with network reside= nt NAT. > If the operator is choosing, due to IPv4 exhaustion, to resuse IP address= es 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 provid= es this function. But those will all be lost in the service chain. >=20 > 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 n= atural candidate for metadata. >=20 > Yours, > Joel >=20 > On 9/24/13 7:02 PM, Linda Dunbar wrote: >> Adrian, >>=20 >> Very good analysis. Thank you. >>=20 >> "Metadata" has been used extensively in the NSC context. But beyond the = "service chain ID", I can't find any other necessary information required t= o 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 exam= ples of the information required to be exchanged among those "Service Funct= ions" given by the draft-quinn-nsc-arch-00? >>=20 >> 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. >>=20 >>=20 >> Thanks, Linda >>=20 >>> -----Original Message----- >>>=20 >>> 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. >>>=20 >>> 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) >>>=20 >>> We should also look at what you mean by out-of-band. I think here=20 >>> you mean "using some information exchange protocol." >>=20 >> [Linda] Since each Service-Chain ID represents a list of service functio= ns, it is possible to use "out-of-band" control channel to pass the informa= tion on the sequence of Service Functions associated with the ID. >>=20 >>=20 >>>=20 >>> The charter says: >>>=20 >>> | 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 >>>=20 >>> and: >>>=20 >>> | 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. >>>=20 >>> This feels like out-of-band exchange of information is expected. >>>=20 >>> Adrian >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >>=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From Chuong.D.Pham@team.telstra.com Wed Sep 25 16:42: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 7CA4E21F8426 for ; Wed, 25 Sep 2013 16:42:30 -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 ZNiR9Ea33Z0W for ; Wed, 25 Sep 2013 16:42:11 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4C85C21F90CF for ; Wed, 25 Sep 2013 16:42:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,981,1371045600"; d="scan'208";a="161911803" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 26 Sep 2013 09:42:04 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7209"; a="161829784" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbvi.tcif.telstra.com.au with ESMTP; 26 Sep 2013 09:42:04 +1000 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Thu, 26 Sep 2013 09:42:03 +1000 From: "Pham, Chuong D" To: Ron Parker , David Allan I , Jerome Moisand , Thomas Nadeau , Linda Dunbar Date: Thu, 26 Sep 2013 09:42:02 +1000 Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac66GpbELX/7iKSeTEWOKNuCjol3hgALgXvQ Message-ID: <5602569641FB314FB4D9AD5659D41B9C25565D2843@WSMSG3154V.srv.dir.telstra.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> <583789CD-C183-451C-B4DD-8944A1DC03B1@lucidvision.com> In-Reply-To: Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] 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: Wed, 25 Sep 2013 23:42:31 -0000 I agree with Ron that cell id is another very good example of interesting f= ields in metadata for Mobile operators.=20 Regards, Chuong -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Thursday, 26 September 2013 3:27 AM To: David Allan I; Jerome Moisand; Thomas Nadeau; Linda Dunbar Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 I agree with Dave that subscriber ID and those fields necessary to complete= the chain forwarding (may or may not end up being a simple chain id) are t= he most important metadata. However, there may be other interesting field= s to consider such as location of the subscriber (e.g., cell id in a 3gpp = network). =20 But other less universally useful fields may prove too troublesome to incor= porate. Take DPI conclusions as a counter example. How are they describ= ed? Where is the central registry of known protocols/applications and the= strings and/or integers used to identify them? It would be an ongoing ba= ttle to try to communicate DPI conclusions between SF's in such a way that = all could agree on the interpretation. Thanks. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of David= Allan I Sent: Wednesday, September 25, 2013 12:21 PM To: Jerome Moisand; Thomas Nadeau; Linda Dunbar Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 I'm not a fan of encapsulating the frame in a database before forwarding...= . I understand Joel's use case of carrying the subscriber ID (assuming the en= tire frame presented to a BNG is not preserved), and the need for a chain I= D as a forwarding "helper". These two items strike me as both "necessary an= d sufficient". Cheers Dave=20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jerom= e Moisand Sent: Tuesday, September 24, 2013 6:51 PM To: Thomas Nadeau; Linda Dunbar Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 There are definitely quite a few additional candidates for metadata fields = of interest... But I believe we need much more work on the PROBLEM STATEMEN= T, and not jump to solution design.=20 We really need to work much more on use cases. Some use cases may imply mor= e 'metadata' than others. Simple problems may be solved by simple means. Mo= re complex problems may require more complex elements of solutions. Some ca= ses could be solved by signaling means instead of data plane means. Or the = reverse way around. Etc. Let me suggest we give more priority to refining the problem statement(s) f= irst... And not rush the design process. -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Nadeau Sent: Tuesday, September 24, 2013 8:18 PM To: Linda Dunbar Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 On Sep 24, 2013:7:02 PM, at 7:02 PM, Linda Dunbar = wrote: > Adrian, >=20 > Very good analysis. Thank you.=20 >=20 > "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 examp= les of the information required to be exchanged among those "Service Functi= ons" given by the draft-quinn-nsc-arch-00? Some examples might be OAM, other stats, service chain descriptions, etc..= . --Tom > 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. =09 >=20 >=20 > Thanks, Linda >=20 >> -----Original Message----- >>=20 >> I think "metadata" is a particularly poor term to use here because it=20 >> 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. >>=20 >> 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=20 >> service node (e.g. about how to perform given some state >> information) >>=20 >> We should also look at what you mean by out-of-band. I think here you=20 >> mean "using some information exchange protocol." >=20 > [Linda] Since each Service-Chain ID represents a list of service function= s, it is possible to use "out-of-band" control channel to pass the informat= ion on the sequence of Service Functions associated with the ID.=20 >=20 >=20 >>=20 >> The charter says: >>=20 >> | 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 protocols=20 >> | or protocol extensions to convey the service path and for=20 >> | communication between nodes that implement service functions >>=20 >> and: >>=20 >> | 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. >>=20 >> This feels like out-of-band exchange of information is expected. >>=20 >> Adrian >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From ramk@Brocade.com Wed Sep 25 18:59: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 08B0321F9E62 for ; Wed, 25 Sep 2013 18:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RahoHRcBkgb5 for ; Wed, 25 Sep 2013 18:59:49 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 299CB21F9E8D for ; Wed, 25 Sep 2013 18:59:48 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r8Q1746F019366; Wed, 25 Sep 2013 18:59:45 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1f41merbm1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Sep 2013 18:59:45 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 25 Sep 2013 18:59:44 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 25 Sep 2013 18:59:44 -0700 From: ramki Krishnan To: Anoop Ghanwani , Ron Parker Date: Wed, 25 Sep 2013 18:59:38 -0700 Thread-Topic: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3] Thread-Index: Ac66GpTkH3bczdcwRreL2qHDsOx9CwAQTPTA Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> <064001ceba06$27012680$75037380$@olddog.co.uk> <201309251724.r8PHO9hk031606@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BFFF996138HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-25_12:2013-09-26, 2013-09-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309250160 Cc: Thomas Narten , "" , "Paul Quinn \(paulq\)" , "" Subject: Re: [nsc] transparent vs. non-transparent services [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: Thu, 26 Sep 2013 01:59:56 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BFFF996138HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >>It may be that as Thomas says, we are not going to worry about non-transp= arent appliances at all, but then I'm not sure how we even implement someth= ing like a load balancer. >> Finally, I do think the problem statement needs a lot of work before we = get to solutions. I think it would be useful to state somewhere in the cha= rter that solutions would only be considered after the problem statement is= in a reasonable shape and the WG participants are in agreement about what = needs to be solved. Agree with Anoop. We do need to clarify this aspect in the problem statemen= t. Thanks, Ramki From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Anoop= Ghanwani Sent: Wednesday, September 25, 2013 11:11 AM To: Ron Parker Cc: Thomas Narten; ; Paul Quinn (paulq); Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3] When I mentioned transparent/non-transparent, I meant that there was some c= hange in the packet headers (whether at the IP, MAC, or TCP layers) for pac= kets that were going to be subject to the service in question, in the non-t= ransparent case. In other words, for the transparent case, I cannot tell b= y looking at the packet headers whether or not the packet would be subject = to that service. Clearly, there are others who think transparent/non-trans= parent mean something else. And that's just simply because there is not st= andard terminology, which perhaps the WG can help define. I think this also plays into where in the packet the NSC header goes, and w= hether there can be multiple instances of the NSC header in the packet. If a certain layer's header is terminated at a service box, it would be a l= ayering violation to carry the NSC header beyond that point. For instance, if the NSC header is located between the MAC and IP header, a= nd the packet hits a load balancer that changes the IP & MAC headers, that = device would need to create a new NSC header. It may be that as Thomas says, we are not going to worry about non-transpar= ent appliances at all, but then I'm not sure how we even implement somethin= g like a load balancer. Finally, I do think the problem statement needs a lot of work before we get= to solutions. I think it would be useful to state somewhere in the charte= r that solutions would only be considered after the problem statement is in= a reasonable shape and the WG participants are in agreement about what nee= ds to be solved. Anoop On Wed, Sep 25, 2013 at 10:28 AM, Ron Parker > wrote: Thomas, I agree that the notion of transparent service is not necessary to incorpor= ate in our work. Ron -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, September 25, 2013 1:24 PM To: Ron Parker Cc: Paul Quinn (paulq); >; = Anoop Ghanwani; > Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3] Ron, > So is the definition of transparent -- packets are unchanged (headers, > content, etc.) and routing/switching path is unaltered? > Or is it just the former? The mere diversion to a service node would > seem to constitute "routing/switching is altered". I think the point is we don't exactly have an agreed to defintion of "trans= parent" in the NSC context, so it's not particularly helpful to use it in d= escribing NSC behavior without being clear about what is meant. For services in NSC, packets clearly will get modified in some cases (e.g. = NAT or proxies) but won't in others. So distinguishing types of services by= how much they change the packets they inspect is probably not helpful for = NSC. NSC doesn't really care *what* the services does, just that the servic= e exists and packets need to be steered to travel through the service. Thomas --_000_C7634EB63EFD984A978DFB46EA5174F2BFFF996138HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>>It may be that as Thomas says, we are not going to worry about non-transparent appliances at all, but then I'm not sure how we even implement something li= ke a load balancer.

 

>> Finally, I do think the problem statement needs a lot of work before we get= to solutions.  I think it would be useful to state somewhere in the chart= er that solutions would only be considered after the problem statement is in a reasonable shape and the WG participants are in agreement about what needs = to be solved.

 

Agree with Anoop. We do need to clarify this aspect in the problem statement.

 

Thanks,

Ramki

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Anoo= p Ghanwani
Sent: Wednesday, September 25, 2013 11:11 AM
To: Ron Parker
Cc: Thomas Narten; <adrian@olddog.co.uk>; Paul Quinn (paulq); <nsc@ietf.org>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re:= New NSC WG Charter - charter bullet #3]

 

When I mentioned transparent/non-transparent, I meant = that there was some change in the packet headers (whether at the IP, MAC, or TCP layers) for packets that were going to be subject to the service in questio= n, in the non-transparent case.  In other words, for the transparent case= , I cannot tell by looking at the packet headers whether or not the packet woul= d be subject to that service.  Clearly, there are others who think transparent/non-transparent mean something else.  And that's just simp= ly because there is not standard terminology, which perhaps the WG can help define.

 

I think this also plays into where in the packet the N= SC header goes, and whether there can be multiple instances of the NSC header = in the packet.

 

If a certain layer's header is terminated at a service= box, it would be a layering violation to carry the NSC header beyond that point.=

 

For instance, if the NSC header is located between the= MAC and IP header, and the packet hits a load balancer that changes the IP &= ; MAC headers, that device would need to create a new NSC header.<= /p>

 

It may be that as Thomas says, we are not going to wor= ry about non-transparent appliances at all, but then I'm not sure how we even implement something like a load balancer.

 

Finally, I do think the problem statement needs a lot = of work before we get to solutions.  I think it would be useful to state somewhere in the charter that solutions would only be considered after the problem statement is in a reasonable shape and the WG participants are in agreement about what needs to be solved.

 

Anoop

 

On Wed, Sep 25, 2013 at 10:28 AM, Ron Parker <Ron_Parke= r@affirmednetworks.com> wrote:

Thomas,

I agree that the notion of transparent service is not necessary to incorpor= ate in our work.

   Ron


-----Original Message-----
From: Thomas Narten [mailto:narten@us.= ibm.com]
Sent: Wednesday, September 25, 2013 1:24 PM
To: Ron Parker
Cc: Paul Quinn (paulq); <adrian@o= lddog.co.uk>; Anoop Ghanwani; <nsc@ietf.org> Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3]

Ron,

> So is the definition of transparent -- packets are unchanged (headers,=
> content, etc.) and routing/switching path is unaltered?
> Or is it just the former?  The mere diversion to a service node w= ould
> seem to constitute "routing/switching is altered".

I think the point is we don't exactly have an agreed to defintion of "transparent" in the NSC context, so it's not particularly helpfu= l to use it in describing NSC behavior without being clear about what is meant.<= br>
For services in NSC, packets clearly will get modified in some cases (e.g. = NAT or proxies) but won't in others. So distinguishing types of services by how much they change the packets they inspect is probably not helpful for NSC. = NSC doesn't really care *what* the services does, just that the service exists = and packets need to be steered to travel through the service.

Thomas

 

--_000_C7634EB63EFD984A978DFB46EA5174F2BFFF996138HQ1EXCH01corp_-- From mohamed.boucadair@orange.com Thu Sep 26 00:35:41 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 668D711E80E2 for ; Thu, 26 Sep 2013 00:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.158, 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 axXQRQpin10n for ; Thu, 26 Sep 2013 00:35:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 90CFB11E8168 for ; Thu, 26 Sep 2013 00:35:33 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 217D422C18F; Thu, 26 Sep 2013 09:35:32 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 005A12380A9; Thu, 26 Sep 2013 09:35:32 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 26 Sep 2013 09:35:31 +0200 From: To: Ian Smith , "Jim Guichard (jguichar)" , Thomas Narten , "NAPIERALA, MARIA H" Date: Thu, 26 Sep 2013 09:35:30 +0200 Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABFCA//+Ms0yAAKKTIA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EF2475CFA@PUEXCB1B.nanterre.francetelecom.fr> References: <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com>, <68B171751455884590F8E38E96416F363F6A0015@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A6EFA09@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A6EFA09@SEAEMBX02.olympus.F5Net.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 07:35:41 -0000 Hi Ian, Your comment is legitimate and I hear it.=20 Together with Ron, we initiated an analysis document discussing various des= ign option candidates. The current version is available at http://tools.ietf.org/html/draft-boucadair-chaining-design-analysis-00=20 That effort is open and you are welcome to record solutions that do not req= uire protocol extensions, etc. Those proposals will be analyzed and challen= ged. Cheers, Med >-----Message d'origine----- >De=A0: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Ia= n >Smith >Envoy=E9=A0: mercredi 25 septembre 2013 23:54 >=C0=A0: Jim Guichard (jguichar); Thomas Narten; NAPIERALA, MARIA H >Cc=A0: nsc@ietf.org >Objet=A0: Re: [nsc] New NSC WG Charter > >If that is the intent, then at some point someone needs to explain, >probably prior to Vancouver, in detail what functionality not already >existing in standardized overlay networking protocols, encapsulation >protocols, and/or options headers is required to solve the problem >statement being addressed (which also appears to be lacking consensus). > > > > >________________________________________ >From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim Guichar= d >(jguichar) [jguichar@cisco.com] >Sent: Wednesday, September 25, 2013 5:39 PM >To: Thomas Narten; NAPIERALA, MARIA H >Cc: nsc@ietf.org >Subject: Re: [nsc] New NSC WG Charter > >Thomas et al, > >Let's be clear about what we mean by "service-level data plane >encapsulation" as once the intent is clearly understood I see no issue >with the way the current charter reads. Work item #3 states that the >service-level data plane encapsulation is used "for conveying the service >function chain and the service function path associated with data packets, >and for carrying context information between nodes that implement service >functions". This is *different* than specifying a solution that uses >existing transport encapsulations for forwarding traffic through a set of >service functions (for example a solution that uses an MPLS label stack). > >On 9/25/13 5:24 PM, "Thomas Narten" wrote: > >>"NAPIERALA, MARIA H" writes: >> >>> The group charter's write-up says that: "The Service Function >>> Chaining (SFC) working group will develop new approaches to service >>> delivery ..." (i.e., not one "approach" but "approaches", which >>> means more than one). >> >>> But then is states that a document will be developed such that it >>> "will describe *the(?) single* service-level data plane >>> encapsulation format for conveying the service function chain and >>> the service function path associated with data packets, and for >>> carrying context information between nodes that implement service >>> functions". >> >>> How to do you reconcile those two statements? >> >>Note: this inconsistency existed in the earlier charter, I didn't >>introduce it. :-) >> >>I think for the service plane data encapsulation, we should aim for >>one. I'm understand the concern about writing that into the charter in >>absolute terms, as I think the WG should have room to discuss and it >>may be too early to be definitive. But unless there is compelling >>reason, we should have one encap. (BTW, nothing new here.. this is >>normal IETF.) >> >>That said, I don't see the need for more than one encap. Does anyone >>think we do? And if so, why? >> >>> In my opinion, we should open the door for more than one solution to >>> service chaining. >> >>Ah, "solution to service chaining" (to me) is more than the encap, >>including the control plane and related stuff. So even if we develop >>one encap, that doesn't necessarily mean there is only one >>"solution". So the inconsistency may not be quite as strong as first >>seems. >> >>Suggestion. change: >> >> A document will describe the single service-level data plane >> encapsulation format ... >> >>To: >> >> A document will describe a service-level data plane encapsulation >> format ... >> >>this is a bit weaker, but still does (implicitely) suggest one encap. >> >>or, if folk think this is not good enough, we could add text saying we >>are aiming for one, and will only do more if ... >> >>But personally, I think it would be fine to have the charter say one >>encap, and if the WG concludes that one encap isn't what is needed, >>then recharter. We shouldn't look at rechartering as "impossible". We >>just need to be able to make the case that more than one encap is >>necessary. If we can do that, I wouldn't think rechartering would be a >>big deal. >> >>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 mohamed.boucadair@orange.com Thu Sep 26 00:47: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 95C6C21F8FF8 for ; Thu, 26 Sep 2013 00:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rben8CHygwZy for ; Thu, 26 Sep 2013 00:46:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 523E111E8169 for ; Thu, 26 Sep 2013 00:46:42 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 0BB503B41E3; Thu, 26 Sep 2013 09:46:41 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id DF6DF180093; Thu, 26 Sep 2013 09:46:40 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 26 Sep 2013 09:46:36 +0200 From: To: Linda Dunbar , Ron Parker , JACQUENET Christian IMT/OLN Date: Thu, 26 Sep 2013 09:46:34 +0200 Thread-Topic: Questions to "draft-boucadair-service-chaining-framework-00" Thread-Index: Ac6zIzV4YecyP+l0TLOCgmb29TQbGwHZ8zlw Message-ID: <94C682931C08B048B7A8645303FDC9F36EF2475D15@PUEXCB1B.nanterre.francetelecom.fr> References: <4A95BA014132FF49AE685FAB4B9F17F645BC7C23@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BC7C23@dfweml509-mbx.china.huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/related; boundary="_006_94C682931C08B048B7A8645303FDC9F36EF2475D15PUEXCB1Bnante_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.9.26.51815 Cc: "nsc@ietf.org" Subject: Re: [nsc] Questions to "draft-boucadair-service-chaining-framework-00" 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, 26 Sep 2013 07:47:08 -0000 --_006_94C682931C08B048B7A8645303FDC9F36EF2475D15PUEXCB1Bnante_ Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF2475D15PUEXCB1Bnante_" --_000_94C682931C08B048B7A8645303FDC9F36EF2475D15PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Linda, Apologies for the delay to answer this message. Please see inline. Cheers, Med De : Linda Dunbar [mailto:linda.dunbar@huawei.com] Envoy=E9 : lundi 16 septembre 2013 23:25 =C0 : BOUCADAIR Mohamed IMT/OLN; Ron Parker; JACQUENET Christian IMT/OLN Cc : nsc@ietf.org Objet : Questions to "draft-boucadair-service-chaining-framework-00" Mohamed, et al, What does the first bullet in the Objective section mean? [cid:image001.png@01CEBA9C.53F17280] Is it about the "forwarding planes" among "Service Functions"? or is it abo= ut creating a forwarding plane in the "underlying network? [Med] This means creating a forwarding path that will be service-inferred, = i.e. a forwarding path that involves a set of SFs in a given order. Is the "differentiated packet forwarding" referring to the "underlying netw= ork"? [Med] it means differentiated packet forwarding within an SFC-enabled domai= n. [cid:image002.png@01CEBA9C.53F17280] In Section 1.5, you stated that "SFs are handled as black boxes", [cid:image003.png@01CEBA9C.53F17280] Is it intended for chaining together existing Service Functions? [Med] chaining-related features are not part of the technical characterizat= ion of each SF. Does it mean that the Service Functions don't see the "Chain Marking inform= ation" (the Section 6 in draft-boucadair-chaining-design-analysis-00)? [Med] This is something that need to be further clarified in the document: = the marking information will need to be parsed and understood by the SF. We= do not consider that part an inherent component of the technical character= ization of an SF. This is an extension to "legacy" behavior. Then, is it the underlying nodes that need to interpret the "Chain Marking = Information"? [Med] Only SF nodes interpret such information; other (legacy) nodes are no= t required to do so. Thanks, Linda Dunbar --_000_94C682931C08B048B7A8645303FDC9F36EF2475D15PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Linda,

 

Apologies for the delay to answer this message.

 

Please s= ee inline.

 =

Cheers,

Med<= o:p>

 

=

De : Linda Dunbar= [mailto:linda.dunbar@huawei.com]
Envoy=E9 : lundi 16 septe= mbre 2013 23:25
=C0 : BOUCADAIR Mohamed IMT/OLN; Ron Parker;= JACQUENET Christian IMT/OLN
Cc : nsc@ietf.org
Objet&n= bsp;: Questions to "draft-boucadair-service-chaining-framework-00&= quot;

 

Mohamed, et al,

 

What does the first bullet in= the Objective section mean?

Is it about the “forwar= ding planes” among “Service Functions”? or is it about cr= eating a forwarding plane in the “underlying network?

[Med] This me= ans creating a forwarding path that will be service-inferred, i.e. a forwar= ding path that involves a set of SFs in a given order. =

 

 

Is the “differentiated p= acket forwarding” referring to the “underlying network”?<= o:p>

[Med] it means differentiated packet= forwarding within an SFC-enabled domain.

 

 

In Section 1.5, you stated that “SFs are handled as= black boxes”,

Is it intended for chaining together =  existing Service Functions?

[= Med] chaining-related features are not part of the technical characterizati= on of each SF.

Does= it mean that the Service Functions don’t see the “Chain Markin= g information” (the Section 6 in draft-boucadair-chaining-design-anal= ysis-00)?  

[Med] This is somet= hing that need to be further clarified in the document: the marking informa= tion will need to be parsed and understood by the SF. We do not consider th= at part an inherent component of the technical characterization of an SF. T= his is an extension to “legacy” behavior.

Then, is it the underlying nodes that nee= d to interpret the “Chain Marking Information”?

=

[Med] Only SF nodes interpret such information; ot= her (legacy) nodes are not required to do so.

 

Thanks,=

Linda Dunbar

 

= --_000_94C682931C08B048B7A8645303FDC9F36EF2475D15PUEXCB1Bnante_-- --_006_94C682931C08B048B7A8645303FDC9F36EF2475D15PUEXCB1Bnante_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=2500; creation-date="Thu, 26 Sep 2013 07:46:35 GMT"; modification-date="Thu, 26 Sep 2013 07:46:35 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAQ8AAAALCAYAAABhyQicAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAlESURBVGje 7Zp3jJRlEMYn2Sj/GBMkEhICRiOCJUAUKSoI2BA1BKQElBbEQldpgmIBCyCghKI0FQu9HAgW8Oi9 qMCBCocCCtI8FJAT5cbvt3Pjfrfc3kHgFmL2ksnuvt9bnmnPzPuBqGrtQF5KSUpSkpKzEcn9EveX EciMQNJyZXbu7/16Zn87A5kWWp+SlKQkuUK+Ltai/MuHPLYHUi73USQk/G4UyPFCttwXyB3R+SdP RjQzM6J79kT02LGI5uRE4vb8/8ihQxFNS4voqVPnd9/09IhmZJzZ3Oxss/dPP51/HPmdxTlZWYXP xf/g+v33C+Obv/46HeuiRRHdvLlozyXeDxyI6N69kWguJFdv8vXyQCYlkzw65Q4nkikFbJcTyJDo vMOHRUePFn30UdH27UVr1RL95hspZO/CZdMm0aVLz32f8y1//CE6dKgESXt+9500SXTJksLnHT8u 2r27aJcuos88I/rnn0Wr75Ejor16id51l+i+fYnnTZki2rq1aMeOol99deF889xzonXriv7ySwzX okVFe+7ff4u++67orbeKjht3oWKzxlncGM6JPOgqro4O79ljBu/USXTevHBSNC9guxOB1IrO69s3 ZrDsbNE+fSwJunYVHTtW9LPPLPgyMyWoSKKDB4v27i26fr2t+fln0QEDbGzqVBv77TfR228Xvf56 w/XppzEjzZxpc8eMSZzAOTmiCxbYucx9/XUbQ0hSxiZOjAVc5862H1hfCm54c+eKduhgepEwJOnw 4YaZxIUsw+d9/73oiy8aVvY+ccLGZ8+23wRWIqwE3ocf2r7ffWdjv/4q+uqrds7TT4u+8ILh+Ocf 0UaNREuXtvnp6TY/K0t0yBA7a+1aG/vhB9P/k09EJ082bDyDdD74QHTOHPP7jz/a/LQ0W8+ZjhV7 MH/gQNFKlUzP/HSYPl30yitFGzcWfftts6nrz7n4Fz+zLzHx/PNWGHg2bZro+++LPvusrVmxwsaJ S76DCT38bHwDJtaDC78xjr8d6803S9BtGC7stHWrzdm/X/S110xHfAqO3bvzYuV5v36ia9acrieY XnnFdGRu//55CZXY57n//vZbOwM7850xzu7WTXTECNvDfUgRGDXK9HWyI47eesvGevYU/frrgsjj skAWJIM8NgVyRbS6oyzJCWCIgEC36ZUL2O5IICWj8x54QHThwryKYAgStnhxS9bly0U3brQEw3A4 hy5l3TrrXJhLgjRtKrp6tZEQFaxhQ8PlDiaZ27Sxfe680wIlP0MeOiT68ssWdDgOIoA4IIDHHrP1 t90m+s47ErS6tg9YSTQC1hOP4CDo69UzJxN848dbhWE/J4527USXLTM7cBZOJ0GpxJxVu7bpyPyM DNMJAScJtW2baJ06lljeXXBmq1ZGxAQOgcWZb75plXXxYgladNuDMyBrPrHrypVGKCQWBIx/P//c SAk7lyxpScveEHUYKzgGDTLiGDnSzvnoI9EKFUR37Mjf3tu3i1arZv7ZsMH8N2GCYUZPzm7b1hJt yxbRqlUtIb780jpMiBwdiT2Ihu/4HF+AiVhATp4U3blT9IYbLFbwCTHEWSQlWPEhWLEpuOiY8LPH 5YMPij7yiOlOsqMjumIr1r/3nmipUvl3z0ePWmdNDKLXjBlWDLGrF1LIx+dDQOB/8knRJk1sjHVl y5pNvvjC/EYMQRKQCfOJJ/CRMx6v6MuagruPcckgj7WBFI9Wn8cfjx2OkQFqvysUsF1W7j3LKjUG 9z0OHrRPWlc3mAcYCUGVhzz4xEEEGISCI0uUMOc7UZC8nkwkDkatWdPWY2ifGy8kObhIFCoagcc4 lfHee209DqXaMk4Q8iyeAMFEQLzxRmycoL7nnthvkqV587zVic8nnrDuybFCoowT6BAMQiL5On6H 7UjQfPyxfeeaREJ58IXPI6Hr1zcd/SzImmfsj83DetG5QUrhMbBCpu4XKja2oxrznCvATTeZDxMF LhjC5EJc0SX4b+wL2fl3r7ielA8/LFqsmOhVVxnZQWr4CEzEUZkyRvTMZ274akT8kMjetYHVuzj0 cVJ2XSFLvlP9e/Qw4iAXnNzpsvbuzV9PrudetIhL8EFo3nl4kQAH3SB2pFuEdLzThfx9P8gMEmVf fM5++JLOCj9C6ow1a2YdqnfWu3ZZ4ciLb0QyyONwIKWiTE67B0DYmGSNBXT9ArY7ntuZ2FWEikFA t2xpgYfjGzQQvfFGMwoMSjLC7FR0HApRcZ+GPJiD0ek0eIZxqByOi6rCeqrUU0/FCMgTNV7oHHAW gYKQfIyvWmVBzXp0pes5dkz0oYdiWP065e8hICt30vz5ple5cqItWliFJxjQBVxg9cCMx4qzE71T oLWtWNEwQ94k6333WeKTsNi2ShUjW75TeTlr1iyzC0HmdsWe4MUGBFz58jYXH5Ckd99tZ6ErieLt tWMl2LEruPAJayGkypVjusULncN111kiQLbYFSHJWE91hQhJNro/uiF08+KAkMR0ieCgg8MvdFFg Yh86GzoRCJ/O4v77bT1XObBC8I6VzpCrBd0nRIAPsTF2ZR3kj12J11tusesciUnSggNdE5EHHRTd NsRGMaNTJo+wFT6qXt2uT5yFLSgKYCNmeC2A/tdea3kHkWM3ulmuJE7ew4ZZ54gv6QQZwxbkDxgg UWzKuhi2SwKZnqwXpg3zVFOqht/VTYYXsN2pQHr+NxdleKcBAxMgOJQApE1lX8biz6I78Ls1FYn5 BHeYTelimIshfS7PGWM+7wsSvfNgrWOK70pY73dwJIyVoI1P7vB33hFQVZgL3ni9wusdK88SYXVb Eax8ggt7spbv+ARdCEbsyKdjhaTDHU/YrqzjXMcKrni/hF+2kuyOlWTwjoAx9sAHYVuEBXzMcT+6 rr4ePXwu8xDI1F9qxtsD8e6P9WDjfHRA5/B6vz7yjLnoRkFjDee6XZFEdmVPug+IEwLj6hH2bdhG NWoYgXPdCePnO8Le3mGxBzHomNGBM/ERRcfH/Sywug7YALzsx5h39OH4Rs8YPm4Kmckij5XRq0v+ bWiVQA4WsuW2QK7Ri+1fQ1KSkrMVf+FMh4D4O7Z4Iam5TvNOiJfQF48OlwYyUIvqL8F/EpsaSJdA uoeE3xvPcNuFgXSMW5+SlKQkeUK+Dgoku8jI41+ekRNqvayhNwAAAABJRU5ErkJggg== --_006_94C682931C08B048B7A8645303FDC9F36EF2475D15PUEXCB1Bnante_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=5590; creation-date="Thu, 26 Sep 2013 07:46:35 GMT"; modification-date="Thu, 26 Sep 2013 07:46:35 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAaYAAAAbCAYAAAA3UiscAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABVWSURBVHja 7d0LtJVVtQfw7zbGbVwaN8cNR43Ry16jkfaO7GFRGVqWPaRMs+jhAxDKwkyspGyjkFnaS4kQihKx fBQRFRiZRZAoCBEqoUSWWoEQgaIi2rrfby8m+zuns48HBD0HvjXGHGfvb6/HXHPNNf9zrm+tdYqU 0sElNXozbdy4sTFo0KDGeeed19iyZcv252PHjm1Mnz69sXTp0sb+++/fuPTSSxuTJ09uHHrooY3N mzc35s6d2zjwwAMby5Yta5xxxhmNq6++urFixYrG7NmzG7fddluThg4d2nx2zTXXNP8q5+/AgQMb 559/fmPNmjWNlStXNsaPH99YsGBB87fhw4c3Jk2a1CwzYMCAxvr16xuHH354Y+LEiY1FixY1Bg8e 3Gzzqquuaj5/8MEHm/wqj7/eLu+aaqqppkeTim0fenUqDXoaMmRIOv7449O6deu2P7/11lvTcccd l0aPHp3GjBmTSuBq5hk2bFgqASSNGzeuWW758uVp9erVacSIEc3v06ZNS1u3bm3WMXXq1Oazs88+ u1n3zTff3PwedMkllzTz3Xjjjc16PZszZ07zmTZLYEuzZs1Kp512Who5cmS65ZZb0qhRo5r58LZk yZLt/Cp35pln9nZx16lOdarTo5r6BDDVqU51qlOd9p5UA1Od6lSnOtWpV6U+AEz3lXRtSdeVtKim mmqqqaZHha7bRltqYEppbEn/V9ITSuq/19CKFf3TunV9g9dVq/qn22/fe8amr9NNN/Ud3XokiQ7T 5VoW7egJ22j83g5My5qg9JvfFGnw4CK95S1FWras2MZ2kT7zmSK97W1F+u53W8/+9Kec96ij8ud4 vivo+98v0gc/mNv9xz92Xb2rVxfpuOOK9LGPFen++/OzM88smv2u5luwoEgf+ECRhgwp0vz5redf +UqRPvzhIn30o63yu4OWLu36+Te/WaQf/GDny7cj4/eudxVpypTd05/Nm7M8v/OdnuXfsKFIN97Y 8/p//ONc//vfX6Rbbtl949IdrVpVpGOPLdKoUUXaujU/azQ66s/DJfWddNIj05/ly4v03vdmMn47 U0fVhnQer699bdfyS1/uuaf1/ec/zzq9bt0jIy/tb9r08OqgK2wO+t3vPNu3pBv2DGCaN29euuKK K5o75HqeGk0WDSxDTRlPOaUlsL/9rUjnn1+ko49uPbvvvmzo3/zmrGjx/O9/L8r2i/STnxRpy5ai jEiK9NOftn7//e+LNGtW/q2rwfn1r4v07nfnSThzZmuSL1yY673++vz9zjuL9LOfZeD6wx+KNGdO ke6+u/2g42PatGzcX/7yXO6aa4p06aVFWru2lY9CvPjFGbymTs1GUl9PP71IL31pkb785SL98pc5 L95+8Ysi/fCHLQD1F1+33ponN57xde+9ud8zZhTpgQdyndrXH89++9tc/i9/KdKrXlWkCy/MZcnT 8yVLMq/qDV7VedVVuf1rr22BzCtfWaRvfzuXrwK7NuT98587TqhLLsmTuJ3R+9e/8kRXHq/ajN9u uCHXOW9ekR58sPUcv9o3hjffnJ2MU08t0saNWV+C3ypft9/eckze8IaOetRuXC+/vEgHHFCkz342 y4dcPV+0KJf3N3R77tysf7fdltsjK3wHeDCk+qk9+eSZPbulg3SDftIJz+ldVbcmTCjSgQdmfZIX P/RUnvXrs8OjDXxxhqJeMvSMHOi5+dYOLOimvMbg3/8u0j//mXmOMfU8dKkrok/6ZU5WdYMMPDen Q7c4OC97Wcf5QXdD58khnpMjvtQrP9m84hXZbpBV5P3jH4t02WW5z75z8IzR4sW5rLq14beVK1t9 9Ts5d9UnfT/44KwD9E0f6ZmxuPjizCvHIfJrz7ObbuoeKOiBuSyvcQ/g0z/PyD10y/z59Kczv+0A OSjmgDpCP+hG2B0BAH3J+c/p28C0ZcuWcuLNTSeffHJpYE4qgeWUclAu7mHpI7YLeNy4rKQMSdUI Mqrve99/Chm6M1Y+MzYAjYEbOTIL/6yzcgRmshhIhh2YtQMRwPGUpxRp+PBsdDy74IIijR6d6/3U p/LAU7SDDirSa15TpHPOKdKYMR35rZLJ8PnPF+njH8/1UgCTUoTwnOdkgxV5GfQnP7lIJ5xQpIkT s3LedVeR3vrWIu2/f5E++ck8CclKf047LfP2rW9lg2Ly8N5f//rc1498JBvpSZMyjyNGZBmr8+1v L9KgQUX6xCdyJKZfJuMznpG9b/2NyEGk9KIXFWny5BavJoi+k8mJJ+a25d9vvyIdf3wub/KZ/HgG rvKK/PRfv+XRJ/zqR1fyu+OODOYIrxwUhthvjK86Rc4+e8aImKTq1scjj8yyHDYs911eoC/vj35U pM99Ltfhd2MosnrmM3N58u3OY2eMnvrUPLYAjVFjeEJfgKFxBq6crhe+MMuMfho/cveZnPBx6KHZ WKgLTyJsBkRbZP+4x2Ud1z8yABacKO3j/yUvKdKaNdmxeNazivSrX7WMp9/MIXyRCWNnvLXr2Yc+ lPtCfu0cBHXQIfmvvjo7Mhymk0/OeV7wgiKNH991eXNOf/XrTW9qOZTmZlU3ApzoKP0MYDIXjBuZ kytdoBv48BlPr3511nlgZB6JYs29cDoAz2tfm9sLm0PX6RaZys9Iy0cvQwfMifPO67pfnACyPvzw PO4xZ4AVmRpfdRkX44Ufff3iF9uDHQKg5KWv9JhuAr0vfSmXxzd7BXTNHzYCv3S6OwcZj/gxjpwZ 8iVX8ho6NNuSls4P6dvAtGzZsjR48ODSCN3f/L548eJScMf2sPTA7QaFIopYDjmkSGPHtgRK0Qxy Z0FbcrvyytZS17nntn4zgYXsDDJDb9LzCB5qecOyYTUqYMgiJDcRKYnPDI7oLvKGB1olXuUxx2Rw 8N1Sj0lg0vnOgIu2qmUoeHjeQYy4Jbwq2L3uddlwUVx9i3qAJkWtRg+UjvFQx/Oel5+TLyMZUYIJ 47O6upILA2YixHeRiDIUXZT11a/m54xOtRzFJzOAYpJzDEQinIoAGMB39tntxwRYxPKLyQXgTR6T SPsMEidE1HTEER2Xd0UBjPpzn5sBtAo0vGrjg69nPzvrhvz0qifLHwzbO97RMSLwPaIOhpP+0APf RWLAoBrBM5IAi45qm6Hh6eNJX975zlZ+5cNTRuqOyIlO8NKjf4xaRNcIKIXRMlbkyXkJ3WRQRbt0 vh0wVeVC9xl87TOyIo7ulnrxZU4aL/0KwNY//dBfuhNOAyCiixEpAGyOnLGn8/RYe/oVc4/sYmnc PO7KAf3e93Jb8Z3TEtE6kPEb2U2f3spjroWd6Yo4g50BXV+Mr89AwLgBTXNBGxzmdmAX0TjwASKc DrIyxzlNyrOHQDbar9q10LeuXlNUV6PMOc5a2J3/fEUwqG8D09q1a0tQOLcczOnNyGnChAnlhDu9 h6UPawqdZ2GNnOcunDTBGSGDK4JiRHgzFNZ6Kq/GRAQ8JjuhK8+I88ZMFp6oAbQkQCme/vSWR9YV Wd5ioITgJipDhy/KrF4RjejDEoaJycPi8XW3jBfLLMozOLxS0Z22gBT+Y8nH8gXviyH2zISjLCaz CE0dPCcACRQoFeXmIXuOLwAtuuEtAwUAAqiAkN8oPOBjkAEj0AVwvGiy5Tky5CaBicqg4OWww3K+ mADaZqi+8Y0iDRiQPytv0pCT8vopOtI2IMQrcPvrX/P46LulEnyYsK0lhI6Eb8Amr8iDV05+xlT7 jIB3jvoPrES5ZMWYACkeNcPPiGpLv8iAUeOs4IuBolfkZcxF6foQyz7t3lcwloCWN0wPjDXjqn1j Tydj2ZNuWW4BIsrzokXoz39+roe+0nHgjSfgDVAZXLzLQ8+Dp4suaunW179epKc9LY8V2dB5OkKn OEJABxCZa4CA7vLKo/wXvpAjnna6TJ+0b27QIe2Rdzg5eLZM1E5W9AAP9MYY8vo5avop6vMXL+Yd uQBRRlgkbM7imw6KmOQlW/NABMFexHibBwyzMcSrZ2RgHpEhYw8URFrkwvADMcCHD2BojmvDmJG3 VQDOcbu+0WM6Kv911+XlWiscol1OiqjS3Dcvzjgj1+07R6RdnZwoEYy8QMOYG1eRmGeci3BS6DuZ 6is5xLh0Jvyp01haJjQHrWaQC7tDjgC2tXx9ZN8GJmnTpk2l13pW81aGKVOmlJPx3h6WHN1UPIYj loosM/CMeHwG0G+8BgpA+Rk2BsYzv1Ee5eT3nMEKz9Rgmkg8Q+8zuts4YGKoUx3huTEKFMEzChDR ggFGvC2ecXeeNaBRnoFmLHhj/gb/FEQ+ABPP5OUtmjw8ruArIiOT0iQVBalfPn1maCNveMMMsXyI R2mSM+7yUXiyFnF4zmjGUpxyDBXPSl79ZVCifZ8DyJRn2BkW5avRKfDTR+0Dknh3hW8TUB3qbrfu rgxwtWSlTWMIMMkQEDIkysdaPvDDA57wQ5YhN/0gN301gRkmfJF9TEjgoTxDVX0/0JnUH7JWnkFE ohHP/MUnHWK8I29448CRcWE4GWJy8ozRxxPgEVEx4GQVulHdKOJzZ91i/CKvuhhK/eTgAGrziLw4 LowZ4Gbg3/Oeji/xq0T3ldGWvlRBiJGLZcN2RI+0r1/mp3nZlW5wTuhtVec5CfHeR1l5gWrUyyjL BxxidYPDqP/a5OAaF86HPqiXfpNLzHkOsUiMfnkOYHwGJoCr8yalzpsP8AUMvbcN/tkNc0D9ojsy 0x7+jVd3G7fok/rkNabxDpUT5Jm5EA4tmeGdDLTTecWlSpxFvMqrj55x5kLW+GqN7Zi+D0w7nxaU 9D89Wjqpae8jToj3cqLjXbnLrKYcXTBInAgRNACobiJ5KLKUZxnJEiPPe0+RC0cTKAEv8uF4Pdxd b32P/rekhXszMEknlfT4kvapqaYOtHnzPqUHuk8ZVexTGsLexBt97den6a67+pWRS7+0YEG/tHBh vzIS3bHymzf3K6PqfqXn3q+MQPu2LDr36/rrW3LZtGnP6VvPadRut/p9AJg2lnRRSdNKurimmno5 0dPLS5qx7W9NNe0pdNk2Wl8DU0qzSzq6ppr6CB1V0vCS1vXuaVWnOvXi1MuB6c6SDkixpdQLcC8r d+WpaS+wvdDe1euwdg/ZPNDdTr9dQdb9vSTfkRsJHg2ymcDuqx15T9EVeanb3fbcHSEbJWzUiC36 O9IXemiTRPt8p9bWpU512snUy4HpwpL+q2kAvGS0jdX2356eJenpS97YUberyI4a26ftKrMraFfU aeeQnYNd/eZUeezC2V3UXfs9ITuGHDru6kzXjpDdgHHG6eGSHUu2MjcaO1bOMQW71GzZbp/vSSXd UVuYOtVpJ1IvB6Zjmizajmmba1ybESf5nQGJg5TOHnhm669dM84BOJth+y9Qk0f0Yquo7ZN2ccVp 5+rVRXFQ07ZZ50zicKhdRg6S2qLb3VZOvzmD5CS8tkVktkDbVm2rqZP2tjEDRFuGnd2wbVdbcSDS FmJnRzyzXZchdF5q333zTiDbNoG1KNLvtujGCfbYZmu7svJxnsEWd3JhhG3/jfMMcRsB6u7OODw4 C2PbqHqdzQlgV6dn3W2btdXYYdvIG/fmGUNbuLXvKEB3gOCshXNrsQPP1ldjy7EwNuq2rdsZEVug bTu2Pdd4k4PzKA5aax+Yq4Ps1WnMHTQm5858hW7FNnYHEemjHWft+f3vkmbVFqZOddqJ1MuB6eAm i7ZjMhIO1tqC6qyQ54w348/QvvGNeVuqJS0HKp0vsETnHBMj5JCmpTX7/h36dP4DYDBgDtWFQbF/ X6QDrJwXEJ0BF8ACAERADGD1XrcqMX4OKSLtO0QHTB0CVifQcHsFg4oXBwWdjHeOgrHDF0PrjIRz Bw7rOoPiDISDeco5QMwoM8LObDjHg9cAUGDqDIvygNRZHoBsWzV5OEfhuqa4g1CeuKqnXUQD1B3O xSfHgOyMg8gQD9riCFSvUep8ut/WbjKU16FYQCz6AQzGEGB3t+0beNi67AxH3KgBmDkC+kN+DgIC I4cN6QOZayvOvzlYqX3nWgCO/tAN5zeAVpyh4TAAO3y5dQQoOk/krIn+20Y9cGB3wPSYkibUFqZO ddrzgOmQJotAgMEGUIxsXNrKUFpSAS5OZYfHLhKJa3SCHNRjhPyNyAQ5PFddkrHkxOhUl3sAAWBh vHjVwDEihnYHDjvfUuxAn3p8ZkwBDHBxyWLk0S9GvnqdkfcgIi1548qj8OjjM2ABZD6LDBjvan/i rjnXvcR1I+TIsAN3QOVQnv61u3ZG+9UrduKgotPy8R3QOqTYVXkg6nqgiDYtyeqr/uuvMdT/h3rf ZzkxDvLGYcO4RkaUHGMpEgQqIkdl8M9ZiHIAMA4gO30PMKuXlLqAFT/4witQUne8V/KeizNUjQg7 HtAGTBfUFqZOddqJ1MuB6YQUQMM7ZTwYvrj3jlG1tMWztaQnMonIwLKRaCDuBwMwIqOq0XeViOt2 XCvCuANAtxtY6tEWA8iwM6aARHTGK+d1t7six9KWtvEgb4BgXMzJUPLwgQCD6toZmzoYzyc+Medz GwWDiCd994KeYQeKlqX0W1SABwDsuhgRAk+eDEQE6lbeXxEjnvv3z6fwgYFlKNGlv+q1dGmZrt1h QZeQijLIn7wtmZIX0Iuoq7vLJ12no3+iFnlFZyJR8hWBqhOgRzTc1Tsu/cKv++O0KWojRw6KcQOS ZAFggARnhRMBlACudrXlr9stLE/6XbTopgNjZmmPDIA3XvEF/Dzj+IRcjSW9if4COX1p8fzYkubU FqZOddrzgMm5kMc0gcGSDwPh/UFcROivpSnLVq4cEgGIgHjuyLJONQJglKvvYnjY8jB46g6P2fsX V74Ao7gZ3C47z7RluafdvzxgLIGA9kUxESHYjSYa8JslJKRdUYM2AGrc/SWvfuKp+m8IRI144r3z 3BlLHj9QI5/4tw94A27KBzBaYtOWJUFykF+flFGHfrX7twbVZUp9Iof4/0KA3xhoq3oJaWcCHK6n QfJqOyIxBl371X9D0BUw4RXf+mvcLIsCPN+BN5mpq3qxbvXOMeAaS7RASZ2i2ABD/SC3cGbUi6/4 Vw4hR+XJkBOhjXByOvZ/v5LW1BamTnXa84Dp7pIOSvUVMTX1Pdq9/6+mTnXak1MfOGDrf82fWNN2 GlHLoNeTCy431NalTnXaydQHgKlOdapTneq0N6UamPpQ2rBhQ5o5c2Z64IEHamHsYWn16tXpyiuv 3Onyq1atav6/szo9dLrnnnvSjBkzduDf7/QsLVmyJM2fP78W8C5I/w/Ipy7oMcwoSwAAAABJRU5E rkJggg== --_006_94C682931C08B048B7A8645303FDC9F36EF2475D15PUEXCB1Bnante_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=4570; creation-date="Thu, 26 Sep 2013 07:46:35 GMT"; modification-date="Thu, 26 Sep 2013 07:46:35 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAYYAAAAWCAYAAADEkTsSAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABFaSURBVHja 7dx5kF1FFQbwtvzHKitVKIUgIDtEFhVlE2UVWWQXENSIAQRUEkEMu4JhE9k3ZY8oSwKCApFdRECI hEWRXZF9DWETSEIgSXt/aQ/vZpg3mUzyCCP3Vp2aeff17T7dfc73ne57+qWc8zqVDG+ke5k0adLw ESNGDB87dmwzHo000sj7QtL//mmu5mqu5mqu5pp+NcTQXM3VXM3VXDNcHSSGqZVcX8mFlVzcSCON NNJIx+WiSi6p5Pn3KjFcWsk8/2uikUYaeTflP/9J+bnnmnHojbz1VspPPZXy1Klztt4XXywyd/q1 ayVT3mvE8Eolm06v/vnnUz7kkJR32CHlHXdM+ZVXUr7zzvL/Tjul/J3vpHz88XPfOK67LuUf/CDl l1+e/bouvzzlnXdO+eGHU37jjZR/9rPS33/9q3fP//vfRZcjj0x5ypTO9PeYY4pe9XuTJ6f8y18W XW+9ddbrfPTR8uyYMTMve/XVKR944HsTKJ58MuU332x9/uMfU95995RffbXvdarv8cf79izA2muv lH/9694/M3Zsyscd17f2br65+OvRR/ft+cMP7/uzfRF2NzvPwyT+NmnSnG3ffJ155rszBtdem/KQ ISl/97spP/usex+p5MbOEcP48ePzLbfcUoH5nbNQ7S3TVwuAhnFefHHK999fSODBB1N+4YWUv/jF Ak5nnZXyV79aOgdEAdJttxVC6clRHnggVXqlfM89rfv/+EfKjzyS8uuvF8coA1QAWlkO367OZ55J +VOfSvmqq0pZ9bg/cWLKd91V7r30Urmn3rvvbtUbZQl9Lrww5U9+MuXLLivATq/VVkv5d7+bsc14 /umnW/dELn/4Q8rHHpvyZz7TnqgmTEj59tvL856J++PHl3vGsSeHueGG0t+//KX0xb1p08q4brJJ ab9eJ7A3L3XANEfa8l2MO0D56U9L2+5zuu7av/felFdYoZRRh7mvf1efL+MUbZuDv/61BdKCDHWw tXj+oYfK88aH7rPiYOZ2yy1T/sUvig1pz/wsv3zKV15Z6h037p1t1eegO/ntb1P+yldKWb4QhK8f 7ulHlAVQ2nbfWBibESNSXmONUs5Y8wFjjGzYpzGxSvC8OURm7K6uwxNPtGyDvbsnWHFPHVFO/wQI fHRm46Uff/tbqw7+AqRWXLHMGV2iLF2Vc1+UHnMbffS8oMh3oVdXMg3bMA7sTbn11y++FffClsM2 oi3YY+yVcV/b/AgR8vtYMXg22tc3euknWzYvxjpIxJjzFz6vfODWY4+lfMUVM/afsCfl7rijtKdO bUV7M7NXK5Dof+g7enTKK6+c8vDhhYz0qZQ/qDPEMG7cuIr5j86DBw/OQ4cOrSLYI6uOvdSLai9+ e4l2xhkpH3poyqefXiYgHGK33VLefvuU99yzGIN7P/lJyt/7XspbbZXySSe1HxwTe8IJKe+xRyEb hub+vvumvMACJRJW/+9/n/I//1naV1YU0xNYfvnLZRUzeHARk8tJDjoo5R/+MOXvf7848p/+lPKi i5bPyvkLPBgHxv7Rj1IeOLAYW9Str/SJz5wTgNLLMwxWW6JofbLiAJzh7F2FUe+3X4lk99mnGBTC FbGr89vfLhJO0VX049OfLmV22aUQRMzN3nuX8Y2yvjNP+oDMAzysaPR/u+1SXmaZoiuiRw7m8Vvf Kv1qR2yIadCgooOx4DTGJcZVlHz99Sn/5jcpr7deyueeW+aWfdx3XyFeYyBSsipFDsp/4xtlDDhs 6MvZr7mmgFZPjmduF1ww5S99qdhQkOY665T+kx//uBA2Z4451A7gbVevOf7Yx0q/jC1gsdXDzmO+ Ro4swHreeWUelV1kkeL47Is9GBPjCjD3378AgvnfdtuUjzii9PPEE1PedNOif91e6K1O44Jk2ID5 0r45EyxEef3eeOOex0of6MZW1bvkkqVt3332s6XebbZJ+e9/b5Fj9FWw6N4556Q833zFZ4YNK+Nh bE85pZT95jdbc8AO9Ulb6ufvCGHeeUtwaRwEE+zggguKbSjPZl57rZAdmweg5vHkk0t5+qy5Zivo 0T4bM2crrVRsz7zQw/jDiOHDW8S6+OIlmKBXrJb1dZVVShsxXsiAzsoZ7whCl122+As91NtuZQrn 9NHz7APx8G96wj19Na5soDyzUy7veucwMQwZMiSPGjXq7c+DBg2qOndHL6q94O3IXmTCeESgX/ta KwLQCYAydGir4waFgTB8YNxuzw8r235i6KIw4BhEJFLB6BHtG8AttihlOURPS1zEEM/Sw8AjB7qY kCWWaEVawAfQ+P+oo4o+665bwNk9S1MgVScGEWd83nrrlDffvOjFWIPoRCix+mGU7YzE90CJoX3u c8XIghjUyVg4fbutKCBsnGOe/I9EgxhOPbX1nXE44IAC4htuWO4DY0QY9V16aSHss89Oef75U/7V r2a+fF911db2mrGnr3GKaOzGGwvohLMCmdNOa31eaqkWMS68cCHHP/+5Bd7G4KabWm2ao5//fOZR 8Ne/3go2QoBDzA0ntvVoDABI2GGdTLubL3ZYvwfUBBCeBwrA3LgBtChDf+QqUma/7iFOIGXOAVL4 BP+qR9abbdbyC75mBRXfI1XkDoC1rx62UyeGeL6dXHJJCWLis8gasZsb4+Uewj7//AJWiF1b5ie+ JxttVFZo9VUbokV8xse2I2JDfrGyBOju+3+DDVorhVh1L730jLYRpK3tsO0QOKGOOuHxe2OgrLGl P+Kk0667lh2AKG/FErsJdYE1hx3W+mwsjHd8No/GEKlZzbiHdOrzVBdBY31rim8IdGBE2MGMsl0l b855Yhg5cmQVAZw4fStpzJgxFcvtUHXgwV5Ue0UlH5g+wdiNk4nwAKetFg4sYrEXicljScoQReYi UU5tmd5u7w6oAmR1rr12iUABMfYVWSAgEQBC4mjqtK3lu3ZLNM8iMZGvCBFAmlzGDFBEfIyRQwFt kR0n4PCMkJNgbP1dffVi3AxWxPT5z6d88MGtrS/gAmjpBbD0FSiYeFEEAxK5Blh3FUaFVIGRctpi XAxWnUCLzu1WDABHfxmmdyKe1y/OAICMPyC0FDYnolGGuNxyxSlFt9qhq7oAH6e1+qAX0PN916V0 CF3pHStJRKke400n9frOHNBJNIkUOIc54rjmyCqTHQQJAhjkpW1Ah7DCvtTfm/c8wAQgiP7MnWhd vwUCMfdWwtpCmGFbEVR0J8AdKOkX8gI2gN12jef1G9loUx+1Fdt0gIptWB0AvS98oegnuo5ghF1a tQFAtsQubEWKUvkYXUXM6kS45tAK1qpA+0hJgMFeBT/qt32mfAQ73W0H8g1bn8rxLSClHwDduCFO c4g0gK+2gJ+553Pm0UqIT4etIBD+RGd9EgDRgf+IxKMP6mff7NI8B4kao7XWKuPINmzDAX9zLxgx 1rEKMZ8XXVTaoXe8sDe/MAaBKm8c4QigFzTaMQjfdJ/9aZ8NwCJ4J8Cw4oEH7I89Ixb6my8rGVt+ glk2AS+NhT52N97mz3jH83ZCzLW+s09+hEBbK4Y9KpnWmXcMo0ePnr6VNGzYsMoQ7u1ltfdXssR0 gI1tAUunYHhRhXuYN4iBMACAaTUBWNqtGBiusgDIpIuaGTojiG2g2M8Pp1AnoGwHDACAjsgKaNEb uHJeOplUqwBEwwC0AcQZmP8toW1T0YtRA1bbLwgqlvAkXvhyIIZLL4YX4wD8lKOH521ttHu5GMtk OmmfoXIS9+ncDpQJ4ABUIlUrIu1zMoYfujJ4YM/o1Qmc3AcEETH6bJzseXJUYGws6YL42kXRnNA4 AXZ1xMtuKwnj4p7VByfnAFY0Agq60Nk8mid6kSAANgZ43LMCjXGlGyJsF43VBYghOHOoX0CBbSDP mPtRo0pQYKtAW2yPU/a0F89WPWu+4j2FQMLzVovaifb5RtixZ9k4+7N6Q1x0Y9cxdvTxP9KMdggQ i3dY7NU9z9u+pT/Cj7m1TQKokVI8T0Kvdi9ezaNy6uCz7NkcsBNz4H86aF9b5hVZCCaAYLQTL8vp wP+QCPv2HTvkM2EvykbGDx8xP/QHyOHPYRv0ECQC+2hL9B4BUn372KoAsBr/2GY11tpCIKG/srY4 452O9pUF9IjcHEedxgcxqTd8BnbBLIGiz+xIP8K22tkQe4k6Y/cltqcIgm3tEpzUmXcMfb8sX/ac pZd+jTTSSUEIwKjdCqqRRv6/ZNlKnnyvEYPriUq2qmTVRt7Xskoly1cycK7K668PrKK2gXNdj0Ya 6bysUMl5s4XeHSQG112VXFXJdY28L+XaXHKpX8vN1VzN1X+uDhLDDZUsVsmHKhnQJ5k2bUCePHnW npk0aUCeMKE86/OUKUXcmzhx5s8/++yAfOutA/qsc3+Sl18ekG++efbqmDq1jGuM94zy4Uo+WslR jac1V3P1o6tDxDAhl22k2dsn87JJplJvT0bLVJAFIUtItocXUV4ayyd2T1qYjJv6Yaiu4kWSF7+d 3gOUvTAnTlnPjsiMmd3Tx3FqVLpc+0OJC1RyT+NtzdVc/eTqEDHcXsl8OQ4yeXsvOyVOsvorQ0Em TRxuI050KueNvoMvMkqk1AF55b3x7wmklIvDNN7US13zTORjS6eTPSBDoF1KIZ3q5w+IVDJ6yRxA Pu3al75KT5lF0tziRafMGs/ql3RCGRbyuGXwuFc/WNRVlJWZ4sCOTBzl6eM75yLoVf8JCnnNysjS oYPxk6Uiz1q5yAyT+YFwI8OISAmkpywUWU/6Eel7UuG0JbW1nsklG0c5KXeREdK9nNZ4W3M1Vz+5 OkQMl2TnGKRtSRGVsiYl0gEVQIMApCBKh5TrK8VNeqMUtMjplloYx/flb0s1c6isp9+bAepWDFI1 A/CAoZOJ0jidnQCIrTzfdxKDFLX6QSTti4blUANymS3t2pdaByCdQdAv9UlHk85JN9/7675c+/g9 mp7IBjFIk/MTG3KgpRcCd4fL5NDTi77SP4G5z+qUuifXGqlYMUmTQxTOU0SaoUhfTnz9py/MkQNB UiHlyUszVLcUR3U7b4CkpIqaKymc5tfhv57PCOxWyVuNxzVXc/WDq0PEMDLH4REHWeQEA1QABTxE tYAGMPpZhDj1XP9RNznhtlpEx8DaPaDV7icWkAuwcq7AX9tGInGHtIAwgFZ//YRku/MM8vvrv31E z9C36+8d1QXpIa84gCbKFtU7jxBlEKVIXd56/XTtzNIonfqtH85zuMu2GL0c8JO/jLhiBWaVggjj FDZyca7EoZ36CqHriUn6Guf6PaSKULTleSsS+fHx8xJWYA59Rdvm4p1nUAZV8kbjcc3VXP3g6hAx jK7kg9O3gpwGBiKiTZGmw2lWCrZ6gOQ885RtDysGwB0HtkS3tqEcGnGaF4gutlhZeXQHnN4bOMWJ YGxtxG+0eMfgeDxgbLeFFIJIkJDffIlDSLZinOKMFUMcaulOHG6zOqEroEQODvEAZls0+qtepIdg HJwRcTtF3N2R+lgxiPY/8Ymy8ghisnJAVPQS2SMlKw+frbyQkdWLsr4H7lYYH/940Q/h0WuhhVo6 eacD+P0OjZVNbP0hHT+poG5bR1Z8tpus+jzrUJzfqzHGyjs1S4cZV2Z75GbF0FzN1T+uDhHD3ZUs nuOnJuxNA4rYMhHVi5ptidgiin1r2xuAhijjtCKQRyi2SQCUdw/tgBloetZWSpxw1aY6nMqc2c8m W50AROXVgRi8UA2go2v9V0C7CtKgI13pHL/JggzViwTqv9pq7187Tl+2WzFoDznRyZgF+EZ79HIv 9HJqVTvK+2Ew23kI1s8MaA9R0i/mwGc6BDEgMFth6qj/Gi3y1pZTn0Fittk8a1uLDvGuwzsaesxI DCMbb2uu5uonV4eIwS/67ZSb04dzR5CAVc+AAeUHzOa+Tg7dPNR4W3M1Vz+5/guiRFtkzCyCTQAA AABJRU5ErkJggg== --_006_94C682931C08B048B7A8645303FDC9F36EF2475D15PUEXCB1Bnante_-- From jguichar@cisco.com Thu Sep 26 07:03: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 45F7011E80D2 for ; Thu, 26 Sep 2013 07:03:05 -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=[AWL=-0.000, 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 u-8cYrDPl6DR for ; Thu, 26 Sep 2013 07:02:55 -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 200F821F9E40 for ; Thu, 26 Sep 2013 07:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40644; q=dns/txt; s=iport; t=1380204125; x=1381413725; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=X5+A/ma80+GG5Ns0hlsmkpcUBXQ5/bXthrR6BFZk6uQ=; b=ES+CMitQ4foykLu8V563bQv2NLQWdX17NEwFEzk6VFqHHsQF0apio0J6 TJvtwwYXD3oYOS+/YvKl4flhqBZVIN9YoO3Y5PqOqVvVUup7XHTWeUqqA IK8P9TOCN8whALepJ+uAvdfPwUT+K3tVlU+nrt+NH+qlsnXS3PstZ3Y7V w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFALM9RFKtJXG//2dsb2JhbABbgkNEOFKER4FDukmBJBZ0gicBBAEBARdLAgcEBxIBCBIQFgEGLgsUAw4CBA4FCId+DL0TBI4IFoECLQQHgx2BAQOUIJVVgTuBaYFpCBci X-IronPort-AV: E=Sophos;i="4.90,986,1371081600"; d="scan'208,217";a="264770082" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 26 Sep 2013 14:01:52 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8QE1nU7015880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 14:01:49 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 09:01:49 -0500 From: "Jim Guichard (jguichar)" To: Thomas Narten Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXSUUAgADoSAA= Date: Thu, 26 Sep 2013 14:01:48 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6A0EFD@xmb-rcd-x01.cisco.com> In-Reply-To: <201309252010.r8PKAOFW023454@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.181] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F6A0EFDxmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 14:03:07 -0000 --_000_68B171751455884590F8E38E96416F363F6A0EFDxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thomas et al, I have updated the charter as follows to capture the comments/suggestions m= ade over the last few days. Please review and let me know if there are any = outstanding issues not covered by the charter. Thomas, some responses inline below in response to your original email. Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. Service delivery is currently both= a technical and organizational challenge that involves significant modific= ation to the network configuration. Services are typically implemented by t= he ordered combination of a number of service functions that are deployed a= t different points within the network. Today, a common deployment model has= service functions physically inserted on the data forwarding path between = communicating peers. Going forward, however, there is a desire to move to a= different model, where service functions are not required to reside on the= default data path and traffic is instead steered through services, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a Service Function Chain is instantiated via the = selection of specific service function instances and the network nodes on w= hich they are provided, thereby forming a service topology: this is called = a Service Function Path (SFP). The service functions may be applied at a sp= ecific layer within the network protocol stack (network layer, application = layer, etc.). The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment. It will produce a framework for serv= ice function chaining that includes the necessary protocols or protocol ext= ensions to convey the service path and service path information to nodes th= at implement service functions, as well as mechanisms for steering traffic = through service functions. The working group will also examine what informa= tion needs to be gathered from the network and service functions in support= of service function chaining and how that information may be made availabl= e to nodes that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem s= pace to be addressed by the WG including example high-level use cases. Addi= tionally, the WG will normalize nomenclature and definitions for service function chaining. 2) Architecture: This document will provide a description of the architectu= ral building blocks and their relationships including interconnection, plac= ement of capabilities, management, diagnostics, design analysis, and securi= ty models, as well as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describ= e the single service-level data plane encapsulation format for conveying th= e service function chain and the service function path, and for communicati= ng context information between nodes that implement service functions. It i= s intended that the encapsulation be agnostic to the layer at which it is a= pplied and the service that is being constructed. That is, the same encapsu= lation may be used on a service function path realized at the network layer= or at any other layer, and the same encapsulation will apply for the const= ruction of service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to descri= be requirements and protocols necessary to convey information to service fu= nction implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be= carried out in the working groups responsible for the protocols being modi= fied in coordination with this working group, but may be done in this worki= ng group after agreement with all the relevant WG chairs and responsible AD= s. 5) Manageability: This document will address the management of service func= tion chaining including relevant MIBs and YANG information & data modules, = and service function chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the = problem statement and core use cases for Service Function Chaining. Request the IESG for publication of Informational documents defining the ar= chitecture for SFC and describing the framework and requirements for a gene= ric service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying t= he generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying cont= rol plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC = manageability including diagnostics, and MIB and YANG information/data mode= ls to IESG. Request the IESG for publication of Informational applicability documents d= efining how the protocol elements developed by the WG may be combined with = other IETF protocols to satisfy the use cases. On 9/25/13 4:10 PM, "Thomas Narten" > wrote: Jim et al, Here are some specific suggestions on the charter (this is from the version posted Sept. 13). I think they are all editorial, crisping up the language used and consistent with the discussion on the list. Proposed Service Function Chaining (SFC) WG Charter Networks, servers, storage technologies, and applications, have all undergone significant change in recent years with the introduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the physical insertion of equipment on the path into a mechanism for causing the path or data to transit specific physical or virtual nodes on which the service functions are performed. Services are typically implemented by the ordered combination of a number of service functions that may be implemented at different points within the network. Service delivery is currently both a technical and organisational challenge that involves significant modification to the network configuration. Suggest changing the above as follows: 1) change sentence: The process of service delivery is changing from the physical insertion of equipment on the path into a mechanism for causing the path or data to transit specific physical or virtual nodes on which the service functions are performed. To: Today, a common deployment model has service functions physically inserted on the data forwarding path between communicating peers. Going forward, however, there is a desire to move to a different model, where service functions are not required to reside on the default data path and traffic is instead steered through services, wherever they are deployed. Jim> agreed and reflected in the new charter text. 2) Reorder the existing text in the pargraph so that teh revised text goes at end of first paragraph, i.e., resulting in: Networks, servers, storage technologies, and applications, have all undergone significant change in recent years with the introduction of virtualization, network overlays, and orchestration. Service delivery is currently both a technical and organisational challenge that involves significant modification to the network configuration. Services are typically implemented by the ordered chaining of a number of service functions (e.g., firewalls, load-balancers, etc.) that are implemented at different points within the network. Today, a common deployment model has service functions physically inserted on the data forwarding path between communicating peers. Going forward, however, there is a desire to move to a different model, where service functions are not required to reside on the default data path and traffic is instead steered through services, wherever they are deployed. Jim> agreed and reflected in the new charter text. For a given service, the abstracted view of the required service functions and the order in which they are to be invoked is called a s/invoked/applied/ ??? Jim> agreed. Service Function Chain (SFC). Since a given service function may be available on more than one node within a network, a ServiceFunction Chain is instantiated via the selection of specific service function instances and the network nodes on which they are provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be applied at a specific layer within the network protocol stack (network layer, application layer, etc.). I think talking about "layers" here is confusing and not really needed. SFC doesn't really care about what layer is used. It only cares about steering traffic to a service -- what that service does with that traffic is the service's own business. Suggest tweaking: Old: The service functions may be applied at a specific layer within the network protocol stack (network layer, application layer, etc.). better: Service functions are applied to the traffic flows that are directed through them. What the service function actually does to such traffic is service-specific and not of concern to SFC. Jim> I did not use this text as I believe consensus on the layering issue w= as reached on the alias and the original text reflects this consensus. 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. 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. The above doesn't actually include the "steering" part. Suggest: Old: 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. New: 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 service path and service path information to nodes that implement service functions, as well as mechanisms for steering traffic through service functions. Jim> agreed and reflected in new charter text. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high-level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining. 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level encapsulation protocol for conveying communicating information between nodes that implement service functions. Better: 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path associated with data packets, and for carrying context information between nodes that implement service functions. Jim> yep. It is intended that the encapsulation be agnostic to the network layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realised at the network layer or at any other layer, and the same encapsulation willapply for the construction of service function paths regardless of the actual service. If I understand the list discussion, I think the above really just means: It is intended that the encapsulation be agnostic to the underlying network technology (i.e,. IP, MPLS, etc.) being used for transport as well to the specific services being supported. 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: This document will address the management of service function chaining includingrelevant MIBs and YANG data modules, and service function chaining diagnostics. Proposed Milestones (all dates TBD): Request the IESG for publication of an Informational document defining the problem statement and core use cases for Service Function Chaining Request the IESG for publication of Informational documents defining the architecture for SFC and describing the framework and requirements for a generic service function chaining encapsulation protocol. Request the IESG for publication of a Standards Track document specifying the generic service function chaining encapsulation protocol. Request the IESG for publication of Informational documents specifying control plane requirements in support of specific SFC use cases. Request the IESG for publication of an Informational document defining SFC manageability including diagnostics, and MIB and YANG data models to IESG Request the IESG for publication of Informational applicability documents defining how the protocol elements developed by the WG may be combined with other IETF protocols to satisfy the use cases. Thomas _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_68B171751455884590F8E38E96416F363F6A0EFDxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Thomas et al,

I have updated the charter as follows to capture the comments/suggesti= ons made over the last few days. Please review and let me know if there are= any outstanding issues not covered by the charter. 

Thomas, some responses inline below in response to your original email= . 

Service Function Chaining (SFC) WG Charter

Networks, servers, storage technologies, and applications, have a= ll undergone significant change in recent years with the introduction = of virtualization, network overlays, and orchestration. Service d= elivery is currently both a technical and organizational challenge that involves significant modification to the network confi= guration. Services are typically implemented by the ordered combination of = a number of service functions that are deployed at different points within = the network. Today, a common deployment model has service functions physically inserted on the data forwardin= g path between communicating peers. Going forward, however, there is a= desire to move to a different model, where service functions are not = required to reside on the default data path and traffic is instead steered through services, wherever they are deployed.

For a given service, the abstracted view of the required service funct= ions and the order in which they are to be applied is called a Service= Function Chain (SFC). Since a given service function may be available= on more than one node within a network, a Service Function Chain is instantiated via the selection of specific service = function instances and the network nodes on which they are provided, t= hereby forming a service topology: this is called a Service Function P= ath (SFP). The service functions may be applied at a specific layer within the network protocol stack (network layer,= application layer, etc.).

The Service Function Chaining (SFC) working group will develop new app= roaches to service delivery and deployment. It will produce a framework for= service function chaining that includes the necessary protocols or protoco= l extensions to convey the service path and service path information to nodes that implement service function= s, as well as mechanisms for steering traffic through service functions.&nb= sp;The working group will also examine what information needs to be ga= thered from the network and service functions in support of service function chaining and how that information may = be made available to nodes that implement the service functions.

Specifically, the SFC WG is chartered to deliver the following:

1) Problem Statement: This document will provide a summary of the= problem space to be addressed by the WG including example high-level = use cases. Additionally, the WG will normalize nomenclature and defini= tions for
service function chaining.

2) Architecture: This document will provide a description of the&= nbsp;architectural building blocks and their relationships including i= nterconnection, placement of capabilities, management, diagnostics, design = analysis, and security models, as well as requirements on the protocol mechanisms.

3) Generic Service Function Chaining Encapsulation: A document will de= scribe the single service-level data plane encapsulation format for conveyi= ng the service function chain and the service function path, and for commun= icating context information between nodes that implement service functions. It is intended that the encap= sulation be agnostic to the layer at which it is applied and the servi= ce that is being constructed. That is, the same encapsulation may be u= sed on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply fo= r the construction of service function paths regardless of the actual = service.

4) Control Plane Mechanisms: A set of documents will be developed= to describe requirements and protocols necessary to convey informatio= n to service function implementation points. Where possible, existing = IETF
protocols will be used and extended. All protocol extensions work shou= ld be carried out in the working groups responsible for the protocols&= nbsp;being modified in coordination with this working group, but may be don= e in this working group after agreement with all the relevant WG chairs and responsible ADs.

5) Manageability: This document will address the management of se= rvice function chaining including relevant MIBs and YANG information &= amp; data modules, and service function chaining diagnostics.

Proposed Milestones (all dates TBD):

Request the IESG for publication of an Informational document def= ining the problem statement and core use cases for Service Function Ch= aining.

Request the IESG for publication of Informational documents defin= ing the architecture for SFC and describing the framework and requirem= ents for a generic service function chaining encapsulation protocol.

Request the IESG for publication of a Standards Track document sp= ecifying the generic service function chaining encapsulation protocol.=

Request the IESG for publication of Informational documents speci= fying control plane requirements in support of specific SFC use cases.=

Request the IESG for publication of an Informational document def= ining SFC manageability including diagnostics, and MIB and YANG inform= ation/data models to IESG.

Request the IESG for publication of Informational applicability d= ocuments defining how the protocol elements developed by the WG may be= combined with other IETF protocols to satisfy the use cases.


On 9/25/13 4:10 PM, "Thomas Narten" <narten@us.ibm.com> wrote:

Jim et al,

Here are some specific suggestions on the charter (this is from the
version posted Sept. 13). I think they are all editorial, crisping up<= /div>
the language used and consistent with the discussion on the list.

Proposed Service Function Chaining (SFC) WG Charter

Networks, servers, storage technologies, and applications, have all
undergone significant change in recent years with the introduction
of virtualization, network overlays, and orchestration. The process
of service delivery is changing from the physical insertion of
equipment on the path into a mechanism for causing the path or data
to transit specific physical or virtual nodes on which the service
functions are performed.  Services are typically implemented= by the
ordered combination of a number of service functions that may be
implemented at different points within the network. Service delivery
is currently both a technical and organisational challenge that
involves significant modification to the network configuration.


Suggest changing the above as follows:

1) change sentence:

    The process of service delivery is changing fr= om the physical
    insertion of equipment on the path into a mech= anism for causing
    the path or data to transit specific physical = or virtual nodes on
    which the service functions are performed.

To:


     Today, a common deployment model has service = functions
     physically inserted on the data forwarding pa= th between
     communicating peers. Going forward, however, = there is a desire to
     move to a different model, where service func= tions are not
     required to reside on the default data path a= nd traffic is
     instead steered through services, wherever th= ey are deployed.

Jim> agreed and reflected in the new charter text. 



2) Reorder the existing text in the pargraph so that teh revised text<= /div>
goes at end of first paragraph, i.e., resulting in:

     Networks, servers, storage technologies, and = applications, have
     all undergone significant change in recent ye= ars with the
     introduction of virtualization, network overl= ays, and
     orchestration.  Service delivery is= currently both a technical
     and organisational challenge that involves si= gnificant
     modification to the network configuration.&nb= sp; Services are
     typically implemented by the ordered chaining= of a number of
     service functions (e.g., firewalls, load-bala= ncers, etc.)  that
     are implemented at different points within th= e network.  Today, a
     common deployment model has service functions= physically inserted
     on the data forwarding path between communica= ting peers. Going
     forward, however, there is a desire to move t= o a different model,
     where service functions are not required to r= eside on the default
     data path and traffic is instead steered thro= ugh services,
     wherever they are deployed.

Jim> agreed and reflected in the new charter text. 


For a given service, the abstracted view of the required service
functions and the order in which they are to be invoked is called a

s/invoked/applied/  ???

Jim> agreed. 

Service Function Chain (SFC). Since a given service function may be
available on more than one node within a network, a ServiceFunction
Chain is instantiated via the selection of specific service function
instances and the network nodes on which they are provided, thereby
forming a servicetopology: this is called a Service Function Path. The=
service functions may be applied at a specific layer within the
network protocol stack (network layer, application layer, etc.).

I think talking about "layers" here is confusing and not rea= lly
needed. SFC doesn't really care  about what layer is used. I= t only
cares about steering traffic to a service -- what that service does
with that traffic is the service's own business. Suggest tweaking:

Old:

  The service functions may be applied at a specific layer w= ithin the
network protocol stack (network layer, application layer, etc.).

better:

  Service functions are applied to the traffic flows that ar= e directed
  through them. What the service function actually does to s= uch
  traffic is service-specific and not of concern to SFC.

Jim> I did not use this text as I believe consensus on the layering= issue was reached on the alias and the original text reflects this consens= us. 


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.  The working= group
will also examine what information needs to be gathered from the
network and service functions in support of service function chaining<= /div>
and how that information may be made available to nodes that implement=
the service functions.

The above doesn't actually include the "steering" part. Sugg= est:

Old:

    The Service Function Chaining (SFC) working gr= oup will develop new
    approaches to service delivery and deployment,= by providing a
    framework for service function chaining and th= e necessary
    protocols or protocol extensions to convey the= service path and
    for communication between nodes that implement= service functions.
    
New:

    The Service Function Chaining (SFC) working gr= oup will develop new
    approaches to service delivery and deployment.= It will produce a
    framework for service function chaining that i= ncludes the
    necessary protocols or protocol extensions to = convey service path
    and service path information to nodes that imp= lement service
    functions, as well as mechanisms for steering = traffic through
    service functions.

Jim> agreed and reflected in new charter text. 


Specifically, the SFC WG is chartered to deliver the following:
1) Problem Statement: This document will provide a summary of the
problem space to be addressed by the WG including example high-level
use cases.  Additionally, the WG will normalize nomenclature= and
definitions for service function chaining.
2) Architecture: This document will provide a description of the
architectural building blocks and their relationships including
interconnection, placement of capabilities, management, diagnostics,
and security models, as well as requirements on the protocol
mechanisms.
3) Generic Service Function Chaining Encapsulation: A document will
describe the single service-level encapsulation protocol for conveying=
communicating information between nodes that implement service
functions.

Better:

3) Generic Service Function Chaining Encapsulation: A document will
describe the single service-level data plane encapsulation format
for conveying the service function chain and the service function
path associated with data packets, and for carrying context informatio= n
between nodes that implement service functions.

Jim> yep. 


It is intended that the encapsulation be agnostic to
the network layer at which it is applied and the service that is being=
constructed. That is, the same encapsulation may be used on a service<= /div>
function path realised at the network layer or at any other layer, and=
the same encapsulation willapply for the construction of service
function paths regardless of the actual service.

If I understand the list discussion, I think the above really just
means:

    It is intended that the encapsulation be agnos= tic to the
    underlying network technology (i.e,. IP, MPLS,= etc.) being used
    for transport as well to the specific services= being supported.
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<= /div>
protocols will be used and extended. All protocol extensions work
should be carried out in the working groups responsible for the
protocols being modified in coordination with this working group, but<= /div>
may be done in this working group after agreement with all the
relevant WG chairs and responsible ADs.
5) Manageability: This document will address the management of service=
function chaining includingrelevant MIBs and YANG data modules, and
service function chaining diagnostics.
Proposed Milestones (all dates TBD):
Request the IESG for publication of an Informational document defining=
the problem statement and core use cases for Service Function Chaining=
Request the IESG for publication of Informational documents defining
the architecture for SFC and describing the framework and requirements=
for a generic service function chaining encapsulation protocol.
Request the IESG for publication of a Standards Track document
specifying the generic service function chaining encapsulation
protocol.
Request the IESG for publication of Informational documents specifying=
control plane requirements in support of specific SFC use cases.
Request the IESG for publication of an Informational document defining=
SFC manageability including diagnostics, and MIB and YANG data models<= /div>
to IESG
Request the IESG for publication of Informational applicability
documents defining how the protocol elements developed by the WG may
be combined with other IETF protocols to satisfy the use cases.
Thomas

_______________________________________________
nsc mailing list

--_000_68B171751455884590F8E38E96416F363F6A0EFDxmbrcdx01ciscoc_-- From mn1921@att.com Thu Sep 26 07:10:17 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C09B21F8416 for ; Thu, 26 Sep 2013 07:10:17 -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 0s97A+KAgSgN for ; Thu, 26 Sep 2013 07:10:01 -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 4B7EB21F856A for ; Thu, 26 Sep 2013 07:09:47 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 03044425.2aaac5401940.2039964.00-571.5456522.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 26 Sep 2013 14:09:52 +0000 (UTC) X-MXL-Hash: 5244403000cf1094-9828c1508eb299b136085c6987a546eecf72d2c7 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 82044425.0.2039954.00-105.5456311.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 26 Sep 2013 14:09:44 +0000 (UTC) X-MXL-Hash: 524440281adac277-9d12b390fd4e8703dd7b7bb8629ce5f546d9d6e6 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 r8QE9hIU028906; Thu, 26 Sep 2013 10:09:43 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8QE9UOE028680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Sep 2013 10:09:40 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (MISOUT7MSGHUB9A.itservices.sbc.com [144.151.223.62]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 26 Sep 2013 14:09:08 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.03.0158.001; Thu, 26 Sep 2013 10:09:06 -0400 From: "NAPIERALA, MARIA H" To: Thomas Narten Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXOIIA///I2MCAAEu+gIAAzF7A Date: Thu, 26 Sep 2013 14:09:01 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012A37B8@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <68B171751455884590F8E38E96416F363F68DCFA@xmb-rcd-x01.cisco.com> <201309252010.r8PKAOFW023454@cichlid.raleigh.ibm.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A32C0@MISOUT7MSGUSR9I.ITServices.sbc.com> <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com> In-Reply-To: <201309252124.r8PLO5F5001572@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.50.164] 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=Rv1y2laK c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=xu9cFvUiMcUA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=FFZ-zzI3G] X-AnalysisOut: [zMA:10 a=VnNF1IyMAAAA:8 a=48vgC7mUAAAA:8 a=eofk_CvhDKd31Cu] X-AnalysisOut: [llhcA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA] X-AnalysisOut: [:10] Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 14:10:17 -0000 Tom, et al., we should keep open the option of having a solution that specifies how meta= data data is carried but does not dictate how the service chain path is rea= lized.=20 So I vote for changing the language in the charter for item 3): "A document= will describe the single service-level data plane encapsulation format ...= ", as it is solution-specific. Maybe the easiest would be to remove this it= em from the charter. Maria > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Wednesday, September 25, 2013 5:24 PM > To: NAPIERALA, MARIA H > Cc: Jim Guichard (jguichar); nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter >=20 > "NAPIERALA, MARIA H" writes: >=20 > > The group charter's write-up says that: "The Service Function > > Chaining (SFC) working group will develop new approaches to service > > delivery ..." (i.e., not one "approach" but "approaches", which > > means more than one). >=20 > > But then is states that a document will be developed such that it > > "will describe *the(?) single* service-level data plane > > encapsulation format for conveying the service function chain and > > the service function path associated with data packets, and for > > carrying context information between nodes that implement service > > functions". >=20 > > How to do you reconcile those two statements? >=20 > Note: this inconsistency existed in the earlier charter, I didn't > introduce it. :-) >=20 > I think for the service plane data encapsulation, we should aim for > one. I'm understand the concern about writing that into the charter in > absolute terms, as I think the WG should have room to discuss and it > may be too early to be definitive. But unless there is compelling > reason, we should have one encap. (BTW, nothing new here.. this is > normal IETF.) >=20 > That said, I don't see the need for more than one encap. Does anyone > think we do? And if so, why? >=20 > > In my opinion, we should open the door for more than one solution to > > service chaining. >=20 > Ah, "solution to service chaining" (to me) is more than the encap, > including the control plane and related stuff. So even if we develop > one encap, that doesn't necessarily mean there is only one > "solution". So the inconsistency may not be quite as strong as first > seems. >=20 > Suggestion. change: >=20 > A document will describe the single service-level data plane > encapsulation format ... >=20 > To: >=20 > A document will describe a service-level data plane encapsulation > format ... >=20 > this is a bit weaker, but still does (implicitely) suggest one encap. >=20 > or, if folk think this is not good enough, we could add text saying we > are aiming for one, and will only do more if ... >=20 > But personally, I think it would be fine to have the charter say one > encap, and if the WG concludes that one encap isn't what is needed, > then recharter. We shouldn't look at rechartering as "impossible". We > just need to be able to make the case that more than one encap is > necessary. If we can do that, I wouldn't think rechartering would be a > big deal. >=20 > Thomas From jguichar@cisco.com Thu Sep 26 07:12: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 5C6D221F842F for ; Thu, 26 Sep 2013 07:12:55 -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=[AWL=0.000, 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 Ai4aJECqbvuQ for ; Thu, 26 Sep 2013 07:12:49 -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 AC4F021F90CF for ; Thu, 26 Sep 2013 07:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3511; q=dns/txt; s=iport; t=1380204767; x=1381414367; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=neorXww4/31ZEPRzryn/a3kf/sVrUO3i+qBLDIpzpFY=; b=h+wDlBEabK/KUiGVc3aXlB709HNGgNxj/1UPiKKgOoUDVmBFwHdh0fci Thzrd9J8YIHJcQka9nMG2+nQxhlzIp9Msw+L28e3DR43ABFu6OyYPly43 Sdd/FkhQGW1a6oQlr2KqFVFd7T7m/mh9v4yWZepKly4xxuYMKbMzQFJPM E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAJQ/RFKtJXHA/2dsb2JhbABbgweBCsBTgSQWdIIlAQEBBDo/DAYBCBEBAwEBCxQJORQDBggCBAENBQgTh2u9JY8eAjEHBoMXgQEDqXWDJIIq X-IronPort-AV: E=Sophos;i="4.90,986,1371081600"; d="scan'208";a="264809158" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 26 Sep 2013 14:12:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8QECkJH015230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 14:12:46 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 09:12:46 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" , Thomas Narten Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXSUUAgAAOJgCAAAZxgIAABuUAgADP2YA= Date: Thu, 26 Sep 2013 14:12:45 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6A0F44@xmb-rcd-x01.cisco.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012A3351@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.2.3.120616 x-originating-ip: [10.98.43.181] Content-Type: text/plain; charset="us-ascii" Content-ID: <4E6587F511C18C428E58FF2D4D905E53@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 14:12:55 -0000 Hi Maria, Hope you are well. I do not believe the new charter text prevents the realization of a service chain *without* metadata/context information. On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: >I believe the NSC architecture should not preclude the service chain >path/topology from being realized with some existing (and standard ;-) >network overlay (=3Dvirtual network) technique. But if the decision is mad= e >that it does then this should be clearly stated in the charter. >What must be common to the service chain path solutions is, IMO, the >method for carrying the metadata/context information. > >Maria > >> -----Original Message----- >> From: Thomas Narten [mailto:narten@us.ibm.com] >> Sent: Wednesday, September 25, 2013 5:24 PM >> To: NAPIERALA, MARIA H >> Cc: Jim Guichard (jguichar); nsc@ietf.org >> Subject: Re: [nsc] New NSC WG Charter >>=20 >> "NAPIERALA, MARIA H" writes: >>=20 >> > The group charter's write-up says that: "The Service Function >> > Chaining (SFC) working group will develop new approaches to service >> > delivery ..." (i.e., not one "approach" but "approaches", which >> > means more than one). >>=20 >> > But then is states that a document will be developed such that it >> > "will describe *the(?) single* service-level data plane >> > encapsulation format for conveying the service function chain and >> > the service function path associated with data packets, and for >> > carrying context information between nodes that implement service >> > functions". >>=20 >> > How to do you reconcile those two statements? >>=20 >> Note: this inconsistency existed in the earlier charter, I didn't >> introduce it. :-) >>=20 >> I think for the service plane data encapsulation, we should aim for >> one. I'm understand the concern about writing that into the charter in >> absolute terms, as I think the WG should have room to discuss and it >> may be too early to be definitive. But unless there is compelling >> reason, we should have one encap. (BTW, nothing new here.. this is >> normal IETF.) >>=20 >> That said, I don't see the need for more than one encap. Does anyone >> think we do? And if so, why? >>=20 >> > In my opinion, we should open the door for more than one solution to >> > service chaining. >>=20 >> Ah, "solution to service chaining" (to me) is more than the encap, >> including the control plane and related stuff. So even if we develop >> one encap, that doesn't necessarily mean there is only one >> "solution". So the inconsistency may not be quite as strong as first >> seems. >>=20 >> Suggestion. change: >>=20 >> A document will describe the single service-level data plane >> encapsulation format ... >>=20 >> To: >>=20 >> A document will describe a service-level data plane encapsulation >> format ... >>=20 >> this is a bit weaker, but still does (implicitely) suggest one encap. >>=20 >> or, if folk think this is not good enough, we could add text saying we >> are aiming for one, and will only do more if ... >>=20 >> But personally, I think it would be fine to have the charter say one >> encap, and if the WG concludes that one encap isn't what is needed, >> then recharter. We shouldn't look at rechartering as "impossible". We >> just need to be able to make the case that more than one encap is >> necessary. If we can do that, I wouldn't think rechartering would be a >> big deal. >>=20 >> Thomas > From mn1921@att.com Thu Sep 26 07:28: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 7713F21F98AC for ; Thu, 26 Sep 2013 07:28:11 -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 43KNuepbt5HX for ; Thu, 26 Sep 2013 07:28:04 -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 22FC021F9991 for ; Thu, 26 Sep 2013 07:27:55 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b6444425.2aaab7928940.2051469.00-565.5489214.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 26 Sep 2013 14:27:55 +0000 (UTC) X-MXL-Hash: 5244446b7bb0be8f-67bf834b43b306b2c36b36401739fef9af54dbe5 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 a6444425.0.2051464.00-276.5489192.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 26 Sep 2013 14:27:54 +0000 (UTC) X-MXL-Hash: 5244446a0b5b42d0-6450ea27046f113226876e3e49d589183b89a4b4 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 r8QERr6e018057; Thu, 26 Sep 2013 10:27:53 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8QEReTF017813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Sep 2013 10:27:47 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 26 Sep 2013 14:27:24 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; Thu, 26 Sep 2013 10:27:24 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXOIIA///I2MCAAEu+gP//wPdwgAFY24D//7+64A== Date: Thu, 26 Sep 2013 14:27:24 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012A382E@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <1D70D757A2C9D54D83B4CBD7625FA80E012A3351@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6A0F44@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6A0F44@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.50.164] 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=Rv1y2laK c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=xu9cFvUiMcUA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=FFZ-zzI3G] X-AnalysisOut: [zMA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=VnNF1IyMAAAA:8 ] X-AnalysisOut: [a=jL7_-NWWuw9eaYYorqYA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10] Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 14:28:11 -0000 Jim, I said the opposite, i.e., how to carry metadata should be part of the char= ter but how to carry the metadata should not necessarily dictate how the se= rvice chain path itself is realized. Maria > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Thursday, September 26, 2013 10:13 AM > To: NAPIERALA, MARIA H; Thomas Narten > Cc: nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter >=20 > Hi Maria, >=20 > Hope you are well. I do not believe the new charter text prevents the > realization of a service chain *without* metadata/context information. >=20 > On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: >=20 > >I believe the NSC architecture should not preclude the service chain > >path/topology from being realized with some existing (and standard ;-) > >network overlay (=3Dvirtual network) technique. But if the decision is > made > >that it does then this should be clearly stated in the charter. > >What must be common to the service chain path solutions is, IMO, the > >method for carrying the metadata/context information. > > > >Maria > > > >> -----Original Message----- > >> From: Thomas Narten [mailto:narten@us.ibm.com] > >> Sent: Wednesday, September 25, 2013 5:24 PM > >> To: NAPIERALA, MARIA H > >> Cc: Jim Guichard (jguichar); nsc@ietf.org > >> Subject: Re: [nsc] New NSC WG Charter > >> > >> "NAPIERALA, MARIA H" writes: > >> > >> > The group charter's write-up says that: "The Service Function > >> > Chaining (SFC) working group will develop new approaches to > service > >> > delivery ..." (i.e., not one "approach" but "approaches", which > >> > means more than one). > >> > >> > But then is states that a document will be developed such that it > >> > "will describe *the(?) single* service-level data plane > >> > encapsulation format for conveying the service function chain and > >> > the service function path associated with data packets, and for > >> > carrying context information between nodes that implement service > >> > functions". > >> > >> > How to do you reconcile those two statements? > >> > >> Note: this inconsistency existed in the earlier charter, I didn't > >> introduce it. :-) > >> > >> I think for the service plane data encapsulation, we should aim for > >> one. I'm understand the concern about writing that into the charter > in > >> absolute terms, as I think the WG should have room to discuss and it > >> may be too early to be definitive. But unless there is compelling > >> reason, we should have one encap. (BTW, nothing new here.. this is > >> normal IETF.) > >> > >> That said, I don't see the need for more than one encap. Does anyone > >> think we do? And if so, why? > >> > >> > In my opinion, we should open the door for more than one solution > to > >> > service chaining. > >> > >> Ah, "solution to service chaining" (to me) is more than the encap, > >> including the control plane and related stuff. So even if we develop > >> one encap, that doesn't necessarily mean there is only one > >> "solution". So the inconsistency may not be quite as strong as first > >> seems. > >> > >> Suggestion. change: > >> > >> A document will describe the single service-level data plane > >> encapsulation format ... > >> > >> To: > >> > >> A document will describe a service-level data plane encapsulation > >> format ... > >> > >> this is a bit weaker, but still does (implicitely) suggest one > encap. > >> > >> or, if folk think this is not good enough, we could add text saying > we > >> are aiming for one, and will only do more if ... > >> > >> But personally, I think it would be fine to have the charter say one > >> encap, and if the WG concludes that one encap isn't what is needed, > >> then recharter. We shouldn't look at rechartering as "impossible". > We > >> just need to be able to make the case that more than one encap is > >> necessary. If we can do that, I wouldn't think rechartering would be > a > >> big deal. > >> > >> Thomas > > From jguichar@cisco.com Thu Sep 26 07:31: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 DC7FF11E80E7 for ; Thu, 26 Sep 2013 07:31:28 -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=[AWL=0.000, 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 EqTH-OUW0q63 for ; Thu, 26 Sep 2013 07:31:23 -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 3184621F9CDA for ; Thu, 26 Sep 2013 07:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4774; q=dns/txt; s=iport; t=1380205880; x=1381415480; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=amwJZ/d0qOts/fVa51aM8MVWDxQcSZat0BEVijjnRWs=; b=Q5mJE4ApW6y5J7c+w9HKEdaWXhVLdmSOboUr6AjtQUyekWmACJLtRhkU LQY5McR4A4LjVGKPVhGxgf2wvAwFTJTi69SD4Mx2x7DmkIaIMDhsdXRzA Zbb2dDGfdxmvgZDoXzwf/ZKvDjnRz3EQG4zRmtFgFSfP7nfoRnUWh1yTb Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAH9ERFKtJV2c/2dsb2JhbABbgweBCsBTgR8WdIIlAQEBBCcTPwwGAQgRAQMBAQEKFAk5FAMGCAIEDgUIE4drvS2PIDEHBoMXgQEDqXWDJIIq X-IronPort-AV: E=Sophos;i="4.90,986,1371081600"; d="scan'208";a="264819412" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 26 Sep 2013 14:31:19 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8QEVJQ0009552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 14:31:19 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 09:31:19 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXSUUAgAAOJgCAAAZxgIAABuUAgADP2YCAAEcrAP//vgYA Date: Thu, 26 Sep 2013 14:31:18 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6A1220@xmb-rcd-x01.cisco.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012A382E@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.2.3.120616 x-originating-ip: [10.98.43.181] Content-Type: text/plain; charset="us-ascii" Content-ID: <3CD78484AC06DE4888F49DB067A776F0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 14:31:29 -0000 Yes and I believe the following text from the charter covers that -> "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." On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: >Jim, > >I said the opposite, i.e., how to carry metadata should be part of the >charter but how to carry the metadata should not necessarily dictate how >the service chain path itself is realized. > >Maria > >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Thursday, September 26, 2013 10:13 AM >> To: NAPIERALA, MARIA H; Thomas Narten >> Cc: nsc@ietf.org >> Subject: Re: [nsc] New NSC WG Charter >>=20 >> Hi Maria, >>=20 >> Hope you are well. I do not believe the new charter text prevents the >> realization of a service chain *without* metadata/context information. >>=20 >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: >>=20 >> >I believe the NSC architecture should not preclude the service chain >> >path/topology from being realized with some existing (and standard ;-) >> >network overlay (=3Dvirtual network) technique. But if the decision is >> made >> >that it does then this should be clearly stated in the charter. >> >What must be common to the service chain path solutions is, IMO, the >> >method for carrying the metadata/context information. >> > >> >Maria >> > >> >> -----Original Message----- >> >> From: Thomas Narten [mailto:narten@us.ibm.com] >> >> Sent: Wednesday, September 25, 2013 5:24 PM >> >> To: NAPIERALA, MARIA H >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org >> >> Subject: Re: [nsc] New NSC WG Charter >> >> >> >> "NAPIERALA, MARIA H" writes: >> >> >> >> > The group charter's write-up says that: "The Service Function >> >> > Chaining (SFC) working group will develop new approaches to >> service >> >> > delivery ..." (i.e., not one "approach" but "approaches", which >> >> > means more than one). >> >> >> >> > But then is states that a document will be developed such that it >> >> > "will describe *the(?) single* service-level data plane >> >> > encapsulation format for conveying the service function chain and >> >> > the service function path associated with data packets, and for >> >> > carrying context information between nodes that implement service >> >> > functions". >> >> >> >> > How to do you reconcile those two statements? >> >> >> >> Note: this inconsistency existed in the earlier charter, I didn't >> >> introduce it. :-) >> >> >> >> I think for the service plane data encapsulation, we should aim for >> >> one. I'm understand the concern about writing that into the charter >> in >> >> absolute terms, as I think the WG should have room to discuss and it >> >> may be too early to be definitive. But unless there is compelling >> >> reason, we should have one encap. (BTW, nothing new here.. this is >> >> normal IETF.) >> >> >> >> That said, I don't see the need for more than one encap. Does anyone >> >> think we do? And if so, why? >> >> >> >> > In my opinion, we should open the door for more than one solution >> to >> >> > service chaining. >> >> >> >> Ah, "solution to service chaining" (to me) is more than the encap, >> >> including the control plane and related stuff. So even if we develop >> >> one encap, that doesn't necessarily mean there is only one >> >> "solution". So the inconsistency may not be quite as strong as first >> >> seems. >> >> >> >> Suggestion. change: >> >> >> >> A document will describe the single service-level data plane >> >> encapsulation format ... >> >> >> >> To: >> >> >> >> A document will describe a service-level data plane encapsulation >> >> format ... >> >> >> >> this is a bit weaker, but still does (implicitely) suggest one >> encap. >> >> >> >> or, if folk think this is not good enough, we could add text saying >> we >> >> are aiming for one, and will only do more if ... >> >> >> >> But personally, I think it would be fine to have the charter say one >> >> encap, and if the WG concludes that one encap isn't what is needed, >> >> then recharter. We shouldn't look at rechartering as "impossible". >> We >> >> just need to be able to make the case that more than one encap is >> >> necessary. If we can do that, I wouldn't think rechartering would be >> a >> >> big deal. >> >> >> >> Thomas >> > > From mn1921@att.com Thu Sep 26 07:49: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 EE98D21F9FED for ; Thu, 26 Sep 2013 07:49:18 -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 jkTw7isbE3Bn for ; Thu, 26 Sep 2013 07:49:09 -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 36C9421F9EB5 for ; Thu, 26 Sep 2013 07:49:09 -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 56944425.56546940.9227599.00-560.25387067.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 26 Sep 2013 14:49:09 +0000 (UTC) X-MXL-Hash: 5244496567c244c4-a075b53aeecba0ef50fecb5c78899690a56ac2bc 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 46944425.0.9227586.00-370.25387033.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 26 Sep 2013 14:49:08 +0000 (UTC) X-MXL-Hash: 524449640883ccd0-65482232d29be23de5fe997b7aa2be1e2c8f7494 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 r8QEn7bl015847; Thu, 26 Sep 2013 10:49:08 -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 r8QEmq5F015525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Sep 2013 10:49:04 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (MISOUT7MSGHUB9A.itservices.sbc.com [144.151.223.62]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 26 Sep 2013 14:48:28 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.03.0158.001; Thu, 26 Sep 2013 10:48:27 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXOIIA///I2MCAAEu+gP//wPdwgAFY24D//7+64AAIrpkAAAf8x8A= Date: Thu, 26 Sep 2013 14:48:27 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <1D70D757A2C9D54D83B4CBD7625FA80E012A382E@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6A1220@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6A1220@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.50.164] 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=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=xu9cFvUiMcUA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=FFZ-zzI3G] X-AnalysisOut: [zMA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=VnNF1IyMAAAA:8 ] X-AnalysisOut: [a=_J9BEQ6keGG8x6-lRmAA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10] Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 14:49:19 -0000 This paragraph is good. I was pointing out that the item 3 (under "Specifically, the SFC WG is char= tered to deliver the following" heading) is implying a specific solution (w= hich is fine but it should not be the only one...): "3) Generic Service Function Chaining Encapsulation: A document will descri= be the single service-level data plane encapsulation format for conveying t= he service function chain and the service function path, and for communicat= ing context information between nodes that implement service functions..." Maria > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Thursday, September 26, 2013 10:31 AM > To: NAPIERALA, MARIA H > Cc: nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter >=20 > Yes and I believe the following text from the charter covers that -> > "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." >=20 > On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: >=20 > >Jim, > > > >I said the opposite, i.e., how to carry metadata should be part of the > >charter but how to carry the metadata should not necessarily dictate > how > >the service chain path itself is realized. > > > >Maria > > > >> -----Original Message----- > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> Sent: Thursday, September 26, 2013 10:13 AM > >> To: NAPIERALA, MARIA H; Thomas Narten > >> Cc: nsc@ietf.org > >> Subject: Re: [nsc] New NSC WG Charter > >> > >> Hi Maria, > >> > >> Hope you are well. I do not believe the new charter text prevents > the > >> realization of a service chain *without* metadata/context > information. > >> > >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: > >> > >> >I believe the NSC architecture should not preclude the service > chain > >> >path/topology from being realized with some existing (and standard > ;-) > >> >network overlay (=3Dvirtual network) technique. But if the decision > is > >> made > >> >that it does then this should be clearly stated in the charter. > >> >What must be common to the service chain path solutions is, IMO, > the > >> >method for carrying the metadata/context information. > >> > > >> >Maria > >> > > >> >> -----Original Message----- > >> >> From: Thomas Narten [mailto:narten@us.ibm.com] > >> >> Sent: Wednesday, September 25, 2013 5:24 PM > >> >> To: NAPIERALA, MARIA H > >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org > >> >> Subject: Re: [nsc] New NSC WG Charter > >> >> > >> >> "NAPIERALA, MARIA H" writes: > >> >> > >> >> > The group charter's write-up says that: "The Service Function > >> >> > Chaining (SFC) working group will develop new approaches to > >> service > >> >> > delivery ..." (i.e., not one "approach" but "approaches", which > >> >> > means more than one). > >> >> > >> >> > But then is states that a document will be developed such that > it > >> >> > "will describe *the(?) single* service-level data plane > >> >> > encapsulation format for conveying the service function chain > and > >> >> > the service function path associated with data packets, and > for > >> >> > carrying context information between nodes that implement > service > >> >> > functions". > >> >> > >> >> > How to do you reconcile those two statements? > >> >> > >> >> Note: this inconsistency existed in the earlier charter, I didn't > >> >> introduce it. :-) > >> >> > >> >> I think for the service plane data encapsulation, we should aim > for > >> >> one. I'm understand the concern about writing that into the > charter > >> in > >> >> absolute terms, as I think the WG should have room to discuss and > it > >> >> may be too early to be definitive. But unless there is compelling > >> >> reason, we should have one encap. (BTW, nothing new here.. this > is > >> >> normal IETF.) > >> >> > >> >> That said, I don't see the need for more than one encap. Does > anyone > >> >> think we do? And if so, why? > >> >> > >> >> > In my opinion, we should open the door for more than one > solution > >> to > >> >> > service chaining. > >> >> > >> >> Ah, "solution to service chaining" (to me) is more than the > encap, > >> >> including the control plane and related stuff. So even if we > develop > >> >> one encap, that doesn't necessarily mean there is only one > >> >> "solution". So the inconsistency may not be quite as strong as > first > >> >> seems. > >> >> > >> >> Suggestion. change: > >> >> > >> >> A document will describe the single service-level data plane > >> >> encapsulation format ... > >> >> > >> >> To: > >> >> > >> >> A document will describe a service-level data plane > encapsulation > >> >> format ... > >> >> > >> >> this is a bit weaker, but still does (implicitely) suggest one > >> encap. > >> >> > >> >> or, if folk think this is not good enough, we could add text > saying > >> we > >> >> are aiming for one, and will only do more if ... > >> >> > >> >> But personally, I think it would be fine to have the charter say > one > >> >> encap, and if the WG concludes that one encap isn't what is > needed, > >> >> then recharter. We shouldn't look at rechartering as > "impossible". > >> We > >> >> just need to be able to make the case that more than one encap is > >> >> necessary. If we can do that, I wouldn't think rechartering would > be > >> a > >> >> big deal. > >> >> > >> >> Thomas > >> > > > From jguichar@cisco.com Thu Sep 26 07: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 4D1D111E810A for ; Thu, 26 Sep 2013 07:51:30 -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=[AWL=0.000, 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 J7P6zdho5PEv for ; Thu, 26 Sep 2013 07:51:24 -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 B8E1021F9F5B for ; Thu, 26 Sep 2013 07:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6206; q=dns/txt; s=iport; t=1380207077; x=1381416677; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9LF5RRu4rhcOuPcxT+YTXUP2m0FjFNb1q0I/iJi0mDY=; b=lDVyuk+cNQrMPuDkU4b8f1lERIsSDLRbzzVMwyYnTmuaxpsBWLZGt3ED X8wp+4DFDPttLScpgdZ7VGXFZTWlmKFZ2IK9dfXfbfIrYe2ZSN+qF0fgv WJVBIQ7O7w6F1JqurclXYmASjYo5vS0LrSZGj+NmMRW8hkvE8Vcw4aBBW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAMdIRFKtJV2c/2dsb2JhbABbgweBCsBTgR8WdIIlAQEBBCcTPwwGAQgRAQMBAQEKFAk5FAMGCAIEDgUIE4drvSaPIDEHBoMXgQEDqXWDJIIq X-IronPort-AV: E=Sophos;i="4.90,986,1371081600"; d="scan'208";a="264833175" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 26 Sep 2013 14:51:17 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8QEpGYd030293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 14:51:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 09:51:16 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXSUUAgAAOJgCAAAZxgIAABuUAgADP2YCAAEcrAP//vgYAgABH3ID//723gA== Date: Thu, 26 Sep 2013 14:51:15 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@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.2.3.120616 x-originating-ip: [10.98.43.181] Content-Type: text/plain; charset="us-ascii" Content-ID: <16E6273794141F4FAA02D19FCD2718A4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 14:51:30 -0000 That is talking about context information - notice all the *and's* in the sentence ;-)=20 On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: >This paragraph is good. > >I was pointing out that the item 3 (under "Specifically, the SFC WG is >chartered to deliver the following" heading) is implying a specific >solution (which is fine but it should not be the only one...): > >"3) Generic Service Function Chaining Encapsulation: A document will >describe the single service-level data plane encapsulation format for >conveying the service function chain and the service function path, and >for communicating context information between nodes that implement >service functions..." > > >Maria > >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Thursday, September 26, 2013 10:31 AM >> To: NAPIERALA, MARIA H >> Cc: nsc@ietf.org >> Subject: Re: [nsc] New NSC WG Charter >>=20 >> Yes and I believe the following text from the charter covers that -> >> "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." >>=20 >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: >>=20 >> >Jim, >> > >> >I said the opposite, i.e., how to carry metadata should be part of the >> >charter but how to carry the metadata should not necessarily dictate >> how >> >the service chain path itself is realized. >> > >> >Maria >> > >> >> -----Original Message----- >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> >> Sent: Thursday, September 26, 2013 10:13 AM >> >> To: NAPIERALA, MARIA H; Thomas Narten >> >> Cc: nsc@ietf.org >> >> Subject: Re: [nsc] New NSC WG Charter >> >> >> >> Hi Maria, >> >> >> >> Hope you are well. I do not believe the new charter text prevents >> the >> >> realization of a service chain *without* metadata/context >> information. >> >> >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: >> >> >> >> >I believe the NSC architecture should not preclude the service >> chain >> >> >path/topology from being realized with some existing (and standard >> ;-) >> >> >network overlay (=3Dvirtual network) technique. But if the decision >> is >> >> made >> >> >that it does then this should be clearly stated in the charter. >> >> >What must be common to the service chain path solutions is, IMO, >> the >> >> >method for carrying the metadata/context information. >> >> > >> >> >Maria >> >> > >> >> >> -----Original Message----- >> >> >> From: Thomas Narten [mailto:narten@us.ibm.com] >> >> >> Sent: Wednesday, September 25, 2013 5:24 PM >> >> >> To: NAPIERALA, MARIA H >> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org >> >> >> Subject: Re: [nsc] New NSC WG Charter >> >> >> >> >> >> "NAPIERALA, MARIA H" writes: >> >> >> >> >> >> > The group charter's write-up says that: "The Service Function >> >> >> > Chaining (SFC) working group will develop new approaches to >> >> service >> >> >> > delivery ..." (i.e., not one "approach" but "approaches", which >> >> >> > means more than one). >> >> >> >> >> >> > But then is states that a document will be developed such that >> it >> >> >> > "will describe *the(?) single* service-level data plane >> >> >> > encapsulation format for conveying the service function chain >> and >> >> >> > the service function path associated with data packets, and >> for >> >> >> > carrying context information between nodes that implement >> service >> >> >> > functions". >> >> >> >> >> >> > How to do you reconcile those two statements? >> >> >> >> >> >> Note: this inconsistency existed in the earlier charter, I didn't >> >> >> introduce it. :-) >> >> >> >> >> >> I think for the service plane data encapsulation, we should aim >> for >> >> >> one. I'm understand the concern about writing that into the >> charter >> >> in >> >> >> absolute terms, as I think the WG should have room to discuss and >> it >> >> >> may be too early to be definitive. But unless there is compelling >> >> >> reason, we should have one encap. (BTW, nothing new here.. this >> is >> >> >> normal IETF.) >> >> >> >> >> >> That said, I don't see the need for more than one encap. Does >> anyone >> >> >> think we do? And if so, why? >> >> >> >> >> >> > In my opinion, we should open the door for more than one >> solution >> >> to >> >> >> > service chaining. >> >> >> >> >> >> Ah, "solution to service chaining" (to me) is more than the >> encap, >> >> >> including the control plane and related stuff. So even if we >> develop >> >> >> one encap, that doesn't necessarily mean there is only one >> >> >> "solution". So the inconsistency may not be quite as strong as >> first >> >> >> seems. >> >> >> >> >> >> Suggestion. change: >> >> >> >> >> >> A document will describe the single service-level data plane >> >> >> encapsulation format ... >> >> >> >> >> >> To: >> >> >> >> >> >> A document will describe a service-level data plane >> encapsulation >> >> >> format ... >> >> >> >> >> >> this is a bit weaker, but still does (implicitely) suggest one >> >> encap. >> >> >> >> >> >> or, if folk think this is not good enough, we could add text >> saying >> >> we >> >> >> are aiming for one, and will only do more if ... >> >> >> >> >> >> But personally, I think it would be fine to have the charter say >> one >> >> >> encap, and if the WG concludes that one encap isn't what is >> needed, >> >> >> then recharter. We shouldn't look at rechartering as >> "impossible". >> >> We >> >> >> just need to be able to make the case that more than one encap is >> >> >> necessary. If we can do that, I wouldn't think rechartering would >> be >> >> a >> >> >> big deal. >> >> >> >> >> >> Thomas >> >> > >> > > From I.Smith@F5.com Thu Sep 26 08:00: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 4818321F9D68 for ; Thu, 26 Sep 2013 08:00:04 -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 41jMF7Agln48 for ; Thu, 26 Sep 2013 07:59:55 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 835A111E8107 for ; Thu, 26 Sep 2013 07:59:32 -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=1380207572; x=1411743572; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NwHCHwv0XiSJLfwAx5z584vKEAtVGtR2yhupqUl3fsY=; b=AkozhgI2T5c0d+7MmyWNDWK+qCrQ/SpIKPJBg4An7sbV1ymPinwW0byS YbxFWWhSmLG1wLpny3RVaViW4QbZmqOmRaBXygV7JG2eJWW3cp0j6QABd jwyDyFn28IX/NksQgFTwEm63u0kbvUBEjtRNOI4XuGsrb+sC/MpIrvqBD U=; X-IronPort-AV: E=Sophos;i="4.90,986,1371081600"; d="scan'208";a="82035238" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 26 Sep 2013 14:59: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, 26 Sep 2013 07:59:31 -0700 From: Ian Smith To: "Jim Guichard (jguichar)" , "NAPIERALA, MARIA H" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABuUAgAES7ICAAAQYAIAAARcAgAAEy4CAAADIgP//jBl1 Date: Thu, 26 Sep 2013 14:59:31 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A6F05BF@SEAEMBX02.olympus.F5Net.com> References: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@MISOUT7MSGUSR9I.ITServices.sbc.com>, <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6A12C2@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: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 15:00:25 -0000 When you say this:=0A= =0A= >3) Generic Service Function Chaining Encapsulation: A document will=0A= >describe the single service-level data plane encapsulation format for=0A= >conveying the service function chain and the service function path, and=0A= >for communicating context information between nodes that implement=0A= >service functions..."=0A= =0A= I think you are trying to say this:=0A= =0A= 3) Generic Service Function Chaining Encapsulation: A document will=0A= describe a uniform service-level data plane encapsulation format for both:= =0A= a) conveying the service function chain and the service function path, and= =0A= b) for communicating context information between nodes that implement=0A= service functions...=0A= =0A= =0A= ________________________________________=0A= From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim Guichard= (jguichar) [jguichar@cisco.com]=0A= Sent: Thursday, September 26, 2013 10:51 AM=0A= To: NAPIERALA, MARIA H=0A= Cc: nsc@ietf.org=0A= Subject: Re: [nsc] New NSC WG Charter=0A= =0A= That is talking about context information - notice all the *and's* in the= =0A= sentence ;-)=0A= =0A= On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote:=0A= =0A= >This paragraph is good.=0A= >=0A= >I was pointing out that the item 3 (under "Specifically, the SFC WG is=0A= >chartered to deliver the following" heading) is implying a specific=0A= >solution (which is fine but it should not be the only one...):=0A= >=0A= >"3) Generic Service Function Chaining Encapsulation: A document will=0A= >describe the single service-level data plane encapsulation format for=0A= >conveying the service function chain and the service function path, and=0A= >for communicating context information between nodes that implement=0A= >service functions..."=0A= >=0A= >=0A= >Maria=0A= >=0A= >> -----Original Message-----=0A= >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=0A= >> Sent: Thursday, September 26, 2013 10:31 AM=0A= >> To: NAPIERALA, MARIA H=0A= >> Cc: nsc@ietf.org=0A= >> Subject: Re: [nsc] New NSC WG Charter=0A= >>=0A= >> Yes and I believe the following text from the charter covers that ->=0A= >> "The=0A= >> Service Function Chaining (SFC) working group will develop new=0A= >> approaches=0A= >> to service delivery and deployment. It will produce a framework for=0A= >> service function chaining that includes the necessary protocols or=0A= >> protocol extensions to convey the service path and service path=0A= >> information to nodes that implement service functions, as well as=0A= >> mechanisms for steering traffic through service functions."=0A= >>=0A= >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote:=0A= >>=0A= >> >Jim,=0A= >> >=0A= >> >I said the opposite, i.e., how to carry metadata should be part of the= =0A= >> >charter but how to carry the metadata should not necessarily dictate=0A= >> how=0A= >> >the service chain path itself is realized.=0A= >> >=0A= >> >Maria=0A= >> >=0A= >> >> -----Original Message-----=0A= >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=0A= >> >> Sent: Thursday, September 26, 2013 10:13 AM=0A= >> >> To: NAPIERALA, MARIA H; Thomas Narten=0A= >> >> Cc: nsc@ietf.org=0A= >> >> Subject: Re: [nsc] New NSC WG Charter=0A= >> >>=0A= >> >> Hi Maria,=0A= >> >>=0A= >> >> Hope you are well. I do not believe the new charter text prevents=0A= >> the=0A= >> >> realization of a service chain *without* metadata/context=0A= >> information.=0A= >> >>=0A= >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote:=0A= >> >>=0A= >> >> >I believe the NSC architecture should not preclude the service=0A= >> chain=0A= >> >> >path/topology from being realized with some existing (and standard= =0A= >> ;-)=0A= >> >> >network overlay (=3Dvirtual network) technique. But if the decision= =0A= >> is=0A= >> >> made=0A= >> >> >that it does then this should be clearly stated in the charter.=0A= >> >> >What must be common to the service chain path solutions is, IMO,=0A= >> the=0A= >> >> >method for carrying the metadata/context information.=0A= >> >> >=0A= >> >> >Maria=0A= >> >> >=0A= >> >> >> -----Original Message-----=0A= >> >> >> From: Thomas Narten [mailto:narten@us.ibm.com]=0A= >> >> >> Sent: Wednesday, September 25, 2013 5:24 PM=0A= >> >> >> To: NAPIERALA, MARIA H=0A= >> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org=0A= >> >> >> Subject: Re: [nsc] New NSC WG Charter=0A= >> >> >>=0A= >> >> >> "NAPIERALA, MARIA H" writes:=0A= >> >> >>=0A= >> >> >> > The group charter's write-up says that: "The Service Function=0A= >> >> >> > Chaining (SFC) working group will develop new approaches to=0A= >> >> service=0A= >> >> >> > delivery ..." (i.e., not one "approach" but "approaches", which= =0A= >> >> >> > means more than one).=0A= >> >> >>=0A= >> >> >> > But then is states that a document will be developed such that= =0A= >> it=0A= >> >> >> > "will describe *the(?) single* service-level data plane=0A= >> >> >> > encapsulation format for conveying the service function chain= =0A= >> and=0A= >> >> >> > the service function path associated with data packets, and=0A= >> for=0A= >> >> >> > carrying context information between nodes that implement=0A= >> service=0A= >> >> >> > functions".=0A= >> >> >>=0A= >> >> >> > How to do you reconcile those two statements?=0A= >> >> >>=0A= >> >> >> Note: this inconsistency existed in the earlier charter, I didn't= =0A= >> >> >> introduce it. :-)=0A= >> >> >>=0A= >> >> >> I think for the service plane data encapsulation, we should aim=0A= >> for=0A= >> >> >> one. I'm understand the concern about writing that into the=0A= >> charter=0A= >> >> in=0A= >> >> >> absolute terms, as I think the WG should have room to discuss and= =0A= >> it=0A= >> >> >> may be too early to be definitive. But unless there is compelling= =0A= >> >> >> reason, we should have one encap. (BTW, nothing new here.. this=0A= >> is=0A= >> >> >> normal IETF.)=0A= >> >> >>=0A= >> >> >> That said, I don't see the need for more than one encap. Does=0A= >> anyone=0A= >> >> >> think we do? And if so, why?=0A= >> >> >>=0A= >> >> >> > In my opinion, we should open the door for more than one=0A= >> solution=0A= >> >> to=0A= >> >> >> > service chaining.=0A= >> >> >>=0A= >> >> >> Ah, "solution to service chaining" (to me) is more than the=0A= >> encap,=0A= >> >> >> including the control plane and related stuff. So even if we=0A= >> develop=0A= >> >> >> one encap, that doesn't necessarily mean there is only one=0A= >> >> >> "solution". So the inconsistency may not be quite as strong as=0A= >> first=0A= >> >> >> seems.=0A= >> >> >>=0A= >> >> >> Suggestion. change:=0A= >> >> >>=0A= >> >> >> A document will describe the single service-level data plane=0A= >> >> >> encapsulation format ...=0A= >> >> >>=0A= >> >> >> To:=0A= >> >> >>=0A= >> >> >> A document will describe a service-level data plane=0A= >> encapsulation=0A= >> >> >> format ...=0A= >> >> >>=0A= >> >> >> this is a bit weaker, but still does (implicitely) suggest one=0A= >> >> encap.=0A= >> >> >>=0A= >> >> >> or, if folk think this is not good enough, we could add text=0A= >> saying=0A= >> >> we=0A= >> >> >> are aiming for one, and will only do more if ...=0A= >> >> >>=0A= >> >> >> But personally, I think it would be fine to have the charter say= =0A= >> one=0A= >> >> >> encap, and if the WG concludes that one encap isn't what is=0A= >> needed,=0A= >> >> >> then recharter. We shouldn't look at rechartering as=0A= >> "impossible".=0A= >> >> We=0A= >> >> >> just need to be able to make the case that more than one encap is= =0A= >> >> >> necessary. If we can do that, I wouldn't think rechartering would= =0A= >> be=0A= >> >> a=0A= >> >> >> big deal.=0A= >> >> >>=0A= >> >> >> Thomas=0A= >> >> >=0A= >> >=0A= >=0A= =0A= _______________________________________________=0A= nsc mailing list=0A= nsc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nsc=0A= From jguichar@cisco.com Thu Sep 26 08:02: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 E1FC821F8F4A for ; Thu, 26 Sep 2013 08:02:24 -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=[AWL=0.000, 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 C5Une9-iS52T for ; Thu, 26 Sep 2013 08:02:18 -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 24C8021E8095 for ; Thu, 26 Sep 2013 08:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7600; q=dns/txt; s=iport; t=1380207737; x=1381417337; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GbVdOG7urvi9syvp7nnKNnU6sE6jzOZawptQGzX7ovc=; b=YN2wrGEw+Zd2sybkN5s5A7mmVTYDZ/SAUfVzj7kONmgIu8QYdUptbec2 EKha0KkyH2DdC8eiJD7MdkhSKRkxtxZyF73RkgbIUH64a6mNUmyBdTtWv bvP6lPhJm7sgyOAK6d+cpbALSMmpjFSQCV1BoBISGK3Xe4VPCOgHVF92B Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAEpLRFKtJV2a/2dsb2JhbABbgwc4UsBTgR8WdIIlAQEBBAEBASQTNAsMBgEIDgMBAwEBAQoUCS4LFAMGCAIEDgUIE4drDL0dBI8gBisHAgSDF4EBA6l1gySCKg X-IronPort-AV: E=Sophos;i="4.90,986,1371081600"; d="scan'208";a="264838597" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 26 Sep 2013 15:02:16 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8QF2G2V021975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 15:02:16 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 10:02:15 -0500 From: "Jim Guichard (jguichar)" To: Ian Smith , "NAPIERALA, MARIA H" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXSUUAgAAOJgCAAAZxgIAABuUAgADP2YCAAEcrAP//vgYAgABH3ID//723gIAARWCA//+9s4A= Date: Thu, 26 Sep 2013 15:02:15 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6A1365@xmb-rcd-x01.cisco.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A6F05BF@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.181] Content-Type: text/plain; charset="us-ascii" Content-ID: <1BA1033A9CE5FF4685E9FA500B706F27@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 15:02:27 -0000 Yes, that is more accurately put Ian. On 9/26/13 10:59 AM, "Ian Smith" wrote: >When you say this: > >>3) Generic Service Function Chaining Encapsulation: A document will >>describe the single service-level data plane encapsulation format for >>conveying the service function chain and the service function path, and >>for communicating context information between nodes that implement >>service functions..." > >I think you are trying to say this: > >3) Generic Service Function Chaining Encapsulation: A document will >describe a uniform service-level data plane encapsulation format for both: > a) conveying the service function chain and the service function path, >and > b) for communicating context information between nodes that implement >service functions... > > >________________________________________ >From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim >Guichard (jguichar) [jguichar@cisco.com] >Sent: Thursday, September 26, 2013 10:51 AM >To: NAPIERALA, MARIA H >Cc: nsc@ietf.org >Subject: Re: [nsc] New NSC WG Charter > >That is talking about context information - notice all the *and's* in the >sentence ;-) > >On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: > >>This paragraph is good. >> >>I was pointing out that the item 3 (under "Specifically, the SFC WG is >>chartered to deliver the following" heading) is implying a specific >>solution (which is fine but it should not be the only one...): >> >>"3) Generic Service Function Chaining Encapsulation: A document will >>describe the single service-level data plane encapsulation format for >>conveying the service function chain and the service function path, and >>for communicating context information between nodes that implement >>service functions..." >> >> >>Maria >> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Thursday, September 26, 2013 10:31 AM >>> To: NAPIERALA, MARIA H >>> Cc: nsc@ietf.org >>> Subject: Re: [nsc] New NSC WG Charter >>> >>> Yes and I believe the following text from the charter covers that -> >>> "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." >>> >>> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: >>> >>> >Jim, >>> > >>> >I said the opposite, i.e., how to carry metadata should be part of the >>> >charter but how to carry the metadata should not necessarily dictate >>> how >>> >the service chain path itself is realized. >>> > >>> >Maria >>> > >>> >> -----Original Message----- >>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> >> Sent: Thursday, September 26, 2013 10:13 AM >>> >> To: NAPIERALA, MARIA H; Thomas Narten >>> >> Cc: nsc@ietf.org >>> >> Subject: Re: [nsc] New NSC WG Charter >>> >> >>> >> Hi Maria, >>> >> >>> >> Hope you are well. I do not believe the new charter text prevents >>> the >>> >> realization of a service chain *without* metadata/context >>> information. >>> >> >>> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: >>> >> >>> >> >I believe the NSC architecture should not preclude the service >>> chain >>> >> >path/topology from being realized with some existing (and standard >>> ;-) >>> >> >network overlay (=3Dvirtual network) technique. But if the decision >>> is >>> >> made >>> >> >that it does then this should be clearly stated in the charter. >>> >> >What must be common to the service chain path solutions is, IMO, >>> the >>> >> >method for carrying the metadata/context information. >>> >> > >>> >> >Maria >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: Thomas Narten [mailto:narten@us.ibm.com] >>> >> >> Sent: Wednesday, September 25, 2013 5:24 PM >>> >> >> To: NAPIERALA, MARIA H >>> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org >>> >> >> Subject: Re: [nsc] New NSC WG Charter >>> >> >> >>> >> >> "NAPIERALA, MARIA H" writes: >>> >> >> >>> >> >> > The group charter's write-up says that: "The Service Function >>> >> >> > Chaining (SFC) working group will develop new approaches to >>> >> service >>> >> >> > delivery ..." (i.e., not one "approach" but "approaches", which >>> >> >> > means more than one). >>> >> >> >>> >> >> > But then is states that a document will be developed such that >>> it >>> >> >> > "will describe *the(?) single* service-level data plane >>> >> >> > encapsulation format for conveying the service function chain >>> and >>> >> >> > the service function path associated with data packets, and >>> for >>> >> >> > carrying context information between nodes that implement >>> service >>> >> >> > functions". >>> >> >> >>> >> >> > How to do you reconcile those two statements? >>> >> >> >>> >> >> Note: this inconsistency existed in the earlier charter, I didn't >>> >> >> introduce it. :-) >>> >> >> >>> >> >> I think for the service plane data encapsulation, we should aim >>> for >>> >> >> one. I'm understand the concern about writing that into the >>> charter >>> >> in >>> >> >> absolute terms, as I think the WG should have room to discuss and >>> it >>> >> >> may be too early to be definitive. But unless there is compelling >>> >> >> reason, we should have one encap. (BTW, nothing new here.. this >>> is >>> >> >> normal IETF.) >>> >> >> >>> >> >> That said, I don't see the need for more than one encap. Does >>> anyone >>> >> >> think we do? And if so, why? >>> >> >> >>> >> >> > In my opinion, we should open the door for more than one >>> solution >>> >> to >>> >> >> > service chaining. >>> >> >> >>> >> >> Ah, "solution to service chaining" (to me) is more than the >>> encap, >>> >> >> including the control plane and related stuff. So even if we >>> develop >>> >> >> one encap, that doesn't necessarily mean there is only one >>> >> >> "solution". So the inconsistency may not be quite as strong as >>> first >>> >> >> seems. >>> >> >> >>> >> >> Suggestion. change: >>> >> >> >>> >> >> A document will describe the single service-level data plane >>> >> >> encapsulation format ... >>> >> >> >>> >> >> To: >>> >> >> >>> >> >> A document will describe a service-level data plane >>> encapsulation >>> >> >> format ... >>> >> >> >>> >> >> this is a bit weaker, but still does (implicitely) suggest one >>> >> encap. >>> >> >> >>> >> >> or, if folk think this is not good enough, we could add text >>> saying >>> >> we >>> >> >> are aiming for one, and will only do more if ... >>> >> >> >>> >> >> But personally, I think it would be fine to have the charter say >>> one >>> >> >> encap, and if the WG concludes that one encap isn't what is >>> needed, >>> >> >> then recharter. We shouldn't look at rechartering as >>> "impossible". >>> >> We >>> >> >> just need to be able to make the case that more than one encap is >>> >> >> necessary. If we can do that, I wouldn't think rechartering would >>> be >>> >> a >>> >> >> big deal. >>> >> >> >>> >> >> Thomas >>> >> > >>> > >> > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From paulq@cisco.com Thu Sep 26 08:11: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 97AE121E8094 for ; Thu, 26 Sep 2013 08:11:29 -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 TzJU84NapXYB for ; Thu, 26 Sep 2013 08:11:24 -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 F32EC21E80A5 for ; Thu, 26 Sep 2013 08:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17030; q=dns/txt; s=iport; t=1380208212; x=1381417812; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aTgoKuQow9F50FfePhcaxt4xJwmX5AMGxR/hbLZDUV4=; b=JC0YrE5t94+qkSlehhNW8WN/e/4XcfU4tvVRC2/o40I/D/+cUEtib4J4 bs09Wd4s4PjVDi/YCzrvS/2LJIErDt0eCSUiDuB7iyjisiIVDDViFPGnC QxFSvsMq6rE/dUAHJLv8FtdV49RBIADuk8EBSKUsXGzScEQ/Dwqk68+pk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAGpNRFKtJV2c/2dsb2JhbABbDoI1RIEKwFOBHxZ0giUBAQEDAWUUBQcEAgEIEQQBAQsZBAcyFAkIAgQBDQUIE4dlBr00jyAGKwYBBoMXgQEDqXWBZn8/gio X-IronPort-AV: E=Sophos;i="4.90,986,1371081600"; d="scan'208,217";a="264842641" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 26 Sep 2013 15:10:08 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8QFA8on015928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 15:10:08 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 10:10:07 -0500 From: "Paul Quinn (paulq)" To: ramki Krishnan , Anoop Ghanwani Thread-Topic: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3] Thread-Index: AQHOuhQTE7xmYsRQmUuk7orbOxe6DZnXCPcAgAAL0oCAAIL9AIAA3N0A Date: Thu, 26 Sep 2013 15:10:07 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> <064001ceba06$27012680$75037380$@olddog.co.uk> <201309251724.r8PHO9hk031606@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.172.246] Content-Type: multipart/alternative; boundary="_000_B4CF12F64861194990FEA0AE39F9B1620EABC25Bxmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] transparent vs. non-transparent services [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: Thu, 26 Sep 2013 15:11:29 -0000 --_000_B4CF12F64861194990FEA0AE39F9B1620EABC25Bxmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Anoop, Ramki, Great to see that you both have read the problem statement! Let's make thi= s constructive: we'd love to see your detailed comments. Please send them = to the list, and/or the draft authors and we'll review them. Paul On Sep 25, 2013, at 6:59 PM, ramki Krishnan > wrote: >>It may be that as Thomas says, we are not going to worry about non-transp= arent appliances at all, but then I'm not sure how we even implement someth= ing like a load balancer. >> Finally, I do think the problem statement needs a lot of work before we = get to solutions. I think it would be useful to state somewhere in the cha= rter that solutions would only be considered after the problem statement is= in a reasonable shape and the WG participants are in agreement about what = needs to be solved. Agree with Anoop. We do need to clarify this aspect in the problem statemen= t. Thanks, Ramki From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Anoop Ghanwani Sent: Wednesday, September 25, 2013 11:11 AM To: Ron Parker Cc: Thomas Narten; >; Paul = Quinn (paulq); > Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3] When I mentioned transparent/non-transparent, I meant that there was some c= hange in the packet headers (whether at the IP, MAC, or TCP layers) for pac= kets that were going to be subject to the service in question, in the non-t= ransparent case. In other words, for the transparent case, I cannot tell b= y looking at the packet headers whether or not the packet would be subject = to that service. Clearly, there are others who think transparent/non-trans= parent mean something else. And that's just simply because there is not st= andard terminology, which perhaps the WG can help define. I think this also plays into where in the packet the NSC header goes, and w= hether there can be multiple instances of the NSC header in the packet. If a certain layer's header is terminated at a service box, it would be a l= ayering violation to carry the NSC header beyond that point. For instance, if the NSC header is located between the MAC and IP header, a= nd the packet hits a load balancer that changes the IP & MAC headers, that = device would need to create a new NSC header. It may be that as Thomas says, we are not going to worry about non-transpar= ent appliances at all, but then I'm not sure how we even implement somethin= g like a load balancer. Finally, I do think the problem statement needs a lot of work before we get= to solutions. I think it would be useful to state somewhere in the charte= r that solutions would only be considered after the problem statement is in= a reasonable shape and the WG participants are in agreement about what nee= ds to be solved. Anoop On Wed, Sep 25, 2013 at 10:28 AM, Ron Parker > wrote: Thomas, I agree that the notion of transparent service is not necessary to incorpor= ate in our work. Ron -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, September 25, 2013 1:24 PM To: Ron Parker Cc: Paul Quinn (paulq); >; = Anoop Ghanwani; > Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3] Ron, > So is the definition of transparent -- packets are unchanged (headers, > content, etc.) and routing/switching path is unaltered? > Or is it just the former? The mere diversion to a service node would > seem to constitute "routing/switching is altered". I think the point is we don't exactly have an agreed to defintion of "trans= parent" in the NSC context, so it's not particularly helpful to use it in d= escribing NSC behavior without being clear about what is meant. For services in NSC, packets clearly will get modified in some cases (e.g. = NAT or proxies) but won't in others. So distinguishing types of services by= how much they change the packets they inspect is probably not helpful for = NSC. NSC doesn't really care *what* the services does, just that the servic= e exists and packets need to be steered to travel through the service. Thomas --_000_B4CF12F64861194990FEA0AE39F9B1620EABC25Bxmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <8D895DA156C0E94C8FCB9240CBA724FC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Anoop, Ramki,

Great to see that you both have read the problem statement!  Let'= s make this constructive: we'd love to see your detailed comments.  Pl= ease send them to the list, and/or the draft authors and we'll review them.=

Paul

On Sep 25, 2013, at 6:59 PM, ramki Krishnan <ramk@Brocade.com>
 wrote:

>>= ;It may be that as Thomas says, we are not going to worry about non-transpa= rent appliances at all, but then I'm not sure how we even implement somethi= ng like a load balancer.
 <= /span>
>>= ; Finally, I do think the problem statement needs a lot of work before we g= et to solutions.  I think it would be useful to state somewhere in the= charter that solutions would only be considered after the problem statement is in a reasonable shape and the WG participan= ts are in agreement about what needs to be solved.
 <= /span>
Agree w= ith Anoop. We do need to clarify this aspect in the problem statement.=
 <= /span>
Thanks,
Ramki
 
From:=  ns= c-bounces@ietf.org [m= ailto:nsc-bounces@ietf.org] On Behalf Of Anoop Ghan= wani
Sent: Wednesday, S= eptember 25, 2013 11:11 AM
To: Ron Parker
Cc: Thomas Narten;= <adrian@olddog.co.uk>; Paul Quinn (paulq); <= ;nsc@ietf.org>
Subject: Re: [nsc]= transparent vs. non-transparent services [was Re: New NSC WG Charter - cha= rter bullet #3]
 
When I mentioned transparent/non-transparent, I meant that there was some c= hange in the packet headers (whether at the IP, MAC, or TCP layers) for pac= kets that were going to be subject to the service in question, in the non-t= ransparent case.  In other words, for the transparent case, I cannot tell by looking at the packet headers w= hether or not the packet would be subject to that service.  Clearly, t= here are others who think transparent/non-transparent mean something else. =  And that's just simply because there is not standard terminology, which perhaps the WG can help define.
 
I think this also plays into where in the packet the NSC header goes, and w= hether there can be multiple instances of the NSC header in the packet.
 
If a certain layer's header is terminated at a service box, it would be a l= ayering violation to carry the NSC header beyond that point.
 
For instance, if the NSC header is located between the MAC and IP header, a= nd the packet hits a load balancer that changes the IP & MAC headers, t= hat device would need to create a new NSC header.
 
It may be that as Thomas says, we are not going to worry about non-transpar= ent appliances at all, but then I'm not sure how we even implement somethin= g like a load balancer.
 
Finally, I do think the problem statement needs a lot of work before we get= to solutions.  I think it would be useful to state somewhere in the c= harter that solutions would only be considered after the problem statement = is in a reasonable shape and the WG participants are in agreement about what needs to be solved.
 
Anoop

 

On Wed, Sep 25, 2013 at 10:28 AM, Ron Parker <Ron_Parker@affirmednetworks.com> wrote:
Thomas,

I agree that the notion of transparent service is not necessary to incorpor= ate in our work.

   Ron


-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, September 25, 2013 1:24 PM
To: Ron Parker
Cc: Paul Quinn (paulq); <adrian@olddog.co.uk>; = Anoop Ghanwani; <nsc@ietf.org>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3]

Ron,

> So is the definition of transparent -- packets are unchanged (headers,=
> content, etc.) and routing/switching path is unaltered?
> Or is it just the former?  The mere diversion to a service node w= ould
> seem to constitute "routing/switching is altered".

I think the point is we don't exactly have an agreed to defintion of "= transparent" in the NSC context, so it's not particularly helpful to u= se it in describing NSC behavior without being clear about what is meant.
For services in NSC, packets clearly will get modified in some cases (e.g. = NAT or proxies) but won't in others. So distinguishing types of services by= how much they change the packets they inspect is probably not helpful for = NSC. NSC doesn't really care *what* the services does, just that the service exists and packets need to be ste= ered to travel through the service.

Thomas

 

--_000_B4CF12F64861194990FEA0AE39F9B1620EABC25Bxmbrcdx14ciscoc_-- From mn1921@att.com Thu Sep 26 08:36: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 412AA11E8147 for ; Thu, 26 Sep 2013 08:36:08 -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 XnXwoA0huB8k for ; Thu, 26 Sep 2013 08:36:01 -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 5707321E809E for ; Thu, 26 Sep 2013 08:35:22 -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 84454425.4c536940.9261607.00-574.25485081.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 26 Sep 2013 15:35:36 +0000 (UTC) X-MXL-Hash: 52445448547626d2-0c9239597a07ca2e7bdf7d4e9326403b2b0572ff 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 33454425.0.9261577.00-340.25484437.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 26 Sep 2013 15:35:16 +0000 (UTC) X-MXL-Hash: 5244543445fb028d-3ee88b84ac4d7e29b40d319765696ddafec7ca06 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 r8QFZEO8015869; Thu, 26 Sep 2013 11:35:14 -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 r8QFYq6c015479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Sep 2013 11:35:07 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 26 Sep 2013 15:34:37 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.03.0158.001; Thu, 26 Sep 2013 11:34:37 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXOIIA///I2MCAAEu+gP//wPdwgAFY24D//7+64AAIrpkAAAf8x8D//8WsgIAAN1RA Date: Thu, 26 Sep 2013 15:34:37 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012A3998@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.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=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=-s3I2kwCOWQA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=FFZ-zzI3G] X-AnalysisOut: [zMA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=VnNF1IyMAAAA:8 ] X-AnalysisOut: [a=ToED_HQuu2u2DOUwt2kA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10] Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 15:36:09 -0000 I understand. Why such document is specifically singled out in the charter? Let's leave i= t to the solutions. Maria > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Thursday, September 26, 2013 10:51 AM > To: NAPIERALA, MARIA H > Cc: nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter >=20 > That is talking about context information - notice all the *and's* in > the > sentence ;-) >=20 > On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: >=20 > >This paragraph is good. > > > >I was pointing out that the item 3 (under "Specifically, the SFC WG is > >chartered to deliver the following" heading) is implying a specific > >solution (which is fine but it should not be the only one...): > > > >"3) Generic Service Function Chaining Encapsulation: A document will > >describe the single service-level data plane encapsulation format for > >conveying the service function chain and the service function path, > and > >for communicating context information between nodes that implement > >service functions..." > > > > > >Maria > > > >> -----Original Message----- > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> Sent: Thursday, September 26, 2013 10:31 AM > >> To: NAPIERALA, MARIA H > >> Cc: nsc@ietf.org > >> Subject: Re: [nsc] New NSC WG Charter > >> > >> Yes and I believe the following text from the charter covers that -> > >> "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." > >> > >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: > >> > >> >Jim, > >> > > >> >I said the opposite, i.e., how to carry metadata should be part of > the > >> >charter but how to carry the metadata should not necessarily > dictate > >> how > >> >the service chain path itself is realized. > >> > > >> >Maria > >> > > >> >> -----Original Message----- > >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> >> Sent: Thursday, September 26, 2013 10:13 AM > >> >> To: NAPIERALA, MARIA H; Thomas Narten > >> >> Cc: nsc@ietf.org > >> >> Subject: Re: [nsc] New NSC WG Charter > >> >> > >> >> Hi Maria, > >> >> > >> >> Hope you are well. I do not believe the new charter text prevents > >> the > >> >> realization of a service chain *without* metadata/context > >> information. > >> >> > >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: > >> >> > >> >> >I believe the NSC architecture should not preclude the service > >> chain > >> >> >path/topology from being realized with some existing (and > standard > >> ;-) > >> >> >network overlay (=3Dvirtual network) technique. But if the > decision > >> is > >> >> made > >> >> >that it does then this should be clearly stated in the charter. > >> >> >What must be common to the service chain path solutions is, IMO, > >> the > >> >> >method for carrying the metadata/context information. > >> >> > > >> >> >Maria > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Thomas Narten [mailto:narten@us.ibm.com] > >> >> >> Sent: Wednesday, September 25, 2013 5:24 PM > >> >> >> To: NAPIERALA, MARIA H > >> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org > >> >> >> Subject: Re: [nsc] New NSC WG Charter > >> >> >> > >> >> >> "NAPIERALA, MARIA H" writes: > >> >> >> > >> >> >> > The group charter's write-up says that: "The Service > Function > >> >> >> > Chaining (SFC) working group will develop new approaches to > >> >> service > >> >> >> > delivery ..." (i.e., not one "approach" but "approaches", > which > >> >> >> > means more than one). > >> >> >> > >> >> >> > But then is states that a document will be developed such > that > >> it > >> >> >> > "will describe *the(?) single* service-level data plane > >> >> >> > encapsulation format for conveying the service function > chain > >> and > >> >> >> > the service function path associated with data packets, and > >> for > >> >> >> > carrying context information between nodes that implement > >> service > >> >> >> > functions". > >> >> >> > >> >> >> > How to do you reconcile those two statements? > >> >> >> > >> >> >> Note: this inconsistency existed in the earlier charter, I > didn't > >> >> >> introduce it. :-) > >> >> >> > >> >> >> I think for the service plane data encapsulation, we should > aim > >> for > >> >> >> one. I'm understand the concern about writing that into the > >> charter > >> >> in > >> >> >> absolute terms, as I think the WG should have room to discuss > and > >> it > >> >> >> may be too early to be definitive. But unless there is > compelling > >> >> >> reason, we should have one encap. (BTW, nothing new here.. > this > >> is > >> >> >> normal IETF.) > >> >> >> > >> >> >> That said, I don't see the need for more than one encap. Does > >> anyone > >> >> >> think we do? And if so, why? > >> >> >> > >> >> >> > In my opinion, we should open the door for more than one > >> solution > >> >> to > >> >> >> > service chaining. > >> >> >> > >> >> >> Ah, "solution to service chaining" (to me) is more than the > >> encap, > >> >> >> including the control plane and related stuff. So even if we > >> develop > >> >> >> one encap, that doesn't necessarily mean there is only one > >> >> >> "solution". So the inconsistency may not be quite as strong as > >> first > >> >> >> seems. > >> >> >> > >> >> >> Suggestion. change: > >> >> >> > >> >> >> A document will describe the single service-level data plane > >> >> >> encapsulation format ... > >> >> >> > >> >> >> To: > >> >> >> > >> >> >> A document will describe a service-level data plane > >> encapsulation > >> >> >> format ... > >> >> >> > >> >> >> this is a bit weaker, but still does (implicitely) suggest one > >> >> encap. > >> >> >> > >> >> >> or, if folk think this is not good enough, we could add text > >> saying > >> >> we > >> >> >> are aiming for one, and will only do more if ... > >> >> >> > >> >> >> But personally, I think it would be fine to have the charter > say > >> one > >> >> >> encap, and if the WG concludes that one encap isn't what is > >> needed, > >> >> >> then recharter. We shouldn't look at rechartering as > >> "impossible". > >> >> We > >> >> >> just need to be able to make the case that more than one encap > is > >> >> >> necessary. If we can do that, I wouldn't think rechartering > would > >> be > >> >> a > >> >> >> big deal. > >> >> >> > >> >> >> Thomas > >> >> > > >> > > > From ghanwani@gmail.com Thu Sep 26 10:47: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 0980821E80AD for ; Thu, 26 Sep 2013 10:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 vLmpJ4xtDcqu for ; Thu, 26 Sep 2013 10:47:17 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0F67F21E80AB for ; Thu, 26 Sep 2013 10:47:08 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x55so1563750wes.10 for ; Thu, 26 Sep 2013 10:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TgZ842gyiN1GzVOM0Nd0b/W850T3BKgk3/Zsgizx/Ho=; b=gNpeVDnrq5nMfkf4CmqAoKYQON2HS3J7zMm0nPofEQDaOCfie1v6SV95eZmICSifu3 xEX+kOuksOCW4T/A/dSQmy3ScFvP4zCBi1wpymTzyjmfDUjmsVwJK0dBSqtfmgbkHHHV vAwXWaLAFMNUrhi1U50oeuPqfHp39/1+O4GRM31SSbGDxcE6WjiC12cVr5qfV/+pnx4M MmAumruxIvXSAWlWYcsXPesFRaMVrRBs71c6cbfeTl0hc7XQ9Q6/wVUNqYB4c4AwnvH8 JqRtMjjGcZadfj/RLMGxhw+6zWog8vo4SauCpDaKebAPXthcfcv+F6WArPcDZJtwXLaQ osqw== MIME-Version: 1.0 X-Received: by 10.180.184.107 with SMTP id et11mr28785225wic.60.1380217628044; Thu, 26 Sep 2013 10:47:08 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.217.54.6 with HTTP; Thu, 26 Sep 2013 10:47:07 -0700 (PDT) In-Reply-To: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> <064001ceba06$27012680$75037380$@olddog.co.uk> <201309251724.r8PHO9hk031606@cichlid.raleigh.ibm.com> Date: Thu, 26 Sep 2013 10:47:07 -0700 X-Google-Sender-Auth: QKNYLJ8R0wBRcZri12bWRP4TSg8 Message-ID: From: Anoop Ghanwani To: "Paul Quinn (paulq)" Content-Type: multipart/alternative; boundary=001a11c227ee6eb2e104e74cf5bb Cc: ramki Krishnan , "nsc@ietf.org" Subject: Re: [nsc] transparent vs. non-transparent services [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: Thu, 26 Sep 2013 17:47:19 -0000 --001a11c227ee6eb2e104e74cf5bb Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, The two big issues are the ones that I already alluded to. First, it would be good to have more clarity around transparent vs non-transparent appliances (otherwise you have folks like Thomas who think it only applies to transparent appliances, and folks like me who wonder how non-transparent appliances are supposed to work with this). The second issue is around multiple layers of overlays. There is reference to metadata, yet it is not clear if metadata must appear multiple times in the frame if the service is applied at L2 vs L3 vs L4. I can't see how the document can deal with this without getting into some specific examples. A relatively minor thing would be better clarify around overlays. Normally when I think of overlays, I think tunnels, not regular layering. But it seems like Adrian, for example, has a differing view. The document should clarify what it really means by network overlay by giving some examples. The way the document is currently written captures the problem well, but at a very high-level. It is easy to get a gist of what's going on, but it leaves a lot of room for interpretation as to the scope of the problem being tackled. Anoop On Thu, Sep 26, 2013 at 8:10 AM, Paul Quinn (paulq) wrote: > Hi Anoop, Ramki, > > Great to see that you both have read the problem statement! Let's make > this constructive: we'd love to see your detailed comments. Please send > them to the list, and/or the draft authors and we'll review them. > > Paul > > On Sep 25, 2013, at 6:59 PM, ramki Krishnan > wrote: > > >>It may be that as Thomas says, we are not going to worry about > non-transparent appliances at all, but then I'm not sure how we even > implement something like a load balancer.**** > > >> Finally, I do think the problem statement needs a lot of work before > we get to solutions. I think it would be useful to state somewhere in the > charter that solutions would only be considered after the problem statement > is in a reasonable shape and the WG participants are in agreement about > what needs to be solved.**** > > Agree with Anoop. We do need to clarify this aspect in the problem > statement.**** > > Thanks,**** > Ramki**** > > *From:* nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf Of > *Anoop Ghanwani > *Sent:* Wednesday, September 25, 2013 11:11 AM > *To:* Ron Parker > *Cc:* Thomas Narten; ; Paul Quinn (paulq); < > nsc@ietf.org> > *Subject:* Re: [nsc] transparent vs. non-transparent services [was Re: > New NSC WG Charter - charter bullet #3]**** > ** ** > When I mentioned transparent/non-transparent, I meant that there was > some change in the packet headers (whether at the IP, MAC, or TCP layers) > for packets that were going to be subject to the service in question, in > the non-transparent case. In other words, for the transparent case, I > cannot tell by looking at the packet headers whether or not the packet > would be subject to that service. Clearly, there are others who think > transparent/non-transparent mean something else. And that's just simply > because there is not standard terminology, which perhaps the WG can help > define.**** > ** ** > I think this also plays into where in the packet the NSC header goes, > and whether there can be multiple instances of the NSC header in the packet. > **** > ** ** > If a certain layer's header is terminated at a service box, it would be > a layering violation to carry the NSC header beyond that point.**** > ** ** > For instance, if the NSC header is located between the MAC and IP > header, and the packet hits a load balancer that changes the IP & MAC > headers, that device would need to create a new NSC header.**** > ** ** > It may be that as Thomas says, we are not going to worry about > non-transparent appliances at all, but then I'm not sure how we even > implement something like a load balancer.**** > ** ** > Finally, I do think the problem statement needs a lot of work before we > get to solutions. I think it would be useful to state somewhere in the > charter that solutions would only be considered after the problem statement > is in a reasonable shape and the WG participants are in agreement about > what needs to be solved.**** > ** ** > Anoop**** > > ** ** > On Wed, Sep 25, 2013 at 10:28 AM, Ron Parker < > Ron_Parker@affirmednetworks.com> wrote:**** > Thomas, > > I agree that the notion of transparent service is not necessary to > incorporate in our work. > > Ron**** > > > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Wednesday, September 25, 2013 1:24 PM > To: Ron Parker > Cc: Paul Quinn (paulq); ; Anoop Ghanwani; < > nsc@ietf.org> > Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New > NSC WG Charter - charter bullet #3]**** > > Ron, > > > So is the definition of transparent -- packets are unchanged (headers, > > content, etc.) and routing/switching path is unaltered? > > Or is it just the former? The mere diversion to a service node would > > seem to constitute "routing/switching is altered". > > I think the point is we don't exactly have an agreed to defintion of > "transparent" in the NSC context, so it's not particularly helpful to use > it in describing NSC behavior without being clear about what is meant. > > For services in NSC, packets clearly will get modified in some cases (e.g. > NAT or proxies) but won't in others. So distinguishing types of services by > how much they change the packets they inspect is probably not helpful for > NSC. NSC doesn't really care *what* the services does, just that the > service exists and packets need to be steered to travel through the service. > > Thomas**** > ** ** > > > --001a11c227ee6eb2e104e74cf5bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Paul,

The two big issues are the one= s that I already alluded to. =A0

First, it would b= e good to have more clarity around transparent vs non-transparent appliance= s (otherwise you have folks like Thomas who think it only applies to transp= arent appliances, and folks like me who wonder how non-transparent applianc= es are supposed to work with this).

The second issue is around multiple layers of overlays.= =A0There is reference to metadata, yet it is not clear if metadata must ap= pear multiple times in the frame if the service is applied at L2 vs L3 vs L= 4.

I can't see how the document can deal with this wit= hout getting into some specific examples.

A relati= vely minor thing would be better clarify around overlays. =A0Normally when = I think of overlays, I think tunnels, not regular layering. =A0But it seems= like Adrian, for example, has a differing view. =A0The document should cla= rify what it really means by network overlay by giving some examples.

The way the document is currently written captures the = problem well, but at a very high-level. =A0It is easy to get a gist of what= 's going on, but it leaves a lot of room for interpretation as to the s= cope of the problem being tackled.

Anoop


On Thu, Sep 26, 2013 at 8:10 AM, Paul Quinn (paulq)= <paulq@cisco.com> wrote:
Hi Anoop, Ramki,

Great to see that you both have read the problem statement! =A0Let'= ;s make this constructive: we'd love to see your detailed comments. =A0= Please send them to the list, and/or the draft authors and we'll review= them.

Paul

On Sep 25, 2013, at 6:59 PM, ramki Krishnan <ramk@Brocade.com>
=A0wrote:

>>It ma= y be that as Thomas says, we are not going to worry about non-transparent a= ppliances at all, but then I'm not sure how we even implement something= like a load balancer.
=A0
>> Fina= lly, I do think the problem statement needs a lot of work before we get to = solutions. =A0I think it would be useful to state somewhere in the charter = that solutions would only be considered after the problem statement is in a reasonable shape and the WG participan= ts are in agreement about what needs to be solved.
=A0
Agree with An= oop. We do need to clarify this aspect in the problem statement.<= /u>
=A0
Thanks,
Ramki
=A0
From:=A0= nsc-bounces@ietf.org=A0[mailto:nsc-bounces@ietf.org]=A0On Behalf Of=A0Anoop Ghanwani
Sent:=A0Wednesday, September 25, 2013 11:11 AM
To:=A0Ron Parker
Cc:=A0Thomas Narten; <adrian@olddog.co.uk>; Paul Quinn (paulq); <nsc@ietf.org>
Subject:=A0Re: [nsc] transparent vs. non-transparent se= rvices [was Re: New NSC WG Charter - charter bullet #3]
=A0
When I mentioned transparent/non-transparent, I meant that there was some c= hange in the packet headers (whether at the IP, MAC, or TCP layers) for pac= kets that were going to be subject to the service in question, in the non-t= ransparent case. =A0In other words, for the transparent case, I cannot tell by looking at the packet headers w= hether or not the packet would be subject to that service. =A0Clearly, ther= e are others who think transparent/non-transparent mean something else. =A0= And that's just simply because there is not standard terminology, which perhaps the WG can help define.<= u>
=A0
I think this also plays into where in the packet the NSC header goes, and w= hether there can be multiple instances of the NSC header in the packet.<= /u>
=A0
If a certain layer's header is terminated at a service box, it would be= a layering violation to carry the NSC header beyond that point.<= /u>
=A0
For instance, if the NSC header is located between the MAC and IP header, a= nd the packet hits a load balancer that changes the IP & MAC headers, t= hat device would need to create a new NSC header.
=A0
It may be that as Thomas says, we are not going to worry about non-transpar= ent appliances at all, but then I'm not sure how we even implement some= thing like a load balancer.
=A0
Finally, I do think the problem statement needs a lot of work before we get= to solutions. =A0I think it would be useful to state somewhere in the char= ter that solutions would only be considered after the problem statement is = in a reasonable shape and the WG participants are in agreement about what needs to be solved.
=A0
Anoop

=A0

On Wed, Sep 25, 2013 at 10:28 AM, Ron Parker <Ron_Parker@affirmednetworks.com> wrote:
Thomas,

I agree that the notion of transparent service is not necessary to incorpor= ate in our work.

=A0 =A0Ron


-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com<= /a>]
Sent: Wednesday, September 25, 2013 1:24 PM
To: Ron Parker
Cc: Paul Quinn (paulq); <adrian@olddog.co= .uk>; Anoop Ghanwani; <nsc@ietf.org&g= t;
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3]

Ron,

> So is the definition of transparent -- packets are unchanged (headers,=
> content, etc.) and routing/switching path is unaltered?
> Or is it just the former? =A0The mere diversion to a service node woul= d
> seem to constitute "routing/switching is altered".

I think the point is we don't exactly have an agreed to defintion of &q= uot;transparent" in the NSC context, so it's not particularly help= ful to use it in describing NSC behavior without being clear about what is = meant.

For services in NSC, packets clearly will get modified in some cases (e.g. = NAT or proxies) but won't in others. So distinguishing types of service= s by how much they change the packets they inspect is probably not helpful = for NSC. NSC doesn't really care *what* the services does, just that the service exists and packets need to be ste= ered to travel through the service.

Thomas

=A0


--001a11c227ee6eb2e104e74cf5bb-- From adrian@olddog.co.uk Thu Sep 26 14:45: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 3790A21F9F80 for ; Thu, 26 Sep 2013 14:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 1sLccMrYzWPV for ; Thu, 26 Sep 2013 14:45:50 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 44E5F21F9F21 for ; Thu, 26 Sep 2013 14:45:49 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8QLjk4m007968 for ; Thu, 26 Sep 2013 22:45:46 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8QLjj2D007960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Sep 2013 22:45:46 +0100 From: "Adrian Farrel" To: Date: Thu, 26 Sep 2013 22:45:43 +0100 Message-ID: <027801cebb01$c0a91170$41fb3450$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac67AbrPpt8IxZNRSzKMaqvTxe542Q== Content-Language: en-gb Subject: [nsc] Next steps towards becoming a WG :-) X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 21:45:55 -0000 Hi, Now that the BoF is approved to happen in Vancouver, a datatracker page exists. You can see it at http://datatracker.ietf.org/wg/sfc/ Note that no documents show up because I inconveniently imposed a change in the group name. If you repost your I-D as draft-yourname-sfc-foo they will show on the web page. If you do that, don't forget to send the Secretariat a message saying draft-yourname-nsc-foo is replaced by draft-yourname-sfc-foo so that they tie up the loose ends. If you click on the "Charter" tab, you'll see the straw man for the charter text. I know you are discussing this in detail and Jim and Thomas will bring me any requested change arising from rough consensus. We'll leave the mailing list name at nsc@ietf.org until a WG is actually formed and then cut over to sfc@ietf.org And (just in case anyone gets too excited) none of this actually represents a commitment that a working group will be formed. It is a work in progress. Adrian From adrian@olddog.co.uk Thu Sep 26 15:01: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 7AF5D21E80C1 for ; Thu, 26 Sep 2013 15:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 ve9LV-ENHaQL for ; Thu, 26 Sep 2013 15:01:33 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE5321E80C5 for ; Thu, 26 Sep 2013 15:01:30 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8QM1PU2005123; Thu, 26 Sep 2013 23:01:25 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8QM1OHU005117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Sep 2013 23:01:25 +0100 From: "Adrian Farrel" To: "'NAPIERALA, MARIA H'" , "'Jim Guichard \(jguichar\)'" References: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A3998@MISOUT7MSGUSR9I.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012A3998@MISOUT7MSGUSR9I.ITServices.sbc.com> Date: Thu, 26 Sep 2013 23:01:22 +0100 Message-ID: <028401cebb03$f0431ff0$d0c95fd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGObFkZE+voGokHjQRntDCGkTNLZwJH83f8Ahi+VtSaNiY70A== Content-Language: en-gb Cc: nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 22:01:38 -0000 I have to pile in here :-( Maria, I think you want to say "Don't require me to use a service-level encapsulation to achieve this function". I don't believe you want to say "Allow me to have more than one service-level encapsulation to achieve this function." The text does not in any way preclude having other mechanisms for doing stuff. In particular, configuring service chains at service nodes is an obvious approach. Similarly the service chain information might be distributed (ahead of time) by some other protocol. The text does say that there will be at most one service-level encapsulation. Because setting out to have more than one new encapsulation protocol to do the same thing. Text also says that there will be a service-level encapsulation. Why does it do that? Because, if this WG goes off and decides to tweak every protocol that is out there to make a special way to carry service chain information in that protocol, it will be a disaster (IMNSHO). If this doesn't address your concern, Maria, perhaps rather than try to change the text or comment on what you think the text implies, you could say what it is you want to be able to do. That way we can say whether it is in or out of scope of the current text. Thanks, Adrian > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > NAPIERALA, MARIA H > Sent: 26 September 2013 16:35 > To: Jim Guichard (jguichar) > Cc: nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter > > I understand. > Why such document is specifically singled out in the charter? Let's leave it to the > solutions. > > Maria > > > -----Original Message----- > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > Sent: Thursday, September 26, 2013 10:51 AM > > To: NAPIERALA, MARIA H > > Cc: nsc@ietf.org > > Subject: Re: [nsc] New NSC WG Charter > > > > That is talking about context information - notice all the *and's* in > > the > > sentence ;-) > > > > On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: > > > > >This paragraph is good. > > > > > >I was pointing out that the item 3 (under "Specifically, the SFC WG is > > >chartered to deliver the following" heading) is implying a specific > > >solution (which is fine but it should not be the only one...): > > > > > >"3) Generic Service Function Chaining Encapsulation: A document will > > >describe the single service-level data plane encapsulation format for > > >conveying the service function chain and the service function path, > > and > > >for communicating context information between nodes that implement > > >service functions..." > > > > > > > > >Maria > > > > > >> -----Original Message----- > > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > >> Sent: Thursday, September 26, 2013 10:31 AM > > >> To: NAPIERALA, MARIA H > > >> Cc: nsc@ietf.org > > >> Subject: Re: [nsc] New NSC WG Charter > > >> > > >> Yes and I believe the following text from the charter covers that -> > > >> "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." > > >> > > >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: > > >> > > >> >Jim, > > >> > > > >> >I said the opposite, i.e., how to carry metadata should be part of > > the > > >> >charter but how to carry the metadata should not necessarily > > dictate > > >> how > > >> >the service chain path itself is realized. > > >> > > > >> >Maria > > >> > > > >> >> -----Original Message----- > > >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > >> >> Sent: Thursday, September 26, 2013 10:13 AM > > >> >> To: NAPIERALA, MARIA H; Thomas Narten > > >> >> Cc: nsc@ietf.org > > >> >> Subject: Re: [nsc] New NSC WG Charter > > >> >> > > >> >> Hi Maria, > > >> >> > > >> >> Hope you are well. I do not believe the new charter text prevents > > >> the > > >> >> realization of a service chain *without* metadata/context > > >> information. > > >> >> > > >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: > > >> >> > > >> >> >I believe the NSC architecture should not preclude the service > > >> chain > > >> >> >path/topology from being realized with some existing (and > > standard > > >> ;-) > > >> >> >network overlay (=virtual network) technique. But if the > > decision > > >> is > > >> >> made > > >> >> >that it does then this should be clearly stated in the charter. > > >> >> >What must be common to the service chain path solutions is, IMO, > > >> the > > >> >> >method for carrying the metadata/context information. > > >> >> > > > >> >> >Maria > > >> >> > > > >> >> >> -----Original Message----- > > >> >> >> From: Thomas Narten [mailto:narten@us.ibm.com] > > >> >> >> Sent: Wednesday, September 25, 2013 5:24 PM > > >> >> >> To: NAPIERALA, MARIA H > > >> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org > > >> >> >> Subject: Re: [nsc] New NSC WG Charter > > >> >> >> > > >> >> >> "NAPIERALA, MARIA H" writes: > > >> >> >> > > >> >> >> > The group charter's write-up says that: "The Service > > Function > > >> >> >> > Chaining (SFC) working group will develop new approaches to > > >> >> service > > >> >> >> > delivery ..." (i.e., not one "approach" but "approaches", > > which > > >> >> >> > means more than one). > > >> >> >> > > >> >> >> > But then is states that a document will be developed such > > that > > >> it > > >> >> >> > "will describe *the(?) single* service-level data plane > > >> >> >> > encapsulation format for conveying the service function > > chain > > >> and > > >> >> >> > the service function path associated with data packets, and > > >> for > > >> >> >> > carrying context information between nodes that implement > > >> service > > >> >> >> > functions". > > >> >> >> > > >> >> >> > How to do you reconcile those two statements? > > >> >> >> > > >> >> >> Note: this inconsistency existed in the earlier charter, I > > didn't > > >> >> >> introduce it. :-) > > >> >> >> > > >> >> >> I think for the service plane data encapsulation, we should > > aim > > >> for > > >> >> >> one. I'm understand the concern about writing that into the > > >> charter > > >> >> in > > >> >> >> absolute terms, as I think the WG should have room to discuss > > and > > >> it > > >> >> >> may be too early to be definitive. But unless there is > > compelling > > >> >> >> reason, we should have one encap. (BTW, nothing new here.. > > this > > >> is > > >> >> >> normal IETF.) > > >> >> >> > > >> >> >> That said, I don't see the need for more than one encap. Does > > >> anyone > > >> >> >> think we do? And if so, why? > > >> >> >> > > >> >> >> > In my opinion, we should open the door for more than one > > >> solution > > >> >> to > > >> >> >> > service chaining. > > >> >> >> > > >> >> >> Ah, "solution to service chaining" (to me) is more than the > > >> encap, > > >> >> >> including the control plane and related stuff. So even if we > > >> develop > > >> >> >> one encap, that doesn't necessarily mean there is only one > > >> >> >> "solution". So the inconsistency may not be quite as strong as > > >> first > > >> >> >> seems. > > >> >> >> > > >> >> >> Suggestion. change: > > >> >> >> > > >> >> >> A document will describe the single service-level data plane > > >> >> >> encapsulation format ... > > >> >> >> > > >> >> >> To: > > >> >> >> > > >> >> >> A document will describe a service-level data plane > > >> encapsulation > > >> >> >> format ... > > >> >> >> > > >> >> >> this is a bit weaker, but still does (implicitely) suggest one > > >> >> encap. > > >> >> >> > > >> >> >> or, if folk think this is not good enough, we could add text > > >> saying > > >> >> we > > >> >> >> are aiming for one, and will only do more if ... > > >> >> >> > > >> >> >> But personally, I think it would be fine to have the charter > > say > > >> one > > >> >> >> encap, and if the WG concludes that one encap isn't what is > > >> needed, > > >> >> >> then recharter. We shouldn't look at rechartering as > > >> "impossible". > > >> >> We > > >> >> >> just need to be able to make the case that more than one encap > > is > > >> >> >> necessary. If we can do that, I wouldn't think rechartering > > would > > >> be > > >> >> a > > >> >> >> big deal. > > >> >> >> > > >> >> >> Thomas > > >> >> > > > >> > > > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Thu Sep 26 15: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 0E43821F9B8A for ; Thu, 26 Sep 2013 15:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.452, 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 vKDIXp7QVxuO for ; Thu, 26 Sep 2013 15:05:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E486B21E8099 for ; Thu, 26 Sep 2013 15:05:19 -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 AYH86833; Thu, 26 Sep 2013 22:05:18 +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; Thu, 26 Sep 2013 23:03:23 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 23:04:14 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Thu, 26 Sep 2013 15:04:10 -0700 From: Linda Dunbar To: "Pham, Chuong D" , "Carlos Pignataro (cpignata)" , "Joel M. Halpern" Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac6zlk4fQ/5RtvjWRWGXnZqzywWMVAAQDQiAAAH6ZtAALKf3AABg6Y0QAAFj1rEAFjGCAABXPIWAACmS74AARmqagAAGAzmgABS3/YAACeY9AAAXe0eAACBJw3A= Date: Thu, 26 Sep 2013 22:04:09 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BCFDB4@dfweml509-mbx.china.huawei.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> <52428F89.4040006@joelhalpern.com> <95067C434CE250468B77282634C96ED325FA2181@xmb-aln-x02.cisco.com> <5602569641FB314FB4D9AD5659D41B9C25565D27CB@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C25565D27CB@WSMSG3154V.srv.dir.telstra.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] 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: Thu, 26 Sep 2013 22:05:29 -0000 Chuong,=20 Thanks for the examples.=20 Some questions are inserted below:=20 > -----Original Message----- >=20 > Another example is in the case of Header Enrichment (HE) service in a > Mobile network. A HE function inserts information elements into HTTP > header. What to insert is dependent on the identification of the users > i.e. the MSISDN. Today, IP packets arriving at the HE function do not > contain such non-IP-address user identification. [Linda] "The Header Enrichment service" insert bits to existing HTTP header= of the packets, correct? I've seen other network function modules (or even= BNG) add/change bits to HTTP header to carry information to downstream nod= es. I hope that this kind of encoding bits/fields to existing header should= be acknowledged as a way to carry "Metadata" by the NSC charter.=20 > If the "cost" of carrying this user identification in metadata is > justified, I see great opportunity, especially for Mobile operators > (and Fixed in the case of Fixed Mobile Convergence (FMC)). [Linda] The "HE" example you give earlier doesn't require new Metadata head= er. Do you have any examples to show adding/encoding bits to existing heade= r (HTTP, TCP, or IP header) is not enough? >=20 > Regards, > Chuong >=20 >=20 >=20 > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: Wednesday, 25 September 2013 10:07 PM > To: Joel M. Halpern > Cc: nsc@ietf.org; adrian@olddog.co.uk; Linda Dunbar > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 >=20 > This, access/subscriber identification, is a good example. >=20 > Another typical example is to use metadata to share the result of > ingress classification, or network information (as e.g., to be used in > subscriber identification) to then be used for policy in a service > function downstream the service path. One such example is VRF > information. >=20 > Thanks, >=20 > -- Carlos. >=20 > On Sep 25, 2013, at 3:23 AM, Joel M. Halpern > wrote: >=20 > > 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 mn1921@att.com Thu Sep 26 15:24: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 0387621F9D89 for ; Thu, 26 Sep 2013 15:24:06 -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 qrxiUjDtbBJU for ; Thu, 26 Sep 2013 15:24:00 -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 BF0F021F9BD3 for ; Thu, 26 Sep 2013 15:23:59 -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 ff3b4425.2aaacb80b940.9535841.00-531.26264440.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 26 Sep 2013 22:23:59 +0000 (UTC) X-MXL-Hash: 5244b3ff715cc9f9-686cc20ef90393a96dd640ca37edd3691581b97f 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 6f3b4425.0.9535706.00-417.26264130.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 26 Sep 2013 22:23:51 +0000 (UTC) X-MXL-Hash: 5244b3f72615f49a-c912c23e17bbe53bdad5839a0fe0a77f696c7239 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 r8QMNoSG013732; Thu, 26 Sep 2013 18:23:50 -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 r8QMNYWU013605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Sep 2013 18:23:43 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (MISOUT7MSGHUB9A.itservices.sbc.com [144.151.223.62]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 26 Sep 2013 22:23:21 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.03.0158.001; Thu, 26 Sep 2013 18:23:20 -0400 From: "NAPIERALA, MARIA H" To: "adrian@olddog.co.uk" , "'Jim Guichard (jguichar)'" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXOIIA///I2MCAAEu+gP//wPdwgAFY24D//7+64AAIrpkAAAf8x8D//8WsgIAAN1RAgABA2QCAAD13kA== Date: Thu, 26 Sep 2013 22:23:20 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012A3E2D@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A3998@MISOUT7MSGUSR9I.ITServices.sbc.com> <028401cebb03$f0431ff0$d0c95fd0$@olddog.co.uk> In-Reply-To: <028401cebb03$f0431ff0$d0c95fd0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.171.5] 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=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=14cQzkQizn0A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=FFZ-zzI3G] X-AnalysisOut: [zMA:10 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 ] X-AnalysisOut: [a=VnNF1IyMAAAA:8 a=Wy6XDnBMuvKT5u0sIycA:9 a=CjuIK1q_8ugA:1] X-AnalysisOut: [0 a=jqlaW5bC1iAA:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=] X-AnalysisOut: [Hz7IrDYlS0cA:10 a=KAcQikHvfYG3lL_5:21 a=RhmbMlOQUSfGWJhP:2] X-AnalysisOut: [1] Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 22:24:06 -0000 I thought I said it already: the ability to carry the metadata without requ= iring to also carry service chain information (quote from the charter's wri= te up: "conveying the service function chain and the service function path"= ) in the data packet. If you think this is already in the charter or it is outside of the charter= , I would like to know. I cannot infer it from the write-up. Maria > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Thursday, September 26, 2013 6:01 PM > To: NAPIERALA, MARIA H; 'Jim Guichard (jguichar)' > Cc: nsc@ietf.org > Subject: RE: [nsc] New NSC WG Charter >=20 > I have to pile in here :-( >=20 > Maria, I think you want to say "Don't require me to use a service-level > encapsulation to achieve this function". > I don't believe you want to say "Allow me to have more than one > service-level > encapsulation to achieve this function." >=20 > The text does not in any way preclude having other mechanisms for doing > stuff. > In particular, configuring service chains at service nodes is an > obvious > approach. Similarly the service chain information might be distributed > (ahead of > time) by some other protocol. >=20 > The text does say that there will be at most one service-level > encapsulation. > Because setting out to have more than one new encapsulation protocol to > do the > same thing. >=20 > Text also says that there will be a service-level encapsulation. > Why does it do that? > Because, if this WG goes off and decides to tweak every protocol that > is out > there to make a special way to carry service chain information in that > protocol, > it will be a disaster (IMNSHO). >=20 > If this doesn't address your concern, Maria, perhaps rather than try to > change > the text or comment on what you think the text implies, you could say > what it is > you want to be able to do. That way we can say whether it is in or out > of scope > of the current text. >=20 > Thanks, > Adrian >=20 >=20 > > -----Original Message----- > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > > NAPIERALA, MARIA H > > Sent: 26 September 2013 16:35 > > To: Jim Guichard (jguichar) > > Cc: nsc@ietf.org > > Subject: Re: [nsc] New NSC WG Charter > > > > I understand. > > Why such document is specifically singled out in the charter? Let's > leave it > to the > > solutions. > > > > Maria > > > > > -----Original Message----- > > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > Sent: Thursday, September 26, 2013 10:51 AM > > > To: NAPIERALA, MARIA H > > > Cc: nsc@ietf.org > > > Subject: Re: [nsc] New NSC WG Charter > > > > > > That is talking about context information - notice all the *and's* > in > > > the > > > sentence ;-) > > > > > > On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: > > > > > > >This paragraph is good. > > > > > > > >I was pointing out that the item 3 (under "Specifically, the SFC > WG is > > > >chartered to deliver the following" heading) is implying a > specific > > > >solution (which is fine but it should not be the only one...): > > > > > > > >"3) Generic Service Function Chaining Encapsulation: A document > will > > > >describe the single service-level data plane encapsulation format > for > > > >conveying the service function chain and the service function > path, > > > and > > > >for communicating context information between nodes that implement > > > >service functions..." > > > > > > > > > > > >Maria > > > > > > > >> -----Original Message----- > > > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > >> Sent: Thursday, September 26, 2013 10:31 AM > > > >> To: NAPIERALA, MARIA H > > > >> Cc: nsc@ietf.org > > > >> Subject: Re: [nsc] New NSC WG Charter > > > >> > > > >> Yes and I believe the following text from the charter covers > that -> > > > >> "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." > > > >> > > > >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" > wrote: > > > >> > > > >> >Jim, > > > >> > > > > >> >I said the opposite, i.e., how to carry metadata should be part > of > > > the > > > >> >charter but how to carry the metadata should not necessarily > > > dictate > > > >> how > > > >> >the service chain path itself is realized. > > > >> > > > > >> >Maria > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > >> >> Sent: Thursday, September 26, 2013 10:13 AM > > > >> >> To: NAPIERALA, MARIA H; Thomas Narten > > > >> >> Cc: nsc@ietf.org > > > >> >> Subject: Re: [nsc] New NSC WG Charter > > > >> >> > > > >> >> Hi Maria, > > > >> >> > > > >> >> Hope you are well. I do not believe the new charter text > prevents > > > >> the > > > >> >> realization of a service chain *without* metadata/context > > > >> information. > > > >> >> > > > >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" > wrote: > > > >> >> > > > >> >> >I believe the NSC architecture should not preclude the > service > > > >> chain > > > >> >> >path/topology from being realized with some existing (and > > > standard > > > >> ;-) > > > >> >> >network overlay (=3Dvirtual network) technique. But if the > > > decision > > > >> is > > > >> >> made > > > >> >> >that it does then this should be clearly stated in the > charter. > > > >> >> >What must be common to the service chain path solutions is, > IMO, > > > >> the > > > >> >> >method for carrying the metadata/context information. > > > >> >> > > > > >> >> >Maria > > > >> >> > > > > >> >> >> -----Original Message----- > > > >> >> >> From: Thomas Narten [mailto:narten@us.ibm.com] > > > >> >> >> Sent: Wednesday, September 25, 2013 5:24 PM > > > >> >> >> To: NAPIERALA, MARIA H > > > >> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org > > > >> >> >> Subject: Re: [nsc] New NSC WG Charter > > > >> >> >> > > > >> >> >> "NAPIERALA, MARIA H" writes: > > > >> >> >> > > > >> >> >> > The group charter's write-up says that: "The Service > > > Function > > > >> >> >> > Chaining (SFC) working group will develop new approaches > to > > > >> >> service > > > >> >> >> > delivery ..." (i.e., not one "approach" but > "approaches", > > > which > > > >> >> >> > means more than one). > > > >> >> >> > > > >> >> >> > But then is states that a document will be developed > such > > > that > > > >> it > > > >> >> >> > "will describe *the(?) single* service-level data plane > > > >> >> >> > encapsulation format for conveying the service function > > > chain > > > >> and > > > >> >> >> > the service function path associated with data packets, > and > > > >> for > > > >> >> >> > carrying context information between nodes that > implement > > > >> service > > > >> >> >> > functions". > > > >> >> >> > > > >> >> >> > How to do you reconcile those two statements? > > > >> >> >> > > > >> >> >> Note: this inconsistency existed in the earlier charter, I > > > didn't > > > >> >> >> introduce it. :-) > > > >> >> >> > > > >> >> >> I think for the service plane data encapsulation, we > should > > > aim > > > >> for > > > >> >> >> one. I'm understand the concern about writing that into > the > > > >> charter > > > >> >> in > > > >> >> >> absolute terms, as I think the WG should have room to > discuss > > > and > > > >> it > > > >> >> >> may be too early to be definitive. But unless there is > > > compelling > > > >> >> >> reason, we should have one encap. (BTW, nothing new here.. > > > this > > > >> is > > > >> >> >> normal IETF.) > > > >> >> >> > > > >> >> >> That said, I don't see the need for more than one encap. > Does > > > >> anyone > > > >> >> >> think we do? And if so, why? > > > >> >> >> > > > >> >> >> > In my opinion, we should open the door for more than one > > > >> solution > > > >> >> to > > > >> >> >> > service chaining. > > > >> >> >> > > > >> >> >> Ah, "solution to service chaining" (to me) is more than > the > > > >> encap, > > > >> >> >> including the control plane and related stuff. So even if > we > > > >> develop > > > >> >> >> one encap, that doesn't necessarily mean there is only one > > > >> >> >> "solution". So the inconsistency may not be quite as > strong as > > > >> first > > > >> >> >> seems. > > > >> >> >> > > > >> >> >> Suggestion. change: > > > >> >> >> > > > >> >> >> A document will describe the single service-level data > plane > > > >> >> >> encapsulation format ... > > > >> >> >> > > > >> >> >> To: > > > >> >> >> > > > >> >> >> A document will describe a service-level data plane > > > >> encapsulation > > > >> >> >> format ... > > > >> >> >> > > > >> >> >> this is a bit weaker, but still does (implicitely) suggest > one > > > >> >> encap. > > > >> >> >> > > > >> >> >> or, if folk think this is not good enough, we could add > text > > > >> saying > > > >> >> we > > > >> >> >> are aiming for one, and will only do more if ... > > > >> >> >> > > > >> >> >> But personally, I think it would be fine to have the > charter > > > say > > > >> one > > > >> >> >> encap, and if the WG concludes that one encap isn't what > is > > > >> needed, > > > >> >> >> then recharter. We shouldn't look at rechartering as > > > >> "impossible". > > > >> >> We > > > >> >> >> just need to be able to make the case that more than one > encap > > > is > > > >> >> >> necessary. If we can do that, I wouldn't think > rechartering > > > would > > > >> be > > > >> >> a > > > >> >> >> big deal. > > > >> >> >> > > > >> >> >> Thomas > > > >> >> > > > > >> > > > > > > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc From adrian@olddog.co.uk Thu Sep 26 15:40: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 DEA4F21F9C90 for ; Thu, 26 Sep 2013 15:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 r2Sy+BIMU6XE for ; Thu, 26 Sep 2013 15:40:02 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 10B0321E80C3 for ; Thu, 26 Sep 2013 15:39:59 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8QMdqM2022303; Thu, 26 Sep 2013 23:39:52 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8QMdnvi022284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Sep 2013 23:39:51 +0100 From: "Adrian Farrel" To: "'NAPIERALA, MARIA H'" , "'Jim Guichard \(jguichar\)'" References: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A3998@MISOUT7MSGUSR9I.ITServices.sbc.com> <028401cebb03$f0431ff0$d0c95fd0$@olddog.co.uk> <1D70D757A2C9D54D83B4CBD7625FA80E012A3E2D@MISOUT7MSGUSR9I.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012A3E2D@MISOUT7MSGUSR9I.ITServices.sbc.com> Date: Thu, 26 Sep 2013 23:39:47 +0100 Message-ID: <02a401cebb09$4f0301e0$ed0905a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGObFkZE+voGokHjQRntDCGkTNLZwJH83f8Ahi+VtQBSIcuEgEWGw96miM9QKA= Content-Language: en-gb Cc: nsc@ietf.org Subject: Re: [nsc] New NSC WG Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 22:40:07 -0000 It is unequivocally in the charter. The text that bothers you is: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. The use of "and" does not always mean that you MUST do both things. It means you can do both. Silly example: The English language allows an English speaker to order food at lunchtime and to make proposals of marriage. This does not require me to propose to the waiter each time I ask for a burrito. In the text in the draft charter it says: We will make one encapsulation protocol. You can use this protocol to carry the service function chain. You can also use this protocol to carry the service function path. You can also use this protocol to carry metadata. OK? Adrian > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > Sent: 26 September 2013 23:23 > To: adrian@olddog.co.uk; 'Jim Guichard (jguichar)' > Cc: nsc@ietf.org > Subject: RE: [nsc] New NSC WG Charter > > I thought I said it already: the ability to carry the metadata without requiring to > also carry service chain information (quote from the charter's write up: > "conveying the service function chain and the service function path") in the data > packet. > If you think this is already in the charter or it is outside of the charter, I would like > to know. I cannot infer it from the write-up. > > Maria > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Thursday, September 26, 2013 6:01 PM > > To: NAPIERALA, MARIA H; 'Jim Guichard (jguichar)' > > Cc: nsc@ietf.org > > Subject: RE: [nsc] New NSC WG Charter > > > > I have to pile in here :-( > > > > Maria, I think you want to say "Don't require me to use a service-level > > encapsulation to achieve this function". > > I don't believe you want to say "Allow me to have more than one > > service-level > > encapsulation to achieve this function." > > > > The text does not in any way preclude having other mechanisms for doing > > stuff. > > In particular, configuring service chains at service nodes is an > > obvious > > approach. Similarly the service chain information might be distributed > > (ahead of > > time) by some other protocol. > > > > The text does say that there will be at most one service-level > > encapsulation. > > Because setting out to have more than one new encapsulation protocol to > > do the > > same thing. > > > > Text also says that there will be a service-level encapsulation. > > Why does it do that? > > Because, if this WG goes off and decides to tweak every protocol that > > is out > > there to make a special way to carry service chain information in that > > protocol, > > it will be a disaster (IMNSHO). > > > > If this doesn't address your concern, Maria, perhaps rather than try to > > change > > the text or comment on what you think the text implies, you could say > > what it is > > you want to be able to do. That way we can say whether it is in or out > > of scope > > of the current text. > > > > Thanks, > > Adrian > > > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > > > NAPIERALA, MARIA H > > > Sent: 26 September 2013 16:35 > > > To: Jim Guichard (jguichar) > > > Cc: nsc@ietf.org > > > Subject: Re: [nsc] New NSC WG Charter > > > > > > I understand. > > > Why such document is specifically singled out in the charter? Let's > > leave it > > to the > > > solutions. > > > > > > Maria > > > > > > > -----Original Message----- > > > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > > Sent: Thursday, September 26, 2013 10:51 AM > > > > To: NAPIERALA, MARIA H > > > > Cc: nsc@ietf.org > > > > Subject: Re: [nsc] New NSC WG Charter > > > > > > > > That is talking about context information - notice all the *and's* > > in > > > > the > > > > sentence ;-) > > > > > > > > On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: > > > > > > > > >This paragraph is good. > > > > > > > > > >I was pointing out that the item 3 (under "Specifically, the SFC > > WG is > > > > >chartered to deliver the following" heading) is implying a > > specific > > > > >solution (which is fine but it should not be the only one...): > > > > > > > > > >"3) Generic Service Function Chaining Encapsulation: A document > > will > > > > >describe the single service-level data plane encapsulation format > > for > > > > >conveying the service function chain and the service function > > path, > > > > and > > > > >for communicating context information between nodes that implement > > > > >service functions..." > > > > > > > > > > > > > > >Maria > > > > > > > > > >> -----Original Message----- > > > > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > > >> Sent: Thursday, September 26, 2013 10:31 AM > > > > >> To: NAPIERALA, MARIA H > > > > >> Cc: nsc@ietf.org > > > > >> Subject: Re: [nsc] New NSC WG Charter > > > > >> > > > > >> Yes and I believe the following text from the charter covers > > that -> > > > > >> "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." > > > > >> > > > > >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" > > wrote: > > > > >> > > > > >> >Jim, > > > > >> > > > > > >> >I said the opposite, i.e., how to carry metadata should be part > > of > > > > the > > > > >> >charter but how to carry the metadata should not necessarily > > > > dictate > > > > >> how > > > > >> >the service chain path itself is realized. > > > > >> > > > > > >> >Maria > > > > >> > > > > > >> >> -----Original Message----- > > > > >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > > >> >> Sent: Thursday, September 26, 2013 10:13 AM > > > > >> >> To: NAPIERALA, MARIA H; Thomas Narten > > > > >> >> Cc: nsc@ietf.org > > > > >> >> Subject: Re: [nsc] New NSC WG Charter > > > > >> >> > > > > >> >> Hi Maria, > > > > >> >> > > > > >> >> Hope you are well. I do not believe the new charter text > > prevents > > > > >> the > > > > >> >> realization of a service chain *without* metadata/context > > > > >> information. > > > > >> >> > > > > >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" > > wrote: > > > > >> >> > > > > >> >> >I believe the NSC architecture should not preclude the > > service > > > > >> chain > > > > >> >> >path/topology from being realized with some existing (and > > > > standard > > > > >> ;-) > > > > >> >> >network overlay (=virtual network) technique. But if the > > > > decision > > > > >> is > > > > >> >> made > > > > >> >> >that it does then this should be clearly stated in the > > charter. > > > > >> >> >What must be common to the service chain path solutions is, > > IMO, > > > > >> the > > > > >> >> >method for carrying the metadata/context information. > > > > >> >> > > > > > >> >> >Maria > > > > >> >> > > > > > >> >> >> -----Original Message----- > > > > >> >> >> From: Thomas Narten [mailto:narten@us.ibm.com] > > > > >> >> >> Sent: Wednesday, September 25, 2013 5:24 PM > > > > >> >> >> To: NAPIERALA, MARIA H > > > > >> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org > > > > >> >> >> Subject: Re: [nsc] New NSC WG Charter > > > > >> >> >> > > > > >> >> >> "NAPIERALA, MARIA H" writes: > > > > >> >> >> > > > > >> >> >> > The group charter's write-up says that: "The Service > > > > Function > > > > >> >> >> > Chaining (SFC) working group will develop new approaches > > to > > > > >> >> service > > > > >> >> >> > delivery ..." (i.e., not one "approach" but > > "approaches", > > > > which > > > > >> >> >> > means more than one). > > > > >> >> >> > > > > >> >> >> > But then is states that a document will be developed > > such > > > > that > > > > >> it > > > > >> >> >> > "will describe *the(?) single* service-level data plane > > > > >> >> >> > encapsulation format for conveying the service function > > > > chain > > > > >> and > > > > >> >> >> > the service function path associated with data packets, > > and > > > > >> for > > > > >> >> >> > carrying context information between nodes that > > implement > > > > >> service > > > > >> >> >> > functions". > > > > >> >> >> > > > > >> >> >> > How to do you reconcile those two statements? > > > > >> >> >> > > > > >> >> >> Note: this inconsistency existed in the earlier charter, I > > > > didn't > > > > >> >> >> introduce it. :-) > > > > >> >> >> > > > > >> >> >> I think for the service plane data encapsulation, we > > should > > > > aim > > > > >> for > > > > >> >> >> one. I'm understand the concern about writing that into > > the > > > > >> charter > > > > >> >> in > > > > >> >> >> absolute terms, as I think the WG should have room to > > discuss > > > > and > > > > >> it > > > > >> >> >> may be too early to be definitive. But unless there is > > > > compelling > > > > >> >> >> reason, we should have one encap. (BTW, nothing new here.. > > > > this > > > > >> is > > > > >> >> >> normal IETF.) > > > > >> >> >> > > > > >> >> >> That said, I don't see the need for more than one encap. > > Does > > > > >> anyone > > > > >> >> >> think we do? And if so, why? > > > > >> >> >> > > > > >> >> >> > In my opinion, we should open the door for more than one > > > > >> solution > > > > >> >> to > > > > >> >> >> > service chaining. > > > > >> >> >> > > > > >> >> >> Ah, "solution to service chaining" (to me) is more than > > the > > > > >> encap, > > > > >> >> >> including the control plane and related stuff. So even if > > we > > > > >> develop > > > > >> >> >> one encap, that doesn't necessarily mean there is only one > > > > >> >> >> "solution". So the inconsistency may not be quite as > > strong as > > > > >> first > > > > >> >> >> seems. > > > > >> >> >> > > > > >> >> >> Suggestion. change: > > > > >> >> >> > > > > >> >> >> A document will describe the single service-level data > > plane > > > > >> >> >> encapsulation format ... > > > > >> >> >> > > > > >> >> >> To: > > > > >> >> >> > > > > >> >> >> A document will describe a service-level data plane > > > > >> encapsulation > > > > >> >> >> format ... > > > > >> >> >> > > > > >> >> >> this is a bit weaker, but still does (implicitely) suggest > > one > > > > >> >> encap. > > > > >> >> >> > > > > >> >> >> or, if folk think this is not good enough, we could add > > text > > > > >> saying > > > > >> >> we > > > > >> >> >> are aiming for one, and will only do more if ... > > > > >> >> >> > > > > >> >> >> But personally, I think it would be fine to have the > > charter > > > > say > > > > >> one > > > > >> >> >> encap, and if the WG concludes that one encap isn't what > > is > > > > >> needed, > > > > >> >> >> then recharter. We shouldn't look at rechartering as > > > > >> "impossible". > > > > >> >> We > > > > >> >> >> just need to be able to make the case that more than one > > encap > > > > is > > > > >> >> >> necessary. If we can do that, I wouldn't think > > rechartering > > > > would > > > > >> be > > > > >> >> a > > > > >> >> >> big deal. > > > > >> >> >> > > > > >> >> >> Thomas > > > > >> >> > > > > > >> > > > > > > > > > > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc From jdrake@juniper.net Thu Sep 26 15:50: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 1EAC321E80C3 for ; Thu, 26 Sep 2013 15:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 i+vNymxU-QHf for ; Thu, 26 Sep 2013 15:50:02 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id C62E321F84A8 for ; Thu, 26 Sep 2013 15:49:59 -0700 (PDT) Received: from mail182-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Thu, 26 Sep 2013 22:49:59 +0000 Received: from mail182-va3 (localhost [127.0.0.1]) by mail182-va3-R.bigfish.com (Postfix) with ESMTP id DC6DB3001FB; Thu, 26 Sep 2013 22:49:58 +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: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I542I1dbaI1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail182-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(76104003)(164054003)(24454002)(377454003)(479174003)(189002)(199002)(51704005)(13464003)(79102001)(561944002)(54356001)(74366001)(53806001)(74706001)(63696002)(74876001)(74316001)(83072001)(77982001)(59766001)(65816001)(76786001)(76796001)(76576001)(54316002)(56816003)(77096001)(56776001)(81542001)(81342001)(66066001)(80022001)(76482001)(69226001)(49866001)(4396001)(80976001)(81686001)(47976001)(19580405001)(50986001)(83322001)(47736001)(81816001)(15975445006)(74502001)(47446002)(31966008)(74662001)(51856001)(19580395003)(33646001)(46102001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail182-va3 (localhost.localdomain [127.0.0.1]) by mail182-va3 (MessageSwitch) id 1380235796364665_6511; Thu, 26 Sep 2013 22:49:56 +0000 (UTC) Received: from VA3EHSMHS043.bigfish.com (unknown [10.7.14.227]) by mail182-va3.bigfish.com (Postfix) with ESMTP id 5341360049; Thu, 26 Sep 2013 22:49:56 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS043.bigfish.com (10.7.99.53) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 26 Sep 2013 22:49:55 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.359.1; Thu, 26 Sep 2013 22:49:55 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 26 Sep 2013 22:49:52 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.220]) with mapi id 15.00.0775.005; Thu, 26 Sep 2013 22:49:52 +0000 From: John E Drake To: "adrian@olddog.co.uk" , "'NAPIERALA, MARIA H'" , "'Jim Guichard (jguichar)'" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnW9XQAgAAOJQCAAAZxgIAABuUAgAES7ICAAAQYAIAAARcAgAAEy4CAAADIgIAADB6AgABsDgCAAAYkAIAABJiAgAACf3A= Date: Thu, 26 Sep 2013 22:49:51 +0000 Message-ID: <59dd8fd701564d11a08a646137671c2b@BY2PR05MB142.namprd05.prod.outlook.com> References: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A3998@MISOUT7MSGUSR9I.ITServices.sbc.com> <028401cebb03$f0431ff0$d0c95fd0$@olddog.co.uk> <1D70D757A2C9D54D83B4CBD7625FA80E012A3E2D@MISOUT7MSGUSR9I.ITServices.sbc.com> <02a401cebb09$4f0301e0$ed0905a0$@olddog.co.uk> In-Reply-To: <02a401cebb09$4f0301e0$ed0905a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0981815F2F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 22:50:08 -0000 Comment inline Yours Irrespectively, John > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: Thursday, September 26, 2013 3:40 PM > To: 'NAPIERALA, MARIA H'; 'Jim Guichard (jguichar)' > Cc: nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter >=20 > It is unequivocally in the charter. >=20 > The text that bothers you is: > A document will describe the single service-level data plane > encapsulation format for conveying the service function chain > and the service function path, and for communicating context > information between nodes that implement service functions. >=20 > The use of "and" does not always mean that you MUST do both things. It > means you can do both. >=20 > Silly example: > The English language allows an English speaker to order food at lunchtime > and to make proposals of marriage. > This does not require me to propose to the waiter each time I ask for a > burrito. [JD] Although, I have seen this happen. >=20 > In the text in the draft charter it says: > We will make one encapsulation protocol. > You can use this protocol to carry the service function chain. > You can also use this protocol to carry the service function path. > You can also use this protocol to carry metadata. >=20 > OK? >=20 > Adrian >=20 > > -----Original Message----- > > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > > Sent: 26 September 2013 23:23 > > To: adrian@olddog.co.uk; 'Jim Guichard (jguichar)' > > Cc: nsc@ietf.org > > Subject: RE: [nsc] New NSC WG Charter > > > > I thought I said it already: the ability to carry the metadata without > requiring to > > also carry service chain information (quote from the charter's write up= : > > "conveying the service function chain and the service function path") > > in the > data > > packet. > > If you think this is already in the charter or it is outside of the > > charter, I > would like > > to know. I cannot infer it from the write-up. > > > > Maria > > > > > -----Original Message----- > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > Sent: Thursday, September 26, 2013 6:01 PM > > > To: NAPIERALA, MARIA H; 'Jim Guichard (jguichar)' > > > Cc: nsc@ietf.org > > > Subject: RE: [nsc] New NSC WG Charter > > > > > > I have to pile in here :-( > > > > > > Maria, I think you want to say "Don't require me to use a > > > service-level encapsulation to achieve this function". > > > I don't believe you want to say "Allow me to have more than one > > > service-level encapsulation to achieve this function." > > > > > > The text does not in any way preclude having other mechanisms for > > > doing stuff. > > > In particular, configuring service chains at service nodes is an > > > obvious approach. Similarly the service chain information might be > > > distributed (ahead of > > > time) by some other protocol. > > > > > > The text does say that there will be at most one service-level > > > encapsulation. > > > Because setting out to have more than one new encapsulation protocol > > > to do the same thing. > > > > > > Text also says that there will be a service-level encapsulation. > > > Why does it do that? > > > Because, if this WG goes off and decides to tweak every protocol > > > that is out there to make a special way to carry service chain > > > information in that protocol, it will be a disaster (IMNSHO). > > > > > > If this doesn't address your concern, Maria, perhaps rather than try > > > to change the text or comment on what you think the text implies, > > > you could say what it is you want to be able to do. That way we can > > > say whether it is in or out of scope of the current text. > > > > > > Thanks, > > > Adrian > > > > > > > > > > -----Original Message----- > > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > > > > Of NAPIERALA, MARIA H > > > > Sent: 26 September 2013 16:35 > > > > To: Jim Guichard (jguichar) > > > > Cc: nsc@ietf.org > > > > Subject: Re: [nsc] New NSC WG Charter > > > > > > > > I understand. > > > > Why such document is specifically singled out in the charter? > > > > Let's > > > leave it > > > to the > > > > solutions. > > > > > > > > Maria > > > > > > > > > -----Original Message----- > > > > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > > > Sent: Thursday, September 26, 2013 10:51 AM > > > > > To: NAPIERALA, MARIA H > > > > > Cc: nsc@ietf.org > > > > > Subject: Re: [nsc] New NSC WG Charter > > > > > > > > > > That is talking about context information - notice all the > > > > > *and's* > > > in > > > > > the > > > > > sentence ;-) > > > > > > > > > > On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" > wrote: > > > > > > > > > > >This paragraph is good. > > > > > > > > > > > >I was pointing out that the item 3 (under "Specifically, the > > > > > >SFC > > > WG is > > > > > >chartered to deliver the following" heading) is implying a > > > specific > > > > > >solution (which is fine but it should not be the only one...): > > > > > > > > > > > >"3) Generic Service Function Chaining Encapsulation: A document > > > will > > > > > >describe the single service-level data plane encapsulation > > > > > >format > > > for > > > > > >conveying the service function chain and the service function > > > path, > > > > > and > > > > > >for communicating context information between nodes that > > > > > >implement service functions..." > > > > > > > > > > > > > > > > > >Maria > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > > > >> Sent: Thursday, September 26, 2013 10:31 AM > > > > > >> To: NAPIERALA, MARIA H > > > > > >> Cc: nsc@ietf.org > > > > > >> Subject: Re: [nsc] New NSC WG Charter > > > > > >> > > > > > >> Yes and I believe the following text from the charter covers > > > that -> > > > > > >> "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." > > > > > >> > > > > > >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" > > > wrote: > > > > > >> > > > > > >> >Jim, > > > > > >> > > > > > > >> >I said the opposite, i.e., how to carry metadata should be > > > > > >> >part > > > of > > > > > the > > > > > >> >charter but how to carry the metadata should not necessarily > > > > > dictate > > > > > >> how > > > > > >> >the service chain path itself is realized. > > > > > >> > > > > > > >> >Maria > > > > > >> > > > > > > >> >> -----Original Message----- > > > > > >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > > > >> >> Sent: Thursday, September 26, 2013 10:13 AM > > > > > >> >> To: NAPIERALA, MARIA H; Thomas Narten > > > > > >> >> Cc: nsc@ietf.org > > > > > >> >> Subject: Re: [nsc] New NSC WG Charter > > > > > >> >> > > > > > >> >> Hi Maria, > > > > > >> >> > > > > > >> >> Hope you are well. I do not believe the new charter text > > > prevents > > > > > >> the > > > > > >> >> realization of a service chain *without* metadata/context > > > > > >> information. > > > > > >> >> > > > > > >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" > > > > wrote: > > > > > >> >> > > > > > >> >> >I believe the NSC architecture should not preclude the > > > service > > > > > >> chain > > > > > >> >> >path/topology from being realized with some existing (and > > > > > standard > > > > > >> ;-) > > > > > >> >> >network overlay (=3Dvirtual network) technique. But if the > > > > > decision > > > > > >> is > > > > > >> >> made > > > > > >> >> >that it does then this should be clearly stated in the > > > charter. > > > > > >> >> >What must be common to the service chain path solutions > > > > > >> >> >is, > > > IMO, > > > > > >> the > > > > > >> >> >method for carrying the metadata/context information. > > > > > >> >> > > > > > > >> >> >Maria > > > > > >> >> > > > > > > >> >> >> -----Original Message----- > > > > > >> >> >> From: Thomas Narten [mailto:narten@us.ibm.com] > > > > > >> >> >> Sent: Wednesday, September 25, 2013 5:24 PM > > > > > >> >> >> To: NAPIERALA, MARIA H > > > > > >> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org > > > > > >> >> >> Subject: Re: [nsc] New NSC WG Charter > > > > > >> >> >> > > > > > >> >> >> "NAPIERALA, MARIA H" writes: > > > > > >> >> >> > > > > > >> >> >> > The group charter's write-up says that: "The Service > > > > > Function > > > > > >> >> >> > Chaining (SFC) working group will develop new > > > > > >> >> >> > approaches > > > to > > > > > >> >> service > > > > > >> >> >> > delivery ..." (i.e., not one "approach" but > > > "approaches", > > > > > which > > > > > >> >> >> > means more than one). > > > > > >> >> >> > > > > > >> >> >> > But then is states that a document will be developed > > > such > > > > > that > > > > > >> it > > > > > >> >> >> > "will describe *the(?) single* service-level data > > > > > >> >> >> > plane encapsulation format for conveying the service > > > > > >> >> >> > function > > > > > chain > > > > > >> and > > > > > >> >> >> > the service function path associated with data > > > > > >> >> >> > packets, > > > and > > > > > >> for > > > > > >> >> >> > carrying context information between nodes that > > > implement > > > > > >> service > > > > > >> >> >> > functions". > > > > > >> >> >> > > > > > >> >> >> > How to do you reconcile those two statements? > > > > > >> >> >> > > > > > >> >> >> Note: this inconsistency existed in the earlier > > > > > >> >> >> charter, I > > > > > didn't > > > > > >> >> >> introduce it. :-) > > > > > >> >> >> > > > > > >> >> >> I think for the service plane data encapsulation, we > > > should > > > > > aim > > > > > >> for > > > > > >> >> >> one. I'm understand the concern about writing that into > > > the > > > > > >> charter > > > > > >> >> in > > > > > >> >> >> absolute terms, as I think the WG should have room to > > > discuss > > > > > and > > > > > >> it > > > > > >> >> >> may be too early to be definitive. But unless there is > > > > > compelling > > > > > >> >> >> reason, we should have one encap. (BTW, nothing new > here.. > > > > > this > > > > > >> is > > > > > >> >> >> normal IETF.) > > > > > >> >> >> > > > > > >> >> >> That said, I don't see the need for more than one encap. > > > Does > > > > > >> anyone > > > > > >> >> >> think we do? And if so, why? > > > > > >> >> >> > > > > > >> >> >> > In my opinion, we should open the door for more than > > > > > >> >> >> > one > > > > > >> solution > > > > > >> >> to > > > > > >> >> >> > service chaining. > > > > > >> >> >> > > > > > >> >> >> Ah, "solution to service chaining" (to me) is more than > > > the > > > > > >> encap, > > > > > >> >> >> including the control plane and related stuff. So even > > > > > >> >> >> if > > > we > > > > > >> develop > > > > > >> >> >> one encap, that doesn't necessarily mean there is only > > > > > >> >> >> one "solution". So the inconsistency may not be quite > > > > > >> >> >> as > > > strong as > > > > > >> first > > > > > >> >> >> seems. > > > > > >> >> >> > > > > > >> >> >> Suggestion. change: > > > > > >> >> >> > > > > > >> >> >> A document will describe the single service-level data > > > plane > > > > > >> >> >> encapsulation format ... > > > > > >> >> >> > > > > > >> >> >> To: > > > > > >> >> >> > > > > > >> >> >> A document will describe a service-level data plane > > > > > >> encapsulation > > > > > >> >> >> format ... > > > > > >> >> >> > > > > > >> >> >> this is a bit weaker, but still does (implicitely) > > > > > >> >> >> suggest > > > one > > > > > >> >> encap. > > > > > >> >> >> > > > > > >> >> >> or, if folk think this is not good enough, we could add > > > text > > > > > >> saying > > > > > >> >> we > > > > > >> >> >> are aiming for one, and will only do more if ... > > > > > >> >> >> > > > > > >> >> >> But personally, I think it would be fine to have the > > > charter > > > > > say > > > > > >> one > > > > > >> >> >> encap, and if the WG concludes that one encap isn't > > > > > >> >> >> what > > > is > > > > > >> needed, > > > > > >> >> >> then recharter. We shouldn't look at rechartering as > > > > > >> "impossible". > > > > > >> >> We > > > > > >> >> >> just need to be able to make the case that more than > > > > > >> >> >> one > > > encap > > > > > is > > > > > >> >> >> necessary. If we can do that, I wouldn't think > > > rechartering > > > > > would > > > > > >> be > > > > > >> >> a > > > > > >> >> >> big deal. > > > > > >> >> >> > > > > > >> >> >> Thomas > > > > > >> >> > > > > > > >> > > > > > > > > > > > > > > > _______________________________________________ > > > > nsc mailing list > > > > nsc@ietf.org > > > > https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 From mn1921@att.com Thu Sep 26 16:20: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 E360A21E80C3 for ; Thu, 26 Sep 2013 16:20:47 -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 vpIaZWRUdr0s for ; Thu, 26 Sep 2013 16:20:39 -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 5162E11E80F2 for ; Thu, 26 Sep 2013 16:20:39 -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 741c4425.2aaacae0a940.9563040.00-533.26338258.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 26 Sep 2013 23:20:39 +0000 (UTC) X-MXL-Hash: 5244c1475abc7113-a7646e8c7840d9b0caa9cb10d139e3271074c6bf 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 641c4425.0.9563031.00-234.26338229.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 26 Sep 2013 23:20:38 +0000 (UTC) X-MXL-Hash: 5244c1460b0c2eef-2a798e0cf76f82cfd5df03ca205228123f50c8c4 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 r8QNKbBN025811; Thu, 26 Sep 2013 19:20:38 -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 r8QNKP0p025718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Sep 2013 19:20:32 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (MISOUT7MSGHUB9A.itservices.sbc.com [144.151.223.62]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 26 Sep 2013 23:20:12 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.03.0158.001; Thu, 26 Sep 2013 19:20:12 -0400 From: "NAPIERALA, MARIA H" To: "adrian@olddog.co.uk" , "'Jim Guichard (jguichar)'" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXOIIA///I2MCAAEu+gP//wPdwgAFY24D//7+64AAIrpkAAAf8x8D//8WsgIAAN1RAgABA2QCAAD13kP//zUSAgAA6GgA= Date: Thu, 26 Sep 2013 23:20:12 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012A3EB3@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A3998@MISOUT7MSGUSR9I.ITServices.sbc.com> <028401cebb03$f0431ff0$d0c95fd0$@olddog.co.uk> <1D70D757A2C9D54D83B4CBD7625FA80E012A3E2D@MISOUT7MSGUSR9I.ITServices.sbc.com> <02a401cebb09$4f0301e0$ed0905a0$@olddog.co.uk> In-Reply-To: <02a401cebb09$4f0301e0$ed0905a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.171.5] 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=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=14cQzkQizn0A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=FFZ-zzI3G] X-AnalysisOut: [zMA:10 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 ] X-AnalysisOut: [a=VnNF1IyMAAAA:8 a=z0h1WtFl5r7tGluaEEEA:9 a=CjuIK1q_8ugA:1] X-AnalysisOut: [0 a=Hz7IrDYlS0cA:10 a=jqlaW5bC1iAA:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [JfD0Fch1gWkA:10 a=HyXAYvuPnJ7uQ_ft:21 a=ZMRKNdf0BBcHJm5P:2] X-AnalysisOut: [1] Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 23:20:51 -0000 > It is unequivocally in the charter. > The text that bothers you is: > A document will describe the single service-level data plane > encapsulation format for conveying the service function chain > and the service function path, and for communicating context > information between nodes that implement service functions. >=20 > The use of "and" does not always mean that you MUST do both things. It Not always, but it might. And in the text above this distinction is not cle= ar. > means you > can do both. >=20 > Silly example: > The English language allows an English speaker to order food at > lunchtime and to > make proposals of marriage. > This does not require me to propose to the waiter each time I ask for a > burrito. So let's change the text as follows (to avoid explaining what "and" means): "A document will describe the single service-level data plane encapsulation format for conveying information such as service function chain ID, service function path, or for communicating cont= ext information between nodes that implement service functions." > In the text in the draft charter it says: > We will make one encapsulation protocol. > You can use this protocol to carry the service function chain. > You can also use this protocol to carry the service function path. > You can also use this protocol to carry metadata. >=20 > OK? >=20 > Adrian >=20 > > -----Original Message----- > > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > > Sent: 26 September 2013 23:23 > > To: adrian@olddog.co.uk; 'Jim Guichard (jguichar)' > > Cc: nsc@ietf.org > > Subject: RE: [nsc] New NSC WG Charter > > > > I thought I said it already: the ability to carry the metadata > without > requiring to > > also carry service chain information (quote from the charter's write > up: > > "conveying the service function chain and the service function path") > in the > data > > packet. > > If you think this is already in the charter or it is outside of the > charter, I > would like > > to know. I cannot infer it from the write-up. > > > > Maria > > > > > -----Original Message----- > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > Sent: Thursday, September 26, 2013 6:01 PM > > > To: NAPIERALA, MARIA H; 'Jim Guichard (jguichar)' > > > Cc: nsc@ietf.org > > > Subject: RE: [nsc] New NSC WG Charter > > > > > > I have to pile in here :-( > > > > > > Maria, I think you want to say "Don't require me to use a service- > level > > > encapsulation to achieve this function". > > > I don't believe you want to say "Allow me to have more than one > > > service-level > > > encapsulation to achieve this function." > > > > > > The text does not in any way preclude having other mechanisms for > doing > > > stuff. > > > In particular, configuring service chains at service nodes is an > > > obvious > > > approach. Similarly the service chain information might be > distributed > > > (ahead of > > > time) by some other protocol. > > > > > > The text does say that there will be at most one service-level > > > encapsulation. > > > Because setting out to have more than one new encapsulation > protocol to > > > do the > > > same thing. > > > > > > Text also says that there will be a service-level encapsulation. > > > Why does it do that? > > > Because, if this WG goes off and decides to tweak every protocol > that > > > is out > > > there to make a special way to carry service chain information in > that > > > protocol, > > > it will be a disaster (IMNSHO). > > > > > > If this doesn't address your concern, Maria, perhaps rather than > try to > > > change > > > the text or comment on what you think the text implies, you could > say > > > what it is > > > you want to be able to do. That way we can say whether it is in or > out > > > of scope > > > of the current text. > > > > > > Thanks, > > > Adrian > > > > > > > > > > -----Original Message----- > > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > Behalf Of > > > > NAPIERALA, MARIA H > > > > Sent: 26 September 2013 16:35 > > > > To: Jim Guichard (jguichar) > > > > Cc: nsc@ietf.org > > > > Subject: Re: [nsc] New NSC WG Charter > > > > > > > > I understand. > > > > Why such document is specifically singled out in the charter? > Let's > > > leave it > > > to the > > > > solutions. > > > > > > > > Maria > > > > > > > > > -----Original Message----- > > > > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > > > Sent: Thursday, September 26, 2013 10:51 AM > > > > > To: NAPIERALA, MARIA H > > > > > Cc: nsc@ietf.org > > > > > Subject: Re: [nsc] New NSC WG Charter > > > > > > > > > > That is talking about context information - notice all the > *and's* > > > in > > > > > the > > > > > sentence ;-) > > > > > > > > > > On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" > wrote: > > > > > > > > > > >This paragraph is good. > > > > > > > > > > > >I was pointing out that the item 3 (under "Specifically, the > SFC > > > WG is > > > > > >chartered to deliver the following" heading) is implying a > > > specific > > > > > >solution (which is fine but it should not be the only one...): > > > > > > > > > > > >"3) Generic Service Function Chaining Encapsulation: A > document > > > will > > > > > >describe the single service-level data plane encapsulation > format > > > for > > > > > >conveying the service function chain and the service function > > > path, > > > > > and > > > > > >for communicating context information between nodes that > implement > > > > > >service functions..." > > > > > > > > > > > > > > > > > >Maria > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > > > >> Sent: Thursday, September 26, 2013 10:31 AM > > > > > >> To: NAPIERALA, MARIA H > > > > > >> Cc: nsc@ietf.org > > > > > >> Subject: Re: [nsc] New NSC WG Charter > > > > > >> > > > > > >> Yes and I believe the following text from the charter covers > > > that -> > > > > > >> "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." > > > > > >> > > > > > >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" > > > wrote: > > > > > >> > > > > > >> >Jim, > > > > > >> > > > > > > >> >I said the opposite, i.e., how to carry metadata should be > part > > > of > > > > > the > > > > > >> >charter but how to carry the metadata should not > necessarily > > > > > dictate > > > > > >> how > > > > > >> >the service chain path itself is realized. > > > > > >> > > > > > > >> >Maria > > > > > >> > > > > > > >> >> -----Original Message----- > > > > > >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > > > >> >> Sent: Thursday, September 26, 2013 10:13 AM > > > > > >> >> To: NAPIERALA, MARIA H; Thomas Narten > > > > > >> >> Cc: nsc@ietf.org > > > > > >> >> Subject: Re: [nsc] New NSC WG Charter > > > > > >> >> > > > > > >> >> Hi Maria, > > > > > >> >> > > > > > >> >> Hope you are well. I do not believe the new charter text > > > prevents > > > > > >> the > > > > > >> >> realization of a service chain *without* metadata/context > > > > > >> information. > > > > > >> >> > > > > > >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" > > > wrote: > > > > > >> >> > > > > > >> >> >I believe the NSC architecture should not preclude the > > > service > > > > > >> chain > > > > > >> >> >path/topology from being realized with some existing > (and > > > > > standard > > > > > >> ;-) > > > > > >> >> >network overlay (=3Dvirtual network) technique. But if the > > > > > decision > > > > > >> is > > > > > >> >> made > > > > > >> >> >that it does then this should be clearly stated in the > > > charter. > > > > > >> >> >What must be common to the service chain path solutions > is, > > > IMO, > > > > > >> the > > > > > >> >> >method for carrying the metadata/context information. > > > > > >> >> > > > > > > >> >> >Maria > > > > > >> >> > > > > > > >> >> >> -----Original Message----- > > > > > >> >> >> From: Thomas Narten [mailto:narten@us.ibm.com] > > > > > >> >> >> Sent: Wednesday, September 25, 2013 5:24 PM > > > > > >> >> >> To: NAPIERALA, MARIA H > > > > > >> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org > > > > > >> >> >> Subject: Re: [nsc] New NSC WG Charter > > > > > >> >> >> > > > > > >> >> >> "NAPIERALA, MARIA H" writes: > > > > > >> >> >> > > > > > >> >> >> > The group charter's write-up says that: "The Service > > > > > Function > > > > > >> >> >> > Chaining (SFC) working group will develop new > approaches > > > to > > > > > >> >> service > > > > > >> >> >> > delivery ..." (i.e., not one "approach" but > > > "approaches", > > > > > which > > > > > >> >> >> > means more than one). > > > > > >> >> >> > > > > > >> >> >> > But then is states that a document will be developed > > > such > > > > > that > > > > > >> it > > > > > >> >> >> > "will describe *the(?) single* service-level data > plane > > > > > >> >> >> > encapsulation format for conveying the service > function > > > > > chain > > > > > >> and > > > > > >> >> >> > the service function path associated with data > packets, > > > and > > > > > >> for > > > > > >> >> >> > carrying context information between nodes that > > > implement > > > > > >> service > > > > > >> >> >> > functions". > > > > > >> >> >> > > > > > >> >> >> > How to do you reconcile those two statements? > > > > > >> >> >> > > > > > >> >> >> Note: this inconsistency existed in the earlier > charter, I > > > > > didn't > > > > > >> >> >> introduce it. :-) > > > > > >> >> >> > > > > > >> >> >> I think for the service plane data encapsulation, we > > > should > > > > > aim > > > > > >> for > > > > > >> >> >> one. I'm understand the concern about writing that > into > > > the > > > > > >> charter > > > > > >> >> in > > > > > >> >> >> absolute terms, as I think the WG should have room to > > > discuss > > > > > and > > > > > >> it > > > > > >> >> >> may be too early to be definitive. But unless there is > > > > > compelling > > > > > >> >> >> reason, we should have one encap. (BTW, nothing new > here.. > > > > > this > > > > > >> is > > > > > >> >> >> normal IETF.) > > > > > >> >> >> > > > > > >> >> >> That said, I don't see the need for more than one > encap. > > > Does > > > > > >> anyone > > > > > >> >> >> think we do? And if so, why? > > > > > >> >> >> > > > > > >> >> >> > In my opinion, we should open the door for more than > one > > > > > >> solution > > > > > >> >> to > > > > > >> >> >> > service chaining. > > > > > >> >> >> > > > > > >> >> >> Ah, "solution to service chaining" (to me) is more > than > > > the > > > > > >> encap, > > > > > >> >> >> including the control plane and related stuff. So even > if > > > we > > > > > >> develop > > > > > >> >> >> one encap, that doesn't necessarily mean there is only > one > > > > > >> >> >> "solution". So the inconsistency may not be quite as > > > strong as > > > > > >> first > > > > > >> >> >> seems. > > > > > >> >> >> > > > > > >> >> >> Suggestion. change: > > > > > >> >> >> > > > > > >> >> >> A document will describe the single service-level > data > > > plane > > > > > >> >> >> encapsulation format ... > > > > > >> >> >> > > > > > >> >> >> To: > > > > > >> >> >> > > > > > >> >> >> A document will describe a service-level data plane > > > > > >> encapsulation > > > > > >> >> >> format ... > > > > > >> >> >> > > > > > >> >> >> this is a bit weaker, but still does (implicitely) > suggest > > > one > > > > > >> >> encap. > > > > > >> >> >> > > > > > >> >> >> or, if folk think this is not good enough, we could > add > > > text > > > > > >> saying > > > > > >> >> we > > > > > >> >> >> are aiming for one, and will only do more if ... > > > > > >> >> >> > > > > > >> >> >> But personally, I think it would be fine to have the > > > charter > > > > > say > > > > > >> one > > > > > >> >> >> encap, and if the WG concludes that one encap isn't > what > > > is > > > > > >> needed, > > > > > >> >> >> then recharter. We shouldn't look at rechartering as > > > > > >> "impossible". > > > > > >> >> We > > > > > >> >> >> just need to be able to make the case that more than > one > > > encap > > > > > is > > > > > >> >> >> necessary. If we can do that, I wouldn't think > > > rechartering > > > > > would > > > > > >> be > > > > > >> >> a > > > > > >> >> >> big deal. > > > > > >> >> >> > > > > > >> >> >> Thomas > > > > > >> >> > > > > > > >> > > > > > > > > > > > > > > > _______________________________________________ > > > > nsc mailing list > > > > nsc@ietf.org > > > > https://www.ietf.org/mailman/listinfo/nsc From kgray@juniper.net Thu Sep 26 16:29:43 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF90B21F9FA2 for ; Thu, 26 Sep 2013 16:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=-0.833, 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 YQAYBUQ1NzbN for ; Thu, 26 Sep 2013 16:29:39 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id 676FC21F9A45 for ; Thu, 26 Sep 2013 16:29:34 -0700 (PDT) Received: from mail76-db9-R.bigfish.com (10.174.16.232) by DB9EHSOBE018.bigfish.com (10.174.14.81) with Microsoft SMTP Server id 14.1.225.22; Thu, 26 Sep 2013 23:29:33 +0000 Received: from mail76-db9 (localhost [127.0.0.1]) by mail76-db9-R.bigfish.com (Postfix) with ESMTP id DB0803000D6; Thu, 26 Sep 2013 23:29:32 +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(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail76-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:(24454002)(377454003)(479174003)(51704005)(13464003)(189002)(199002)(80976001)(47446002)(4396001)(83072001)(77096001)(56816003)(74502001)(76176001)(81816001)(31966008)(81686001)(76796001)(76786001)(74662001)(79102001)(15975445006)(47736001)(49866001)(50986001)(47976001)(74876001)(19580395003)(83322001)(19580405001)(74366001)(59766001)(54356001)(65816001)(53806001)(51856001)(77982001)(81342001)(56776001)(54316002)(36756003)(76482001)(81542001)(46102001)(69226001)(83506001)(63696002)(74706001)(80022001); 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 mail76-db9 (localhost.localdomain [127.0.0.1]) by mail76-db9 (MessageSwitch) id 1380238170775077_10934; Thu, 26 Sep 2013 23:29:30 +0000 (UTC) Received: from DB9EHSMHS022.bigfish.com (unknown [10.174.16.250]) by mail76-db9.bigfish.com (Postfix) with ESMTP id B864D14006C; Thu, 26 Sep 2013 23:29:30 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS022.bigfish.com (10.174.14.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 26 Sep 2013 23:29:30 +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.359.1; Thu, 26 Sep 2013 23:29:27 +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.775.9; Thu, 26 Sep 2013 23:29:26 +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.0775.005; Thu, 26 Sep 2013 23:29:26 +0000 From: Ken Gray To: "adrian@olddog.co.uk" , "'NAPIERALA, MARIA H'" , "'Jim Guichard (jguichar)'" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnW9XQAgAAOJQCAAAZxgIAABuUAgAES7ICAAAQYAIAAARcAgAAEy4CAAADIgIAADB6AgABsDgD//9WHgA== Date: Thu, 26 Sep 2013 23:29:25 +0000 Message-ID: In-Reply-To: <028401cebb03$f0431ff0$d0c95fd0$@olddog.co.uk> 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: 0981815F2F Content-Type: text/plain; charset="us-ascii" Content-ID: <261D9CE00489494B9AFC159B83BE9371@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] New NSC 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: Thu, 26 Sep 2013 23:29:43 -0000 +1=20 >Text also says that there will be a service-level encapsulation. >Why does it do that? >Because, if this WG goes off and decides to tweak every protocol that is >out >there to make a special way to carry service chain information in that >protocol, >it will be a disaster (IMNSHO). > > > > >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> NAPIERALA, MARIA H >> Sent: 26 September 2013 16:35 >> To: Jim Guichard (jguichar) >> Cc: nsc@ietf.org >> Subject: Re: [nsc] New NSC WG Charter >>=20 >> I understand. >> Why such document is specifically singled out in the charter? Let's >>leave it >to the >> solutions. >>=20 >> Maria >>=20 >> > -----Original Message----- >> > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> > Sent: Thursday, September 26, 2013 10:51 AM >> > To: NAPIERALA, MARIA H >> > Cc: nsc@ietf.org >> > Subject: Re: [nsc] New NSC WG Charter >> > >> > That is talking about context information - notice all the *and's* in >> > the >> > sentence ;-) >> > >> > On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: >> > >> > >This paragraph is good. >> > > >> > >I was pointing out that the item 3 (under "Specifically, the SFC WG >>is >> > >chartered to deliver the following" heading) is implying a specific >> > >solution (which is fine but it should not be the only one...): >> > > >> > >"3) Generic Service Function Chaining Encapsulation: A document will >> > >describe the single service-level data plane encapsulation format for >> > >conveying the service function chain and the service function path, >> > and >> > >for communicating context information between nodes that implement >> > >service functions..." >> > > >> > > >> > >Maria >> > > >> > >> -----Original Message----- >> > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> > >> Sent: Thursday, September 26, 2013 10:31 AM >> > >> To: NAPIERALA, MARIA H >> > >> Cc: nsc@ietf.org >> > >> Subject: Re: [nsc] New NSC WG Charter >> > >> >> > >> Yes and I believe the following text from the charter covers that >>-> >> > >> "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." >> > >> >> > >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: >> > >> >> > >> >Jim, >> > >> > >> > >> >I said the opposite, i.e., how to carry metadata should be part of >> > the >> > >> >charter but how to carry the metadata should not necessarily >> > dictate >> > >> how >> > >> >the service chain path itself is realized. >> > >> > >> > >> >Maria >> > >> > >> > >> >> -----Original Message----- >> > >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> > >> >> Sent: Thursday, September 26, 2013 10:13 AM >> > >> >> To: NAPIERALA, MARIA H; Thomas Narten >> > >> >> Cc: nsc@ietf.org >> > >> >> Subject: Re: [nsc] New NSC WG Charter >> > >> >> >> > >> >> Hi Maria, >> > >> >> >> > >> >> Hope you are well. I do not believe the new charter text >>prevents >> > >> the >> > >> >> realization of a service chain *without* metadata/context >> > >> information. >> > >> >> >> > >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: >> > >> >> >> > >> >> >I believe the NSC architecture should not preclude the service >> > >> chain >> > >> >> >path/topology from being realized with some existing (and >> > standard >> > >> ;-) >> > >> >> >network overlay (=3Dvirtual network) technique. But if the >> > decision >> > >> is >> > >> >> made >> > >> >> >that it does then this should be clearly stated in the charter. >> > >> >> >What must be common to the service chain path solutions is, >>IMO, >> > >> the >> > >> >> >method for carrying the metadata/context information. >> > >> >> > >> > >> >> >Maria >> > >> >> > >> > >> >> >> -----Original Message----- >> > >> >> >> From: Thomas Narten [mailto:narten@us.ibm.com] >> > >> >> >> Sent: Wednesday, September 25, 2013 5:24 PM >> > >> >> >> To: NAPIERALA, MARIA H >> > >> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org >> > >> >> >> Subject: Re: [nsc] New NSC WG Charter >> > >> >> >> >> > >> >> >> "NAPIERALA, MARIA H" writes: >> > >> >> >> >> > >> >> >> > The group charter's write-up says that: "The Service >> > Function >> > >> >> >> > Chaining (SFC) working group will develop new approaches to >> > >> >> service >> > >> >> >> > delivery ..." (i.e., not one "approach" but "approaches", >> > which >> > >> >> >> > means more than one). >> > >> >> >> >> > >> >> >> > But then is states that a document will be developed such >> > that >> > >> it >> > >> >> >> > "will describe *the(?) single* service-level data plane >> > >> >> >> > encapsulation format for conveying the service function >> > chain >> > >> and >> > >> >> >> > the service function path associated with data packets, >>and >> > >> for >> > >> >> >> > carrying context information between nodes that implement >> > >> service >> > >> >> >> > functions". >> > >> >> >> >> > >> >> >> > How to do you reconcile those two statements? >> > >> >> >> >> > >> >> >> Note: this inconsistency existed in the earlier charter, I >> > didn't >> > >> >> >> introduce it. :-) >> > >> >> >> >> > >> >> >> I think for the service plane data encapsulation, we should >> > aim >> > >> for >> > >> >> >> one. I'm understand the concern about writing that into the >> > >> charter >> > >> >> in >> > >> >> >> absolute terms, as I think the WG should have room to discuss >> > and >> > >> it >> > >> >> >> may be too early to be definitive. But unless there is >> > compelling >> > >> >> >> reason, we should have one encap. (BTW, nothing new here.. >> > this >> > >> is >> > >> >> >> normal IETF.) >> > >> >> >> >> > >> >> >> That said, I don't see the need for more than one encap. Does >> > >> anyone >> > >> >> >> think we do? And if so, why? >> > >> >> >> >> > >> >> >> > In my opinion, we should open the door for more than one >> > >> solution >> > >> >> to >> > >> >> >> > service chaining. >> > >> >> >> >> > >> >> >> Ah, "solution to service chaining" (to me) is more than the >> > >> encap, >> > >> >> >> including the control plane and related stuff. So even if we >> > >> develop >> > >> >> >> one encap, that doesn't necessarily mean there is only one >> > >> >> >> "solution". So the inconsistency may not be quite as strong >>as >> > >> first >> > >> >> >> seems. >> > >> >> >> >> > >> >> >> Suggestion. change: >> > >> >> >> >> > >> >> >> A document will describe the single service-level data plane >> > >> >> >> encapsulation format ... >> > >> >> >> >> > >> >> >> To: >> > >> >> >> >> > >> >> >> A document will describe a service-level data plane >> > >> encapsulation >> > >> >> >> format ... >> > >> >> >> >> > >> >> >> this is a bit weaker, but still does (implicitely) suggest >>one >> > >> >> encap. >> > >> >> >> >> > >> >> >> or, if folk think this is not good enough, we could add text >> > >> saying >> > >> >> we >> > >> >> >> are aiming for one, and will only do more if ... >> > >> >> >> >> > >> >> >> But personally, I think it would be fine to have the charter >> > say >> > >> one >> > >> >> >> encap, and if the WG concludes that one encap isn't what is >> > >> needed, >> > >> >> >> then recharter. We shouldn't look at rechartering as >> > >> "impossible". >> > >> >> We >> > >> >> >> just need to be able to make the case that more than one >>encap >> > is >> > >> >> >> necessary. If we can do that, I wouldn't think rechartering >> > would >> > >> be >> > >> >> a >> > >> >> >> big deal. >> > >> >> >> >> > >> >> >> 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 kgray@juniper.net Thu Sep 26 16:57: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 CC91921E8094 for ; Thu, 26 Sep 2013 16:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.724 X-Spam-Level: X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 6+Ih1HtxrsMT for ; Thu, 26 Sep 2013 16:57:24 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1D57221E80D4 for ; Thu, 26 Sep 2013 16:57:18 -0700 (PDT) Received: from mail163-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Thu, 26 Sep 2013 23:57:17 +0000 Received: from mail163-va3 (localhost [127.0.0.1]) by mail163-va3-R.bigfish.com (Postfix) with ESMTP id B29D38010F; Thu, 26 Sep 2013 23:57:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371I542I1dbaI1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail163-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(377454003)(24454002)(164054003)(51704005)(13464003)(199002)(189002)(76104003)(47736001)(80976001)(19580405001)(76482001)(81686001)(81816001)(69226001)(83322001)(19580395003)(47976001)(83506001)(51856001)(46102001)(4396001)(31966008)(47446002)(74662001)(49866001)(15975445006)(50986001)(74502001)(74706001)(74876001)(63696002)(561944002)(81542001)(54356001)(74366001)(76176001)(79102001)(83072001)(56816003)(81342001)(77096001)(80022001)(53806001)(65816001)(36756003)(77982001)(76796001)(54316002)(56776001)(76786001)(59766001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB082; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail163-va3 (localhost.localdomain [127.0.0.1]) by mail163-va3 (MessageSwitch) id 1380239835490522_14640; Thu, 26 Sep 2013 23:57:15 +0000 (UTC) Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.233]) by mail163-va3.bigfish.com (Postfix) with ESMTP id 71F8A3A0041; Thu, 26 Sep 2013 23:57:15 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 26 Sep 2013 23:57:15 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.359.1; Thu, 26 Sep 2013 23:57:14 +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.775.9; Thu, 26 Sep 2013 23:57:13 +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.0775.005; Thu, 26 Sep 2013 23:57:13 +0000 From: Ken Gray To: "NAPIERALA, MARIA H" , "adrian@olddog.co.uk" , "'Jim Guichard (jguichar)'" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnW9XQAgAAOJQCAAAZxgIAABuUAgAES7ICAAAQYAIAAARcAgAAEy4CAAADIgIAADB6AgABsDgCAAAYkAIAABJiAgAALSwD//8dCgA== Date: Thu, 26 Sep 2013 23:57:13 +0000 Message-ID: In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012A3EB3@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: 0981815F2F 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: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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: Thu, 26 Sep 2013 23:57:29 -0000 Hate to be a wet blanket, but since we're niggling over the word "and", the proposed text could be interpreted as any one of "service function chain ID, service function path, or for communicating context" but not more than one at the same time. Replacing "and" with "or" didn't make it any clearer for me. On 9/26/13 7:20 PM, "NAPIERALA, MARIA H" wrote: >> It is unequivocally in the charter. > >> The text that bothers you is: >> A document will describe the single service-level data plane >> encapsulation format for conveying the service function chain >> and the service function path, and for communicating context >> information between nodes that implement service functions. >>=20 >> The use of "and" does not always mean that you MUST do both things. It > >Not always, but it might. And in the text above this distinction is not >clear. > >> means you >> can do both. > >>=20 >> Silly example: >> The English language allows an English speaker to order food at >> lunchtime and to >> make proposals of marriage. >> This does not require me to propose to the waiter each time I ask for a >> burrito. > >So let's change the text as follows (to avoid explaining what "and" >means): > >"A document will describe the single service-level data plane >encapsulation format for conveying information such as >service function chain ID, service function path, or for communicating >context >information between nodes that implement service functions." > > >> In the text in the draft charter it says: >> We will make one encapsulation protocol. >> You can use this protocol to carry the service function chain. >> You can also use this protocol to carry the service function path. >> You can also use this protocol to carry metadata. >>=20 >> OK? >>=20 >> Adrian >>=20 >> > -----Original Message----- >> > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] >> > Sent: 26 September 2013 23:23 >> > To: adrian@olddog.co.uk; 'Jim Guichard (jguichar)' >> > Cc: nsc@ietf.org >> > Subject: RE: [nsc] New NSC WG Charter >> > >> > I thought I said it already: the ability to carry the metadata >> without >> requiring to >> > also carry service chain information (quote from the charter's write >> up: >> > "conveying the service function chain and the service function path") >> in the >> data >> > packet. >> > If you think this is already in the charter or it is outside of the >> charter, I >> would like >> > to know. I cannot infer it from the write-up. >> > >> > Maria >> > >> > > -----Original Message----- >> > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> > > Sent: Thursday, September 26, 2013 6:01 PM >> > > To: NAPIERALA, MARIA H; 'Jim Guichard (jguichar)' >> > > Cc: nsc@ietf.org >> > > Subject: RE: [nsc] New NSC WG Charter >> > > >> > > I have to pile in here :-( >> > > >> > > Maria, I think you want to say "Don't require me to use a service- >> level >> > > encapsulation to achieve this function". >> > > I don't believe you want to say "Allow me to have more than one >> > > service-level >> > > encapsulation to achieve this function." >> > > >> > > The text does not in any way preclude having other mechanisms for >> doing >> > > stuff. >> > > In particular, configuring service chains at service nodes is an >> > > obvious >> > > approach. Similarly the service chain information might be >> distributed >> > > (ahead of >> > > time) by some other protocol. >> > > >> > > The text does say that there will be at most one service-level >> > > encapsulation. >> > > Because setting out to have more than one new encapsulation >> protocol to >> > > do the >> > > same thing. >> > > >> > > Text also says that there will be a service-level encapsulation. >> > > Why does it do that? >> > > Because, if this WG goes off and decides to tweak every protocol >> that >> > > is out >> > > there to make a special way to carry service chain information in >> that >> > > protocol, >> > > it will be a disaster (IMNSHO). >> > > >> > > If this doesn't address your concern, Maria, perhaps rather than >> try to >> > > change >> > > the text or comment on what you think the text implies, you could >> say >> > > what it is >> > > you want to be able to do. That way we can say whether it is in or >> out >> > > of scope >> > > of the current text. >> > > >> > > Thanks, >> > > Adrian >> > > >> > > >> > > > -----Original Message----- >> > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> Behalf Of >> > > > NAPIERALA, MARIA H >> > > > Sent: 26 September 2013 16:35 >> > > > To: Jim Guichard (jguichar) >> > > > Cc: nsc@ietf.org >> > > > Subject: Re: [nsc] New NSC WG Charter >> > > > >> > > > I understand. >> > > > Why such document is specifically singled out in the charter? >> Let's >> > > leave it >> > > to the >> > > > solutions. >> > > > >> > > > Maria >> > > > >> > > > > -----Original Message----- >> > > > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> > > > > Sent: Thursday, September 26, 2013 10:51 AM >> > > > > To: NAPIERALA, MARIA H >> > > > > Cc: nsc@ietf.org >> > > > > Subject: Re: [nsc] New NSC WG Charter >> > > > > >> > > > > That is talking about context information - notice all the >> *and's* >> > > in >> > > > > the >> > > > > sentence ;-) >> > > > > >> > > > > On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" >> wrote: >> > > > > >> > > > > >This paragraph is good. >> > > > > > >> > > > > >I was pointing out that the item 3 (under "Specifically, the >> SFC >> > > WG is >> > > > > >chartered to deliver the following" heading) is implying a >> > > specific >> > > > > >solution (which is fine but it should not be the only one...): >> > > > > > >> > > > > >"3) Generic Service Function Chaining Encapsulation: A >> document >> > > will >> > > > > >describe the single service-level data plane encapsulation >> format >> > > for >> > > > > >conveying the service function chain and the service function >> > > path, >> > > > > and >> > > > > >for communicating context information between nodes that >> implement >> > > > > >service functions..." >> > > > > > >> > > > > > >> > > > > >Maria >> > > > > > >> > > > > >> -----Original Message----- >> > > > > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> > > > > >> Sent: Thursday, September 26, 2013 10:31 AM >> > > > > >> To: NAPIERALA, MARIA H >> > > > > >> Cc: nsc@ietf.org >> > > > > >> Subject: Re: [nsc] New NSC WG Charter >> > > > > >> >> > > > > >> Yes and I believe the following text from the charter covers >> > > that -> >> > > > > >> "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." >> > > > > >> >> > > > > >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" >> > > wrote: >> > > > > >> >> > > > > >> >Jim, >> > > > > >> > >> > > > > >> >I said the opposite, i.e., how to carry metadata should be >> part >> > > of >> > > > > the >> > > > > >> >charter but how to carry the metadata should not >> necessarily >> > > > > dictate >> > > > > >> how >> > > > > >> >the service chain path itself is realized. >> > > > > >> > >> > > > > >> >Maria >> > > > > >> > >> > > > > >> >> -----Original Message----- >> > > > > >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> > > > > >> >> Sent: Thursday, September 26, 2013 10:13 AM >> > > > > >> >> To: NAPIERALA, MARIA H; Thomas Narten >> > > > > >> >> Cc: nsc@ietf.org >> > > > > >> >> Subject: Re: [nsc] New NSC WG Charter >> > > > > >> >> >> > > > > >> >> Hi Maria, >> > > > > >> >> >> > > > > >> >> Hope you are well. I do not believe the new charter text >> > > prevents >> > > > > >> the >> > > > > >> >> realization of a service chain *without* metadata/context >> > > > > >> information. >> > > > > >> >> >> > > > > >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" >> > > wrote: >> > > > > >> >> >> > > > > >> >> >I believe the NSC architecture should not preclude the >> > > service >> > > > > >> chain >> > > > > >> >> >path/topology from being realized with some existing >> (and >> > > > > standard >> > > > > >> ;-) >> > > > > >> >> >network overlay (=3Dvirtual network) technique. But if th= e >> > > > > decision >> > > > > >> is >> > > > > >> >> made >> > > > > >> >> >that it does then this should be clearly stated in the >> > > charter. >> > > > > >> >> >What must be common to the service chain path solutions >> is, >> > > IMO, >> > > > > >> the >> > > > > >> >> >method for carrying the metadata/context information. >> > > > > >> >> > >> > > > > >> >> >Maria >> > > > > >> >> > >> > > > > >> >> >> -----Original Message----- >> > > > > >> >> >> From: Thomas Narten [mailto:narten@us.ibm.com] >> > > > > >> >> >> Sent: Wednesday, September 25, 2013 5:24 PM >> > > > > >> >> >> To: NAPIERALA, MARIA H >> > > > > >> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org >> > > > > >> >> >> Subject: Re: [nsc] New NSC WG Charter >> > > > > >> >> >> >> > > > > >> >> >> "NAPIERALA, MARIA H" writes: >> > > > > >> >> >> >> > > > > >> >> >> > The group charter's write-up says that: "The Service >> > > > > Function >> > > > > >> >> >> > Chaining (SFC) working group will develop new >> approaches >> > > to >> > > > > >> >> service >> > > > > >> >> >> > delivery ..." (i.e., not one "approach" but >> > > "approaches", >> > > > > which >> > > > > >> >> >> > means more than one). >> > > > > >> >> >> >> > > > > >> >> >> > But then is states that a document will be developed >> > > such >> > > > > that >> > > > > >> it >> > > > > >> >> >> > "will describe *the(?) single* service-level data >> plane >> > > > > >> >> >> > encapsulation format for conveying the service >> function >> > > > > chain >> > > > > >> and >> > > > > >> >> >> > the service function path associated with data >> packets, >> > > and >> > > > > >> for >> > > > > >> >> >> > carrying context information between nodes that >> > > implement >> > > > > >> service >> > > > > >> >> >> > functions". >> > > > > >> >> >> >> > > > > >> >> >> > How to do you reconcile those two statements? >> > > > > >> >> >> >> > > > > >> >> >> Note: this inconsistency existed in the earlier >> charter, I >> > > > > didn't >> > > > > >> >> >> introduce it. :-) >> > > > > >> >> >> >> > > > > >> >> >> I think for the service plane data encapsulation, we >> > > should >> > > > > aim >> > > > > >> for >> > > > > >> >> >> one. I'm understand the concern about writing that >> into >> > > the >> > > > > >> charter >> > > > > >> >> in >> > > > > >> >> >> absolute terms, as I think the WG should have room to >> > > discuss >> > > > > and >> > > > > >> it >> > > > > >> >> >> may be too early to be definitive. But unless there is >> > > > > compelling >> > > > > >> >> >> reason, we should have one encap. (BTW, nothing new >> here.. >> > > > > this >> > > > > >> is >> > > > > >> >> >> normal IETF.) >> > > > > >> >> >> >> > > > > >> >> >> That said, I don't see the need for more than one >> encap. >> > > Does >> > > > > >> anyone >> > > > > >> >> >> think we do? And if so, why? >> > > > > >> >> >> >> > > > > >> >> >> > In my opinion, we should open the door for more than >> one >> > > > > >> solution >> > > > > >> >> to >> > > > > >> >> >> > service chaining. >> > > > > >> >> >> >> > > > > >> >> >> Ah, "solution to service chaining" (to me) is more >> than >> > > the >> > > > > >> encap, >> > > > > >> >> >> including the control plane and related stuff. So even >> if >> > > we >> > > > > >> develop >> > > > > >> >> >> one encap, that doesn't necessarily mean there is only >> one >> > > > > >> >> >> "solution". So the inconsistency may not be quite as >> > > strong as >> > > > > >> first >> > > > > >> >> >> seems. >> > > > > >> >> >> >> > > > > >> >> >> Suggestion. change: >> > > > > >> >> >> >> > > > > >> >> >> A document will describe the single service-level >> data >> > > plane >> > > > > >> >> >> encapsulation format ... >> > > > > >> >> >> >> > > > > >> >> >> To: >> > > > > >> >> >> >> > > > > >> >> >> A document will describe a service-level data plane >> > > > > >> encapsulation >> > > > > >> >> >> format ... >> > > > > >> >> >> >> > > > > >> >> >> this is a bit weaker, but still does (implicitely) >> suggest >> > > one >> > > > > >> >> encap. >> > > > > >> >> >> >> > > > > >> >> >> or, if folk think this is not good enough, we could >> add >> > > text >> > > > > >> saying >> > > > > >> >> we >> > > > > >> >> >> are aiming for one, and will only do more if ... >> > > > > >> >> >> >> > > > > >> >> >> But personally, I think it would be fine to have the >> > > charter >> > > > > say >> > > > > >> one >> > > > > >> >> >> encap, and if the WG concludes that one encap isn't >> what >> > > is >> > > > > >> needed, >> > > > > >> >> >> then recharter. We shouldn't look at rechartering as >> > > > > >> "impossible". >> > > > > >> >> We >> > > > > >> >> >> just need to be able to make the case that more than >> one >> > > encap >> > > > > is >> > > > > >> >> >> necessary. If we can do that, I wouldn't think >> > > rechartering >> > > > > would >> > > > > >> be >> > > > > >> >> a >> > > > > >> >> >> big deal. >> > > > > >> >> >> >> > > > > >> >> >> 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 Chuong.D.Pham@team.telstra.com Thu Sep 26 17:08: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 826D421E80C5 for ; Thu, 26 Sep 2013 17:08:01 -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 2eE8MpX4uOIt for ; Thu, 26 Sep 2013 17:07:56 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE2121E80D8 for ; Thu, 26 Sep 2013 17:07:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,989,1371045600"; d="scan'208";a="150436055" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 27 Sep 2013 10:07:39 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7210"; a="170235822" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipccni.tcif.telstra.com.au with ESMTP; 27 Sep 2013 10:07:39 +1000 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Fri, 27 Sep 2013 10:07:38 +1000 From: "Pham, Chuong D" To: Linda Dunbar , "Carlos Pignataro (cpignata)" , "Joel M. Halpern" Date: Fri, 27 Sep 2013 10:06:45 +1000 Thread-Topic: [nsc] New NSC WG Charter - charter bullet #3 Thread-Index: Ac67By0pCiL+q0lFQk+xCqbRCZgcvwACuUlQ Message-ID: <5602569641FB314FB4D9AD5659D41B9C255666C77D@WSMSG3154V.srv.dir.telstra.com> References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCE0DA@dfweml509-mbx.china.huawei.com> <049e01ceb955$43cf4960$cb6ddc20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645BCED03@dfweml509-mbx.china.huawei.com> <52428F89.4040006@joelhalpern.com> <95067C434CE250468B77282634C96ED325FA2181@xmb-aln-x02.cisco.com> <5602569641FB314FB4D9AD5659D41B9C25565D27CB@WSMSG3154V.srv.dir.telstra.com> <4A95BA014132FF49AE685FAB4B9F17F645BCFDB4@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BCFDB4@dfweml509-mbx.china.huawei.com> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 00:08:01 -0000 Hi Linda, Please see my responses inline below. Regards, Chuong -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20 Sent: Friday, 27 September 2013 8:04 AM To: Pham, Chuong D; Carlos Pignataro (cpignata); Joel M. Halpern Cc: nsc@ietf.org; adrian@olddog.co.uk Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 Chuong,=20 Thanks for the examples.=20 Some questions are inserted below:=20 > -----Original Message----- >=20 > Another example is in the case of Header Enrichment (HE) service in a=20 > Mobile network. A HE function inserts information elements into HTTP=20 > header. What to insert is dependent on the identification of the users=20 > i.e. the MSISDN. Today, IP packets arriving at the HE function do not=20 > contain such non-IP-address user identification. [Linda] "The Header Enrichment service" insert bits to existing HTTP header= of the packets, correct? I've seen other network function modules (or even= BNG) add/change bits to HTTP header to carry information to downstream nod= es. I hope that this kind of encoding bits/fields to existing header should= be acknowledged as a way to carry "Metadata" by the NSC charter.=20 [Chuong] Header Enrichment service (HE) is considered a value-added-service= (VAS) in our Mobile network and I believe this is also the case for many o= ther Mobile Operators. Traffic is steered to HE (using some non-SDN, non-NS= C methods today - We hope NSC will help us with this). The HE only sees the= source/destination IP addresses (plus other TCP/HTTP layer information lik= e port numbers etc). From the IP packet alone, the HE cannot identify a Mob= ile users. Now, why does the HE need to identify the Mobile users? one exam= ple of the kind of VAS a HE offers is inserting a MSISDN (aka the Mobile ph= one number) into the HTTP header so that the traffic is recognised at the s= erver end (i.e. a Web site owner, owned by us, or our partners) as belongin= g to one of our Mobile subscribers. With this knowledge, the server end can= apply certain actions such as authorising the customers to access certain = services via the Web site (without requiring the users to go through User-N= ame/Password based authentication which is a turn-off of Mobile users with = small screens and handsets. One example of the services is a Usage Meter wh= ich reports on the user's data usage to date. How can the HE know which use= r (and the MSISDN) the IP packets/flows belong to so that the HE can insert= the correct MSISDN? Today, we relying on sending Radius Accounting (RA) me= ssages to the HE. RA has attributes which include the IP address dynamicall= y assigned to a user and the MSISDN belong to this user. Today the HE has t= o receive Radius Accounting and maintain this database at all time. If the = HE receives the MSISDN in the metadata inserted by the first classification= node in NSC, then it does not have to maintain that database. Moreover, do= wnstream to HE, we may want to apply a Parental Control server aka a Conten= t Filtering (CF) service, where the CF also needs to know the MSISDN owning= the IP packets. This is because different users require/subscribe-to diffe= rent CF policies. Today in our network, again, we duplicate what we have fo= r HE and send Radius Accounting to CF and make the CF to maintain the data = base as well. Hopefully, we now can see that if metadata contains the MSISD= N, then the HE and CF do not have to maintain their own databases to correl= ate IP packets with users. HE and CF are what we currently have. I could ex= tend this example to future services such as Personal-Firewall, Malware-Det= ection, Video-Optimisation etc., where different user requires different po= licies, hence the need to identify users of IP packets. =20 > If the "cost" of carrying this user identification in metadata is=20 > justified, I see great opportunity, especially for Mobile operators=20 > (and Fixed in the case of Fixed Mobile Convergence (FMC)). [Linda] The "HE" example you give earlier doesn't require new Metadata head= er. Do you have any examples to show adding/encoding bits to existing heade= r (HTTP, TCP, or IP header) is not enough? [Chuong] See above. If it's still not clear, I will be happy to discuss fur= ther.=20 >=20 > Regards, > Chuong >=20 >=20 >=20 > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: Wednesday, 25 September 2013 10:07 PM > To: Joel M. Halpern > Cc: nsc@ietf.org; adrian@olddog.co.uk; Linda Dunbar > Subject: Re: [nsc] New NSC WG Charter - charter bullet #3 >=20 > This, access/subscriber identification, is a good example. >=20 > Another typical example is to use metadata to share the result of=20 > ingress classification, or network information (as e.g., to be used in=20 > subscriber identification) to then be used for policy in a service=20 > function downstream the service path. One such example is VRF=20 > information. >=20 > Thanks, >=20 > -- Carlos. >=20 > On Sep 25, 2013, at 3:23 AM, Joel M. Halpern > wrote: >=20 > > For me, the canonical example of metadata applies to the use case of > a service chain providing residential gateway functionality with=20 > 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=20 > 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=20 > 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=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=20 > >> injection, 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=20 > the ID. > >> > >> > >>> > >>> The charter says: > >>> > >>> | The Service Function Chaining (SFC) working group will develop > new > >>> | 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=20 > >>> | developed to describe requirements and protocols necessary to=20 > >>> | convey information to service function implementation points.=20 > >>> | 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 mn1921@att.com Thu Sep 26 17:41: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 B1E0C11E8118 for ; Thu, 26 Sep 2013 17:41:53 -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 rvs6B+lmBW3B for ; Thu, 26 Sep 2013 17:41:47 -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 77D3611E810F for ; Thu, 26 Sep 2013 17:41:47 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b44d4425.7e83c940.2434639.00-505.6565100.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 27 Sep 2013 00:41:47 +0000 (UTC) X-MXL-Hash: 5244d44b474d506e-bdf203a2f184c3605757bf2a4192c541bc50f886 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 a44d4425.0.2434637.00-371.6565084.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 27 Sep 2013 00:41:46 +0000 (UTC) X-MXL-Hash: 5244d44a440bc551-903187eb7906af40f99e39995426779b73eb26e3 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 r8R0fkhc019515; Thu, 26 Sep 2013 20:41:46 -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 r8R0fYOP019474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Sep 2013 20:41:39 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 27 Sep 2013 00:41:24 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; Thu, 26 Sep 2013 20:41:23 -0400 From: "NAPIERALA, MARIA H" To: Ken Gray , "adrian@olddog.co.uk" , "'Jim Guichard (jguichar)'" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXOIIA///I2MCAAEu+gP//wPdwgAFY24D//7+64AAIrpkAAAf8x8D//8WsgIAAN1RAgABA2QCAAD13kP//zUSAgAA6GgD//9uJgIAAN++Q Date: Fri, 27 Sep 2013 00:41:23 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012A3FAE@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <1D70D757A2C9D54D83B4CBD7625FA80E012A3EB3@MISOUT7MSGUSR9I.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.171.5] 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=Rv1y2laK c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=14cQzkQizn0A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=FFZ-zzI3G] X-AnalysisOut: [zMA:10 a=OUXY8nFuAAAA:8 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=AUd_NHdVAAAA:8 a=VnNF1IyMAAAA:8 a=FOWvlTFU4IY2eQUdfnoA:9] X-AnalysisOut: [ a=CjuIK1q_8ugA:10 a=peF9eE_zjQwA:10 a=jqlaW5bC1iAA:10 a=l] X-AnalysisOut: [ZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=JfD0Fch1gWkA:10 a=yDkvg] X-AnalysisOut: [UpxeLUUU3qj:21 a=1iTYS9jdILQKORrb:21] Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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, 27 Sep 2013 00:41:53 -0000 It does make a difference if you think in terms of mathematical logic. Otherwise, replace "or" with a grammatical "and/or." Maria > -----Original Message----- > From: Ken Gray [mailto:kgray@juniper.net] > Sent: Thursday, September 26, 2013 7:57 PM > To: NAPIERALA, MARIA H; adrian@olddog.co.uk; 'Jim Guichard (jguichar)' > Cc: nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter >=20 > Hate to be a wet blanket, but since we're niggling over the word "and", > the proposed text could be interpreted as any one of "service function > chain ID, service function path, or for communicating context" but not > more than one at the same time. Replacing "and" with "or" didn't make > it > any clearer for me. >=20 > On 9/26/13 7:20 PM, "NAPIERALA, MARIA H" wrote: >=20 > >> It is unequivocally in the charter. > > > >> The text that bothers you is: > >> A document will describe the single service-level data plane > >> encapsulation format for conveying the service function chain > >> and the service function path, and for communicating context > >> information between nodes that implement service functions. > >> > >> The use of "and" does not always mean that you MUST do both things. > It > > > >Not always, but it might. And in the text above this distinction is > not > >clear. > > > >> means you > >> can do both. > > > >> > >> Silly example: > >> The English language allows an English speaker to order food at > >> lunchtime and to > >> make proposals of marriage. > >> This does not require me to propose to the waiter each time I ask > for a > >> burrito. > > > >So let's change the text as follows (to avoid explaining what "and" > >means): > > > >"A document will describe the single service-level data plane > >encapsulation format for conveying information such as > >service function chain ID, service function path, or for communicating > >context > >information between nodes that implement service functions." > > > > > >> In the text in the draft charter it says: > >> We will make one encapsulation protocol. > >> You can use this protocol to carry the service function chain. > >> You can also use this protocol to carry the service function path. > >> You can also use this protocol to carry metadata. > >> > >> OK? > >> > >> Adrian > >> > >> > -----Original Message----- > >> > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > >> > Sent: 26 September 2013 23:23 > >> > To: adrian@olddog.co.uk; 'Jim Guichard (jguichar)' > >> > Cc: nsc@ietf.org > >> > Subject: RE: [nsc] New NSC WG Charter > >> > > >> > I thought I said it already: the ability to carry the metadata > >> without > >> requiring to > >> > also carry service chain information (quote from the charter's > write > >> up: > >> > "conveying the service function chain and the service function > path") > >> in the > >> data > >> > packet. > >> > If you think this is already in the charter or it is outside of > the > >> charter, I > >> would like > >> > to know. I cannot infer it from the write-up. > >> > > >> > Maria > >> > > >> > > -----Original Message----- > >> > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> > > Sent: Thursday, September 26, 2013 6:01 PM > >> > > To: NAPIERALA, MARIA H; 'Jim Guichard (jguichar)' > >> > > Cc: nsc@ietf.org > >> > > Subject: RE: [nsc] New NSC WG Charter > >> > > > >> > > I have to pile in here :-( > >> > > > >> > > Maria, I think you want to say "Don't require me to use a > service- > >> level > >> > > encapsulation to achieve this function". > >> > > I don't believe you want to say "Allow me to have more than one > >> > > service-level > >> > > encapsulation to achieve this function." > >> > > > >> > > The text does not in any way preclude having other mechanisms > for > >> doing > >> > > stuff. > >> > > In particular, configuring service chains at service nodes is an > >> > > obvious > >> > > approach. Similarly the service chain information might be > >> distributed > >> > > (ahead of > >> > > time) by some other protocol. > >> > > > >> > > The text does say that there will be at most one service-level > >> > > encapsulation. > >> > > Because setting out to have more than one new encapsulation > >> protocol to > >> > > do the > >> > > same thing. > >> > > > >> > > Text also says that there will be a service-level encapsulation. > >> > > Why does it do that? > >> > > Because, if this WG goes off and decides to tweak every protocol > >> that > >> > > is out > >> > > there to make a special way to carry service chain information > in > >> that > >> > > protocol, > >> > > it will be a disaster (IMNSHO). > >> > > > >> > > If this doesn't address your concern, Maria, perhaps rather than > >> try to > >> > > change > >> > > the text or comment on what you think the text implies, you > could > >> say > >> > > what it is > >> > > you want to be able to do. That way we can say whether it is in > or > >> out > >> > > of scope > >> > > of the current text. > >> > > > >> > > Thanks, > >> > > Adrian > >> > > > >> > > > >> > > > -----Original Message----- > >> > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >> Behalf Of > >> > > > NAPIERALA, MARIA H > >> > > > Sent: 26 September 2013 16:35 > >> > > > To: Jim Guichard (jguichar) > >> > > > Cc: nsc@ietf.org > >> > > > Subject: Re: [nsc] New NSC WG Charter > >> > > > > >> > > > I understand. > >> > > > Why such document is specifically singled out in the charter? > >> Let's > >> > > leave it > >> > > to the > >> > > > solutions. > >> > > > > >> > > > Maria > >> > > > > >> > > > > -----Original Message----- > >> > > > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> > > > > Sent: Thursday, September 26, 2013 10:51 AM > >> > > > > To: NAPIERALA, MARIA H > >> > > > > Cc: nsc@ietf.org > >> > > > > Subject: Re: [nsc] New NSC WG Charter > >> > > > > > >> > > > > That is talking about context information - notice all the > >> *and's* > >> > > in > >> > > > > the > >> > > > > sentence ;-) > >> > > > > > >> > > > > On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" > >> wrote: > >> > > > > > >> > > > > >This paragraph is good. > >> > > > > > > >> > > > > >I was pointing out that the item 3 (under "Specifically, > the > >> SFC > >> > > WG is > >> > > > > >chartered to deliver the following" heading) is implying a > >> > > specific > >> > > > > >solution (which is fine but it should not be the only > one...): > >> > > > > > > >> > > > > >"3) Generic Service Function Chaining Encapsulation: A > >> document > >> > > will > >> > > > > >describe the single service-level data plane encapsulation > >> format > >> > > for > >> > > > > >conveying the service function chain and the service > function > >> > > path, > >> > > > > and > >> > > > > >for communicating context information between nodes that > >> implement > >> > > > > >service functions..." > >> > > > > > > >> > > > > > > >> > > > > >Maria > >> > > > > > > >> > > > > >> -----Original Message----- > >> > > > > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> > > > > >> Sent: Thursday, September 26, 2013 10:31 AM > >> > > > > >> To: NAPIERALA, MARIA H > >> > > > > >> Cc: nsc@ietf.org > >> > > > > >> Subject: Re: [nsc] New NSC WG Charter > >> > > > > >> > >> > > > > >> Yes and I believe the following text from the charter > covers > >> > > that -> > >> > > > > >> "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." > >> > > > > >> > >> > > > > >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" > > >> > > wrote: > >> > > > > >> > >> > > > > >> >Jim, > >> > > > > >> > > >> > > > > >> >I said the opposite, i.e., how to carry metadata should > be > >> part > >> > > of > >> > > > > the > >> > > > > >> >charter but how to carry the metadata should not > >> necessarily > >> > > > > dictate > >> > > > > >> how > >> > > > > >> >the service chain path itself is realized. > >> > > > > >> > > >> > > > > >> >Maria > >> > > > > >> > > >> > > > > >> >> -----Original Message----- > >> > > > > >> >> From: Jim Guichard (jguichar) > [mailto:jguichar@cisco.com] > >> > > > > >> >> Sent: Thursday, September 26, 2013 10:13 AM > >> > > > > >> >> To: NAPIERALA, MARIA H; Thomas Narten > >> > > > > >> >> Cc: nsc@ietf.org > >> > > > > >> >> Subject: Re: [nsc] New NSC WG Charter > >> > > > > >> >> > >> > > > > >> >> Hi Maria, > >> > > > > >> >> > >> > > > > >> >> Hope you are well. I do not believe the new charter > text > >> > > prevents > >> > > > > >> the > >> > > > > >> >> realization of a service chain *without* > metadata/context > >> > > > > >> information. > >> > > > > >> >> > >> > > > > >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" > > >> > > wrote: > >> > > > > >> >> > >> > > > > >> >> >I believe the NSC architecture should not preclude > the > >> > > service > >> > > > > >> chain > >> > > > > >> >> >path/topology from being realized with some existing > >> (and > >> > > > > standard > >> > > > > >> ;-) > >> > > > > >> >> >network overlay (=3Dvirtual network) technique. But if > the > >> > > > > decision > >> > > > > >> is > >> > > > > >> >> made > >> > > > > >> >> >that it does then this should be clearly stated in > the > >> > > charter. > >> > > > > >> >> >What must be common to the service chain path > solutions > >> is, > >> > > IMO, > >> > > > > >> the > >> > > > > >> >> >method for carrying the metadata/context information. > >> > > > > >> >> > > >> > > > > >> >> >Maria > >> > > > > >> >> > > >> > > > > >> >> >> -----Original Message----- > >> > > > > >> >> >> From: Thomas Narten [mailto:narten@us.ibm.com] > >> > > > > >> >> >> Sent: Wednesday, September 25, 2013 5:24 PM > >> > > > > >> >> >> To: NAPIERALA, MARIA H > >> > > > > >> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org > >> > > > > >> >> >> Subject: Re: [nsc] New NSC WG Charter > >> > > > > >> >> >> > >> > > > > >> >> >> "NAPIERALA, MARIA H" writes: > >> > > > > >> >> >> > >> > > > > >> >> >> > The group charter's write-up says that: "The > Service > >> > > > > Function > >> > > > > >> >> >> > Chaining (SFC) working group will develop new > >> approaches > >> > > to > >> > > > > >> >> service > >> > > > > >> >> >> > delivery ..." (i.e., not one "approach" but > >> > > "approaches", > >> > > > > which > >> > > > > >> >> >> > means more than one). > >> > > > > >> >> >> > >> > > > > >> >> >> > But then is states that a document will be > developed > >> > > such > >> > > > > that > >> > > > > >> it > >> > > > > >> >> >> > "will describe *the(?) single* service-level > data > >> plane > >> > > > > >> >> >> > encapsulation format for conveying the service > >> function > >> > > > > chain > >> > > > > >> and > >> > > > > >> >> >> > the service function path associated with data > >> packets, > >> > > and > >> > > > > >> for > >> > > > > >> >> >> > carrying context information between nodes that > >> > > implement > >> > > > > >> service > >> > > > > >> >> >> > functions". > >> > > > > >> >> >> > >> > > > > >> >> >> > How to do you reconcile those two statements? > >> > > > > >> >> >> > >> > > > > >> >> >> Note: this inconsistency existed in the earlier > >> charter, I > >> > > > > didn't > >> > > > > >> >> >> introduce it. :-) > >> > > > > >> >> >> > >> > > > > >> >> >> I think for the service plane data encapsulation, > we > >> > > should > >> > > > > aim > >> > > > > >> for > >> > > > > >> >> >> one. I'm understand the concern about writing that > >> into > >> > > the > >> > > > > >> charter > >> > > > > >> >> in > >> > > > > >> >> >> absolute terms, as I think the WG should have room > to > >> > > discuss > >> > > > > and > >> > > > > >> it > >> > > > > >> >> >> may be too early to be definitive. But unless there > is > >> > > > > compelling > >> > > > > >> >> >> reason, we should have one encap. (BTW, nothing new > >> here.. > >> > > > > this > >> > > > > >> is > >> > > > > >> >> >> normal IETF.) > >> > > > > >> >> >> > >> > > > > >> >> >> That said, I don't see the need for more than one > >> encap. > >> > > Does > >> > > > > >> anyone > >> > > > > >> >> >> think we do? And if so, why? > >> > > > > >> >> >> > >> > > > > >> >> >> > In my opinion, we should open the door for more > than > >> one > >> > > > > >> solution > >> > > > > >> >> to > >> > > > > >> >> >> > service chaining. > >> > > > > >> >> >> > >> > > > > >> >> >> Ah, "solution to service chaining" (to me) is more > >> than > >> > > the > >> > > > > >> encap, > >> > > > > >> >> >> including the control plane and related stuff. So > even > >> if > >> > > we > >> > > > > >> develop > >> > > > > >> >> >> one encap, that doesn't necessarily mean there is > only > >> one > >> > > > > >> >> >> "solution". So the inconsistency may not be quite > as > >> > > strong as > >> > > > > >> first > >> > > > > >> >> >> seems. > >> > > > > >> >> >> > >> > > > > >> >> >> Suggestion. change: > >> > > > > >> >> >> > >> > > > > >> >> >> A document will describe the single service-level > >> data > >> > > plane > >> > > > > >> >> >> encapsulation format ... > >> > > > > >> >> >> > >> > > > > >> >> >> To: > >> > > > > >> >> >> > >> > > > > >> >> >> A document will describe a service-level data > plane > >> > > > > >> encapsulation > >> > > > > >> >> >> format ... > >> > > > > >> >> >> > >> > > > > >> >> >> this is a bit weaker, but still does (implicitely) > >> suggest > >> > > one > >> > > > > >> >> encap. > >> > > > > >> >> >> > >> > > > > >> >> >> or, if folk think this is not good enough, we could > >> add > >> > > text > >> > > > > >> saying > >> > > > > >> >> we > >> > > > > >> >> >> are aiming for one, and will only do more if ... > >> > > > > >> >> >> > >> > > > > >> >> >> But personally, I think it would be fine to have > the > >> > > charter > >> > > > > say > >> > > > > >> one > >> > > > > >> >> >> encap, and if the WG concludes that one encap isn't > >> what > >> > > is > >> > > > > >> needed, > >> > > > > >> >> >> then recharter. We shouldn't look at rechartering > as > >> > > > > >> "impossible". > >> > > > > >> >> We > >> > > > > >> >> >> just need to be able to make the case that more > than > >> one > >> > > encap > >> > > > > is > >> > > > > >> >> >> necessary. If we can do that, I wouldn't think > >> > > rechartering > >> > > > > would > >> > > > > >> be > >> > > > > >> >> a > >> > > > > >> >> >> big deal. > >> > > > > >> >> >> > >> > > > > >> >> >> 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 > > > > >=20 From ramk@Brocade.com Thu Sep 26 19:32: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 BF60E21F9CE3 for ; Thu, 26 Sep 2013 19:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO1Lsiwl1id7 for ; Thu, 26 Sep 2013 19:32:09 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id D3A5D21F9F2D for ; Thu, 26 Sep 2013 19:32:09 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r8R2U4pv002070; Thu, 26 Sep 2013 19:32:06 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1f49rjgr98-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Sep 2013 19:32:06 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 26 Sep 2013 19:32:05 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 26 Sep 2013 19:32:05 -0700 From: ramki Krishnan To: Anoop Ghanwani , "Paul Quinn (paulq)" Date: Thu, 26 Sep 2013 19:31:58 -0700 Thread-Topic: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3] Thread-Index: Ac664G26gX3KiGUHRUyTJNINeFHvrwARJtbg Message-ID: References: <7E05C330D7FD6D4FAD0728C46B8995856FDF3C82@ORSMSX105.amr.corp.intel.com> <8E86B6E7C6FB9F40A00B0E269045A7C9211489D9@xmb-aln-x09.cisco.com> <7E05C330D7FD6D4FAD0728C46B8995856FDFFFED@ORSMSX105.amr.corp.intel.com> <05271FBC-BBE7-4261-BC16-AAEA55CA3C0B@cisco.com> <007401ceb795$4e1d5b80$ea581280$@olddog.co.uk> <201309251435.r8PEZ6qo007011@cichlid.raleigh.ibm.com> <064001ceba06$27012680$75037380$@olddog.co.uk> <201309251724.r8PHO9hk031606@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BFFF996356HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-26_12:2013-09-27, 2013-09-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309260180 Cc: "nsc@ietf.org" Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 02:32:16 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BFFF996356HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, I think the following topics should be addressed in the problem statement t= o add more clarity. 1) Interaction between state migration, for example VM migration, and = service function chaining. 2) Fast path offload and service function chaining interaction; for ex= ample, a load balancer/security appliance may send a request to offload a l= ong-lived large flow to the switch/router. If you like, I can send more text on these topics. Thanks, Ramki From: ghanwani@gmail.com [mailto:ghanwani@gmail.com] On Behalf Of Anoop Gha= nwani Sent: Thursday, September 26, 2013 10:47 AM To: Paul Quinn (paulq) Cc: ramki Krishnan; nsc@ietf.org Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3] Hi Paul, The two big issues are the ones that I already alluded to. First, it would be good to have more clarity around transparent vs non-tran= sparent appliances (otherwise you have folks like Thomas who think it only = applies to transparent appliances, and folks like me who wonder how non-tra= nsparent appliances are supposed to work with this). The second issue is around multiple layers of overlays. There is reference= to metadata, yet it is not clear if metadata must appear multiple times in= the frame if the service is applied at L2 vs L3 vs L4. I can't see how the document can deal with this without getting into some s= pecific examples. A relatively minor thing would be better clarify around overlays. Normally= when I think of overlays, I think tunnels, not regular layering. But it s= eems like Adrian, for example, has a differing view. The document should c= larify what it really means by network overlay by giving some examples. The way the document is currently written captures the problem well, but at= a very high-level. It is easy to get a gist of what's going on, but it le= aves a lot of room for interpretation as to the scope of the problem being = tackled. Anoop On Thu, Sep 26, 2013 at 8:10 AM, Paul Quinn (paulq) > wrote: Hi Anoop, Ramki, Great to see that you both have read the problem statement! Let's make thi= s constructive: we'd love to see your detailed comments. Please send them = to the list, and/or the draft authors and we'll review them. Paul On Sep 25, 2013, at 6:59 PM, ramki Krishnan > wrote: >>It may be that as Thomas says, we are not going to worry about non-transp= arent appliances at all, but then I'm not sure how we even implement someth= ing like a load balancer. >> Finally, I do think the problem statement needs a lot of work before we = get to solutions. I think it would be useful to state somewhere in the cha= rter that solutions would only be considered after the problem statement is= in a reasonable shape and the WG participants are in agreement about what = needs to be solved. Agree with Anoop. We do need to clarify this aspect in the problem statemen= t. Thanks, Ramki From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Anoop Ghanwan= i Sent: Wednesday, September 25, 2013 11:11 AM To: Ron Parker Cc: Thomas Narten; >; Paul = Quinn (paulq); > Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3] When I mentioned transparent/non-transparent, I meant that there was some c= hange in the packet headers (whether at the IP, MAC, or TCP layers) for pac= kets that were going to be subject to the service in question, in the non-t= ransparent case. In other words, for the transparent case, I cannot tell b= y looking at the packet headers whether or not the packet would be subject = to that service. Clearly, there are others who think transparent/non-trans= parent mean something else. And that's just simply because there is not st= andard terminology, which perhaps the WG can help define. I think this also plays into where in the packet the NSC header goes, and w= hether there can be multiple instances of the NSC header in the packet. If a certain layer's header is terminated at a service box, it would be a l= ayering violation to carry the NSC header beyond that point. For instance, if the NSC header is located between the MAC and IP header, a= nd the packet hits a load balancer that changes the IP & MAC headers, that = device would need to create a new NSC header. It may be that as Thomas says, we are not going to worry about non-transpar= ent appliances at all, but then I'm not sure how we even implement somethin= g like a load balancer. Finally, I do think the problem statement needs a lot of work before we get= to solutions. I think it would be useful to state somewhere in the charte= r that solutions would only be considered after the problem statement is in= a reasonable shape and the WG participants are in agreement about what nee= ds to be solved. Anoop On Wed, Sep 25, 2013 at 10:28 AM, Ron Parker > wrote: Thomas, I agree that the notion of transparent service is not necessary to incorpor= ate in our work. Ron -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, September 25, 2013 1:24 PM To: Ron Parker Cc: Paul Quinn (paulq); >; = Anoop Ghanwani; > Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3] Ron, > So is the definition of transparent -- packets are unchanged (headers, > content, etc.) and routing/switching path is unaltered? > Or is it just the former? The mere diversion to a service node would > seem to constitute "routing/switching is altered". I think the point is we don't exactly have an agreed to defintion of "trans= parent" in the NSC context, so it's not particularly helpful to use it in d= escribing NSC behavior without being clear about what is meant. For services in NSC, packets clearly will get modified in some cases (e.g. = NAT or proxies) but won't in others. So distinguishing types of services by= how much they change the packets they inspect is probably not helpful for = NSC. NSC doesn't really care *what* the services does, just that the servic= e exists and packets need to be steered to travel through the service. Thomas --_000_C7634EB63EFD984A978DFB46EA5174F2BFFF996356HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

I think the following topics should be addressed in the prob= lem statement to add more clarity.

 

1)      Interaction between state migration, for example VM migration, and service function chaining.

2)      Fast path offload and service function chaining interaction; for example, a load balancer/security appliance may send a request to offload a long-lived larg= e flow to the switch/router.

 <= /span>

If you like, I can send more text on these topics.

 

Thanks,

Ramki

 

From: ghanwani@gmai= l.com [mailto:ghanwani@gmail.com] On Behalf Of Anoop Ghanwani
Sent: Thursday, September 26, 2013 10:47 AM
To: Paul Quinn (paulq)
Cc: ramki Krishnan; nsc@ietf.org
Subject: Re: [nsc] transparent vs. non-transparent services [was Re:= New NSC WG Charter - charter bullet #3]

 

Hi Paul,

 

The two big issues are the ones that I already alluded= to.  

 

First, it would be good to have more clarity around transparent vs non-transparent appliances (otherwise you have folks like Th= omas who think it only applies to transparent appliances, and folks like me who wonder how non-transparent appliances are supposed to work with this).=

 

The second issue is around multiple layers of overlays= .  There is reference to metadata, yet it is not clear if metadata must appear multiple times in the frame if the service is applied at L2 vs L3 vs= L4.

 

I can't see how the document can deal with this withou= t getting into some specific examples.

 

A relatively minor thing would be better clarify aroun= d overlays.  Normally when I think of overlays, I think tunnels, not reg= ular layering.  But it seems like Adrian, for example, has a differing view= .  The document should clarify what it really means by network overlay b= y giving some examples.

 

The way the document is currently written captures the problem well, but at a very high-level.  It is easy to get a gist of what's going on, but it leaves a lot of room for interpretation as to the s= cope of the problem being tackled.

 

Anoop

 

On Thu, Sep 26, 2013 at 8:10 AM, Paul Quinn (paulq) &l= t;paulq@cisco.com> w= rote:

Hi Anoop, Ramki,

 

Great to see that you both have read the problem state= ment!  Let's make this constructive: we'd love to see your detailed comments= .  Please send them to the list, and/or the draft authors and we'll revi= ew them.

 

Paul

 

On Sep 25, 2013, at 6:59 PM, ramki Krishnan <ramk@Brocade.com>=

 wrote:



>>It may be that as Thomas says, we are not going to worry about non-transparent appliances at all, but then I'm not sure how we even implement something li= ke a load balancer.

 

>> Finally, I do think the problem statement needs a lot of work before we get= to solutions.  I think it would be useful to state somewhere in the chart= er that solutions would only be considered after the problem statement is in a reasonable shape and the WG participants are in agreement about what needs = to be solved.

 

Agree with Anoop. We do need to clarify this aspect in the problem statement.

 

Thanks,

Ramki

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=  On Behalf Of Anoop Ghanwani
Sent: Wednesday, September 25, 2013 11:11 AM
To: Ron Parker
Cc: Thomas Narten; <adrian@olddog.co.uk>; Paul Quinn (paulq); <<= span style=3D'color:purple'>nsc@ietf.org>
Subject: Re: [nsc] transparent vs. non-transparent services [wa= s Re: New NSC WG Charter - charter bullet #3]

 

When I mentioned transparent/non-transparent, I meant = that there was some change in the packet headers (whether at the IP, MAC, or TCP layers) for packets that were going to be subject to the service in questio= n, in the non-transparent case.  In other words, for the transparent case= , I cannot tell by looking at the packet headers whether or not the packet woul= d be subject to that service.  Clearly, there are others who think transpar= ent/non-transparent mean something else.  And that's just simply because there is not stan= dard terminology, which perhaps the WG can help define.

 

I think this also plays into where in the packet the N= SC header goes, and whether there can be multiple instances of the NSC header = in the packet.

 

If a certain layer's header is terminated at a service= box, it would be a layering violation to carry the NSC header beyond that point.=

 

For instance, if the NSC header is located between the= MAC and IP header, and the packet hits a load balancer that changes the IP &= ; MAC headers, that device would need to create a new NSC header.<= /p>

 

It may be that as Thomas says, we are not going to wor= ry about non-transparent appliances at all, but then I'm not sure how we even implement something like a load balancer.

 

Finally, I do think the problem statement needs a lot = of work before we get to solutions.  I think it would be useful to state somewhere in the charter that solutions would only be considered after the problem statement is in a reasonable shape and the WG participants are in agreement about what needs to be solved.

 

Anoop

 

On Wed, Sep 25, 2013 at 10:28 AM, Ron Parker <Ron_Parker@affirmednetworks.com> wrote= :

Thomas,

I agree that the notion of transparent service is not necessary to incorpor= ate in our work.

   Ron


-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, September 25, 2013 1:24 PM
To: Ron Parker
Cc: Paul Quinn (paulq); <adrian@olddog.co.uk>; Anoop Ghanwani; = <nsc@ietf.org>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NS= C WG Charter - charter bullet #3]

Ron,

> So is the definition of transparent -- packets are unchanged (headers,=
> content, etc.) and routing/switching path is unaltered?
> Or is it just the former?  The mere diversion to a service node w= ould
> seem to constitute "routing/switching is altered".

I think the point is we don't exactly have an agreed to defintion of "transparent" in the NSC context, so it's not particularly helpfu= l to use it in describing NSC behavior without being clear about what is meant.<= br>
For services in NSC, packets clearly will get modified in some cases (e.g. = NAT or proxies) but won't in others. So distinguishing types of services by how much they change the packets they inspect is probably not helpful for NSC. = NSC doesn't really care *what* the services does, just that the service exists = and packets need to be steered to travel through the service.

Thomas

 

 

 

--_000_C7634EB63EFD984A978DFB46EA5174F2BFFF996356HQ1EXCH01corp_-- From adrian@olddog.co.uk Fri Sep 27 02: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 A78D421F9C05 for ; Fri, 27 Sep 2013 02:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 kP44Gp9UrymV for ; Fri, 27 Sep 2013 02:18:36 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 7B64221F9A99 for ; Fri, 27 Sep 2013 02:18:35 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8R9IV17001624 for ; Fri, 27 Sep 2013 10:18:32 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8R9IReB001579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 27 Sep 2013 10:18:28 +0100 From: "Adrian Farrel" To: References: <1D70D757A2C9D54D83B4CBD7625FA80E012A3EB3@MISOUT7MSGUSR9I.ITServices.sbc.com> In-Reply-To: Date: Fri, 27 Sep 2013 10:18:24 +0100 Message-ID: <035901cebb62$85593c10$900bb430$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHDXeNkhHVCWnPyESZJr6xZz30V1JnwBv4A Content-Language: en-gb Subject: Re: [nsc] New NSC WG Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 09:18:42 -0000 Ken took the words out of my mouth. If we treat English as "mathematical logic" then using "or" as you propose is equally unhelpful. At this point I would like to continue to write our charters in the subset of English that is common in the US and the UK. Let me do it this way... Does anyone else on this mailing list have a problem with the words of the following text subject to the explanation I provided? > A document will describe the single service-level data plane > encapsulation format for conveying the service function chain > and the service function path, and for communicating context > information between nodes that implement service functions If we have rough consensus we will move on. If there is a body of people who find the text ambiguous as Maria does, then we will wheel out a lawyer to make it water-tight. Thanks, Adrian > -----Original Message----- > From: Ken Gray [mailto:kgray@juniper.net] > Sent: 27 September 2013 00:57 > To: NAPIERALA, MARIA H; adrian@olddog.co.uk; 'Jim Guichard (jguichar)' > Cc: nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter > > Hate to be a wet blanket, but since we're niggling over the word "and", > the proposed text could be interpreted as any one of "service function > chain ID, service function path, or for communicating context" but not > more than one at the same time. Replacing "and" with "or" didn't make it > any clearer for me. > > On 9/26/13 7:20 PM, "NAPIERALA, MARIA H" wrote: > > >> It is unequivocally in the charter. > > > >> The text that bothers you is: > >> A document will describe the single service-level data plane > >> encapsulation format for conveying the service function chain > >> and the service function path, and for communicating context > >> information between nodes that implement service functions. > >> > >> The use of "and" does not always mean that you MUST do both things. It > > > >Not always, but it might. And in the text above this distinction is not > >clear. > > > >> means you > >> can do both. > > > >> > >> Silly example: > >> The English language allows an English speaker to order food at > >> lunchtime and to > >> make proposals of marriage. > >> This does not require me to propose to the waiter each time I ask for a > >> burrito. > > > >So let's change the text as follows (to avoid explaining what "and" > >means): > > > >"A document will describe the single service-level data plane > >encapsulation format for conveying information such as > >service function chain ID, service function path, or for communicating > >context > >information between nodes that implement service functions." > > > > > >> In the text in the draft charter it says: > >> We will make one encapsulation protocol. > >> You can use this protocol to carry the service function chain. > >> You can also use this protocol to carry the service function path. > >> You can also use this protocol to carry metadata. > >> > >> OK? > >> > >> Adrian > >> > >> > -----Original Message----- > >> > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > >> > Sent: 26 September 2013 23:23 > >> > To: adrian@olddog.co.uk; 'Jim Guichard (jguichar)' > >> > Cc: nsc@ietf.org > >> > Subject: RE: [nsc] New NSC WG Charter > >> > > >> > I thought I said it already: the ability to carry the metadata > >> without > >> requiring to > >> > also carry service chain information (quote from the charter's write > >> up: > >> > "conveying the service function chain and the service function path") > >> in the > >> data > >> > packet. > >> > If you think this is already in the charter or it is outside of the > >> charter, I > >> would like > >> > to know. I cannot infer it from the write-up. > >> > > >> > Maria > >> > > >> > > -----Original Message----- > >> > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> > > Sent: Thursday, September 26, 2013 6:01 PM > >> > > To: NAPIERALA, MARIA H; 'Jim Guichard (jguichar)' > >> > > Cc: nsc@ietf.org > >> > > Subject: RE: [nsc] New NSC WG Charter > >> > > > >> > > I have to pile in here :-( > >> > > > >> > > Maria, I think you want to say "Don't require me to use a service- > >> level > >> > > encapsulation to achieve this function". > >> > > I don't believe you want to say "Allow me to have more than one > >> > > service-level > >> > > encapsulation to achieve this function." > >> > > > >> > > The text does not in any way preclude having other mechanisms for > >> doing > >> > > stuff. > >> > > In particular, configuring service chains at service nodes is an > >> > > obvious > >> > > approach. Similarly the service chain information might be > >> distributed > >> > > (ahead of > >> > > time) by some other protocol. > >> > > > >> > > The text does say that there will be at most one service-level > >> > > encapsulation. > >> > > Because setting out to have more than one new encapsulation > >> protocol to > >> > > do the > >> > > same thing. > >> > > > >> > > Text also says that there will be a service-level encapsulation. > >> > > Why does it do that? > >> > > Because, if this WG goes off and decides to tweak every protocol > >> that > >> > > is out > >> > > there to make a special way to carry service chain information in > >> that > >> > > protocol, > >> > > it will be a disaster (IMNSHO). > >> > > > >> > > If this doesn't address your concern, Maria, perhaps rather than > >> try to > >> > > change > >> > > the text or comment on what you think the text implies, you could > >> say > >> > > what it is > >> > > you want to be able to do. That way we can say whether it is in or > >> out > >> > > of scope > >> > > of the current text. > >> > > > >> > > Thanks, > >> > > Adrian > >> > > > >> > > > >> > > > -----Original Message----- > >> > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >> Behalf Of > >> > > > NAPIERALA, MARIA H > >> > > > Sent: 26 September 2013 16:35 > >> > > > To: Jim Guichard (jguichar) > >> > > > Cc: nsc@ietf.org > >> > > > Subject: Re: [nsc] New NSC WG Charter > >> > > > > >> > > > I understand. > >> > > > Why such document is specifically singled out in the charter? > >> Let's > >> > > leave it > >> > > to the > >> > > > solutions. > >> > > > > >> > > > Maria > >> > > > > >> > > > > -----Original Message----- > >> > > > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> > > > > Sent: Thursday, September 26, 2013 10:51 AM > >> > > > > To: NAPIERALA, MARIA H > >> > > > > Cc: nsc@ietf.org > >> > > > > Subject: Re: [nsc] New NSC WG Charter > >> > > > > > >> > > > > That is talking about context information - notice all the > >> *and's* > >> > > in > >> > > > > the > >> > > > > sentence ;-) > >> > > > > > >> > > > > On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" > >> wrote: > >> > > > > > >> > > > > >This paragraph is good. > >> > > > > > > >> > > > > >I was pointing out that the item 3 (under "Specifically, the > >> SFC > >> > > WG is > >> > > > > >chartered to deliver the following" heading) is implying a > >> > > specific > >> > > > > >solution (which is fine but it should not be the only one...): > >> > > > > > > >> > > > > >"3) Generic Service Function Chaining Encapsulation: A > >> document > >> > > will > >> > > > > >describe the single service-level data plane encapsulation > >> format > >> > > for > >> > > > > >conveying the service function chain and the service function > >> > > path, > >> > > > > and > >> > > > > >for communicating context information between nodes that > >> implement > >> > > > > >service functions..." > >> > > > > > > >> > > > > > > >> > > > > >Maria > >> > > > > > > >> > > > > >> -----Original Message----- > >> > > > > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> > > > > >> Sent: Thursday, September 26, 2013 10:31 AM > >> > > > > >> To: NAPIERALA, MARIA H > >> > > > > >> Cc: nsc@ietf.org > >> > > > > >> Subject: Re: [nsc] New NSC WG Charter > >> > > > > >> > >> > > > > >> Yes and I believe the following text from the charter covers > >> > > that -> > >> > > > > >> "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." > >> > > > > >> > >> > > > > >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" > >> > > wrote: > >> > > > > >> > >> > > > > >> >Jim, > >> > > > > >> > > >> > > > > >> >I said the opposite, i.e., how to carry metadata should be > >> part > >> > > of > >> > > > > the > >> > > > > >> >charter but how to carry the metadata should not > >> necessarily > >> > > > > dictate > >> > > > > >> how > >> > > > > >> >the service chain path itself is realized. > >> > > > > >> > > >> > > > > >> >Maria > >> > > > > >> > > >> > > > > >> >> -----Original Message----- > >> > > > > >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> > > > > >> >> Sent: Thursday, September 26, 2013 10:13 AM > >> > > > > >> >> To: NAPIERALA, MARIA H; Thomas Narten > >> > > > > >> >> Cc: nsc@ietf.org > >> > > > > >> >> Subject: Re: [nsc] New NSC WG Charter > >> > > > > >> >> > >> > > > > >> >> Hi Maria, > >> > > > > >> >> > >> > > > > >> >> Hope you are well. I do not believe the new charter text > >> > > prevents > >> > > > > >> the > >> > > > > >> >> realization of a service chain *without* metadata/context > >> > > > > >> information. > >> > > > > >> >> > >> > > > > >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" > > >> > > wrote: > >> > > > > >> >> > >> > > > > >> >> >I believe the NSC architecture should not preclude the > >> > > service > >> > > > > >> chain > >> > > > > >> >> >path/topology from being realized with some existing > >> (and > >> > > > > standard > >> > > > > >> ;-) > >> > > > > >> >> >network overlay (=virtual network) technique. But if the > >> > > > > decision > >> > > > > >> is > >> > > > > >> >> made > >> > > > > >> >> >that it does then this should be clearly stated in the > >> > > charter. > >> > > > > >> >> >What must be common to the service chain path solutions > >> is, > >> > > IMO, > >> > > > > >> the > >> > > > > >> >> >method for carrying the metadata/context information. > >> > > > > >> >> > > >> > > > > >> >> >Maria > >> > > > > >> >> > > >> > > > > >> >> >> -----Original Message----- > >> > > > > >> >> >> From: Thomas Narten [mailto:narten@us.ibm.com] > >> > > > > >> >> >> Sent: Wednesday, September 25, 2013 5:24 PM > >> > > > > >> >> >> To: NAPIERALA, MARIA H > >> > > > > >> >> >> Cc: Jim Guichard (jguichar); nsc@ietf.org > >> > > > > >> >> >> Subject: Re: [nsc] New NSC WG Charter > >> > > > > >> >> >> > >> > > > > >> >> >> "NAPIERALA, MARIA H" writes: > >> > > > > >> >> >> > >> > > > > >> >> >> > The group charter's write-up says that: "The Service > >> > > > > Function > >> > > > > >> >> >> > Chaining (SFC) working group will develop new > >> approaches > >> > > to > >> > > > > >> >> service > >> > > > > >> >> >> > delivery ..." (i.e., not one "approach" but > >> > > "approaches", > >> > > > > which > >> > > > > >> >> >> > means more than one). > >> > > > > >> >> >> > >> > > > > >> >> >> > But then is states that a document will be developed > >> > > such > >> > > > > that > >> > > > > >> it > >> > > > > >> >> >> > "will describe *the(?) single* service-level data > >> plane > >> > > > > >> >> >> > encapsulation format for conveying the service > >> function > >> > > > > chain > >> > > > > >> and > >> > > > > >> >> >> > the service function path associated with data > >> packets, > >> > > and > >> > > > > >> for > >> > > > > >> >> >> > carrying context information between nodes that > >> > > implement > >> > > > > >> service > >> > > > > >> >> >> > functions". > >> > > > > >> >> >> > >> > > > > >> >> >> > How to do you reconcile those two statements? > >> > > > > >> >> >> > >> > > > > >> >> >> Note: this inconsistency existed in the earlier > >> charter, I > >> > > > > didn't > >> > > > > >> >> >> introduce it. :-) > >> > > > > >> >> >> > >> > > > > >> >> >> I think for the service plane data encapsulation, we > >> > > should > >> > > > > aim > >> > > > > >> for > >> > > > > >> >> >> one. I'm understand the concern about writing that > >> into > >> > > the > >> > > > > >> charter > >> > > > > >> >> in > >> > > > > >> >> >> absolute terms, as I think the WG should have room to > >> > > discuss > >> > > > > and > >> > > > > >> it > >> > > > > >> >> >> may be too early to be definitive. But unless there is > >> > > > > compelling > >> > > > > >> >> >> reason, we should have one encap. (BTW, nothing new > >> here.. > >> > > > > this > >> > > > > >> is > >> > > > > >> >> >> normal IETF.) > >> > > > > >> >> >> > >> > > > > >> >> >> That said, I don't see the need for more than one > >> encap. > >> > > Does > >> > > > > >> anyone > >> > > > > >> >> >> think we do? And if so, why? > >> > > > > >> >> >> > >> > > > > >> >> >> > In my opinion, we should open the door for more than > >> one > >> > > > > >> solution > >> > > > > >> >> to > >> > > > > >> >> >> > service chaining. > >> > > > > >> >> >> > >> > > > > >> >> >> Ah, "solution to service chaining" (to me) is more > >> than > >> > > the > >> > > > > >> encap, > >> > > > > >> >> >> including the control plane and related stuff. So even > >> if > >> > > we > >> > > > > >> develop > >> > > > > >> >> >> one encap, that doesn't necessarily mean there is only > >> one > >> > > > > >> >> >> "solution". So the inconsistency may not be quite as > >> > > strong as > >> > > > > >> first > >> > > > > >> >> >> seems. > >> > > > > >> >> >> > >> > > > > >> >> >> Suggestion. change: > >> > > > > >> >> >> > >> > > > > >> >> >> A document will describe the single service-level > >> data > >> > > plane > >> > > > > >> >> >> encapsulation format ... > >> > > > > >> >> >> > >> > > > > >> >> >> To: > >> > > > > >> >> >> > >> > > > > >> >> >> A document will describe a service-level data plane > >> > > > > >> encapsulation > >> > > > > >> >> >> format ... > >> > > > > >> >> >> > >> > > > > >> >> >> this is a bit weaker, but still does (implicitely) > >> suggest > >> > > one > >> > > > > >> >> encap. > >> > > > > >> >> >> > >> > > > > >> >> >> or, if folk think this is not good enough, we could > >> add > >> > > text > >> > > > > >> saying > >> > > > > >> >> we > >> > > > > >> >> >> are aiming for one, and will only do more if ... > >> > > > > >> >> >> > >> > > > > >> >> >> But personally, I think it would be fine to have the > >> > > charter > >> > > > > say > >> > > > > >> one > >> > > > > >> >> >> encap, and if the WG concludes that one encap isn't > >> what > >> > > is > >> > > > > >> needed, > >> > > > > >> >> >> then recharter. We shouldn't look at rechartering as > >> > > > > >> "impossible". > >> > > > > >> >> We > >> > > > > >> >> >> just need to be able to make the case that more than > >> one > >> > > encap > >> > > > > is > >> > > > > >> >> >> necessary. If we can do that, I wouldn't think > >> > > rechartering > >> > > > > would > >> > > > > >> be > >> > > > > >> >> a > >> > > > > >> >> >> big deal. > >> > > > > >> >> >> > >> > > > > >> >> >> 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 tnadeau@lucidvision.com Fri Sep 27 06:30: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 2944621F9AE2 for ; Fri, 27 Sep 2013 06:30:38 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O370s6OSUoda for ; Fri, 27 Sep 2013 06:30:33 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id B67C711E80F8 for ; Fri, 27 Sep 2013 06:30:26 -0700 (PDT) Received: from [172.28.131.62] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 5D4EF25861BA; Fri, 27 Sep 2013 09:30:21 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8F7D1C22-4024-4A81-9362-57DFA94F7889"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Nadeau In-Reply-To: <028401cebb03$f0431ff0$d0c95fd0$@olddog.co.uk> Date: Fri, 27 Sep 2013 09:30:19 -0400 Message-Id: <4DEFAA61-1964-48FB-A13D-A5A0147FE8DD@lucidvision.com> References: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A3998@MISOUT7MSGUSR9I.ITServices.sbc.com> <028401cebb03$f0431ff0$d0c95fd0$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1510) Cc: nsc@ietf.org, "'Jim Guichard \(jguichar\)'" , "'NAPIERALA, MARIA H'" Subject: Re: [nsc] New NSC 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, 27 Sep 2013 13:30:38 -0000 --Apple-Mail=_8F7D1C22-4024-4A81-9362-57DFA94F7889 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 26, 2013:6:01 PM, at 6:01 PM, "Adrian Farrel" = wrote: > I have to pile in here :-( >=20 > Maria, I think you want to say "Don't require me to use a = service-level > encapsulation to achieve this function".=20 > I don't believe you want to say "Allow me to have more than one = service-level > encapsulation to achieve this function." >=20 > The text does not in any way preclude having other mechanisms for = doing stuff.=20 > In particular, configuring service chains at service nodes is an = obvious > approach. Similarly the service chain information might be distributed = (ahead of > time) by some other protocol. >=20 > The text does say that there will be at most one service-level = encapsulation. > Because setting out to have more than one new encapsulation protocol = to do the > same thing. >=20 > Text also says that there will be a service-level encapsulation. > Why does it do that? > Because, if this WG goes off and decides to tweak every protocol that = is out > there to make a special way to carry service chain information in that = protocol, > it will be a disaster (IMNSHO). Agreed. This is very important to be clear on. --Tom >=20 > If this doesn't address your concern, Maria, perhaps rather than try = to change > the text or comment on what you think the text implies, you could say = what it is > you want to be able to do. That way we can say whether it is in or out = of scope > of the current text. >=20 > Thanks, > Adrian >=20 >=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> NAPIERALA, MARIA H >> Sent: 26 September 2013 16:35 >> To: Jim Guichard (jguichar) >> Cc: nsc@ietf.org >> Subject: Re: [nsc] New NSC WG Charter >>=20 >> I understand. >> Why such document is specifically singled out in the charter? Let's = leave it > to the >> solutions. >>=20 >> Maria >>=20 >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Thursday, September 26, 2013 10:51 AM >>> To: NAPIERALA, MARIA H >>> Cc: nsc@ietf.org >>> Subject: Re: [nsc] New NSC WG Charter >>>=20 >>> That is talking about context information - notice all the *and's* = in >>> the >>> sentence ;-) >>>=20 >>> On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: >>>=20 >>>> This paragraph is good. >>>>=20 >>>> I was pointing out that the item 3 (under "Specifically, the SFC WG = is >>>> chartered to deliver the following" heading) is implying a specific >>>> solution (which is fine but it should not be the only one...): >>>>=20 >>>> "3) Generic Service Function Chaining Encapsulation: A document = will >>>> describe the single service-level data plane encapsulation format = for >>>> conveying the service function chain and the service function path, >>> and >>>> for communicating context information between nodes that implement >>>> service functions..." >>>>=20 >>>>=20 >>>> Maria >>>>=20 >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Thursday, September 26, 2013 10:31 AM >>>>> To: NAPIERALA, MARIA H >>>>> Cc: nsc@ietf.org >>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>=20 >>>>> Yes and I believe the following text from the charter covers that = -> >>>>> "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." >>>>>=20 >>>>> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: >>>>>=20 >>>>>> Jim, >>>>>>=20 >>>>>> I said the opposite, i.e., how to carry metadata should be part = of >>> the >>>>>> charter but how to carry the metadata should not necessarily >>> dictate >>>>> how >>>>>> the service chain path itself is realized. >>>>>>=20 >>>>>> Maria >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>> Sent: Thursday, September 26, 2013 10:13 AM >>>>>>> To: NAPIERALA, MARIA H; Thomas Narten >>>>>>> Cc: nsc@ietf.org >>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>=20 >>>>>>> Hi Maria, >>>>>>>=20 >>>>>>> Hope you are well. I do not believe the new charter text = prevents >>>>> the >>>>>>> realization of a service chain *without* metadata/context >>>>> information. >>>>>>>=20 >>>>>>> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: >>>>>>>=20 >>>>>>>> I believe the NSC architecture should not preclude the service >>>>> chain >>>>>>>> path/topology from being realized with some existing (and >>> standard >>>>> ;-) >>>>>>>> network overlay (=3Dvirtual network) technique. But if the >>> decision >>>>> is >>>>>>> made >>>>>>>> that it does then this should be clearly stated in the charter. >>>>>>>> What must be common to the service chain path solutions is, = IMO, >>>>> the >>>>>>>> method for carrying the metadata/context information. >>>>>>>>=20 >>>>>>>> Maria >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Thomas Narten [mailto:narten@us.ibm.com] >>>>>>>>> Sent: Wednesday, September 25, 2013 5:24 PM >>>>>>>>> To: NAPIERALA, MARIA H >>>>>>>>> Cc: Jim Guichard (jguichar); nsc@ietf.org >>>>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>>>=20 >>>>>>>>> "NAPIERALA, MARIA H" writes: >>>>>>>>>=20 >>>>>>>>>> The group charter's write-up says that: "The Service >>> Function >>>>>>>>>> Chaining (SFC) working group will develop new approaches to >>>>>>> service >>>>>>>>>> delivery ..." (i.e., not one "approach" but "approaches", >>> which >>>>>>>>>> means more than one). >>>>>>>>>=20 >>>>>>>>>> But then is states that a document will be developed such >>> that >>>>> it >>>>>>>>>> "will describe *the(?) single* service-level data plane >>>>>>>>>> encapsulation format for conveying the service function >>> chain >>>>> and >>>>>>>>>> the service function path associated with data packets, and >>>>> for >>>>>>>>>> carrying context information between nodes that implement >>>>> service >>>>>>>>>> functions". >>>>>>>>>=20 >>>>>>>>>> How to do you reconcile those two statements? >>>>>>>>>=20 >>>>>>>>> Note: this inconsistency existed in the earlier charter, I >>> didn't >>>>>>>>> introduce it. :-) >>>>>>>>>=20 >>>>>>>>> I think for the service plane data encapsulation, we should >>> aim >>>>> for >>>>>>>>> one. I'm understand the concern about writing that into the >>>>> charter >>>>>>> in >>>>>>>>> absolute terms, as I think the WG should have room to discuss >>> and >>>>> it >>>>>>>>> may be too early to be definitive. But unless there is >>> compelling >>>>>>>>> reason, we should have one encap. (BTW, nothing new here.. >>> this >>>>> is >>>>>>>>> normal IETF.) >>>>>>>>>=20 >>>>>>>>> That said, I don't see the need for more than one encap. Does >>>>> anyone >>>>>>>>> think we do? And if so, why? >>>>>>>>>=20 >>>>>>>>>> In my opinion, we should open the door for more than one >>>>> solution >>>>>>> to >>>>>>>>>> service chaining. >>>>>>>>>=20 >>>>>>>>> Ah, "solution to service chaining" (to me) is more than the >>>>> encap, >>>>>>>>> including the control plane and related stuff. So even if we >>>>> develop >>>>>>>>> one encap, that doesn't necessarily mean there is only one >>>>>>>>> "solution". So the inconsistency may not be quite as strong as >>>>> first >>>>>>>>> seems. >>>>>>>>>=20 >>>>>>>>> Suggestion. change: >>>>>>>>>=20 >>>>>>>>> A document will describe the single service-level data plane >>>>>>>>> encapsulation format ... >>>>>>>>>=20 >>>>>>>>> To: >>>>>>>>>=20 >>>>>>>>> A document will describe a service-level data plane >>>>> encapsulation >>>>>>>>> format ... >>>>>>>>>=20 >>>>>>>>> this is a bit weaker, but still does (implicitely) suggest one >>>>>>> encap. >>>>>>>>>=20 >>>>>>>>> or, if folk think this is not good enough, we could add text >>>>> saying >>>>>>> we >>>>>>>>> are aiming for one, and will only do more if ... >>>>>>>>>=20 >>>>>>>>> But personally, I think it would be fine to have the charter >>> say >>>>> one >>>>>>>>> encap, and if the WG concludes that one encap isn't what is >>>>> needed, >>>>>>>>> then recharter. We shouldn't look at rechartering as >>>>> "impossible". >>>>>>> We >>>>>>>>> just need to be able to make the case that more than one encap >>> is >>>>>>>>> necessary. If we can do that, I wouldn't think rechartering >>> would >>>>> be >>>>>>> a >>>>>>>>> big deal. >>>>>>>>>=20 >>>>>>>>> Thomas >>>>>>>>=20 >>>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 --Apple-Mail=_8F7D1C22-4024-4A81-9362-57DFA94F7889 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 iQIcBAEBCgAGBQJSRYhsAAoJEPcO+I7eiUJZDOUQAKVeqesYLIdj9XHOyEEBTRPo t8IAZxsQLjVSjunfp5iWnP4IAsF2c0De0ePSFGqV2pkErLxe2859x45SFFu/NQL0 9v1fWxIWAXvl7tQqpCL8dJXUUUksbo9AZRKYIc0AwU8Y+rerZ1Jh5gKFOvqSlOor BZuZSMf4gJQz283US7yjXtB1k11KpaoTFsQcJbfvinuxCuj1gAYy8zpQTNUrbT2G 7wboBkiXNB08PCH68bbdeKROLmlvr+6uc6dyeLYXnG32JxB2AdueppgxYcfNrfIQ G7+IqI/PKJAUco96dvbVRHBUNtmoViRwaSoP0I7XyqNtVohm/jaq5KF5SuKtUipc nnrcUGTkGMhI0aHH8kk29ddvXcmmr6iRBX1ZnCyKQOfhF3Kk1tjv+wUX54w3BcW5 pPElUiwGGjCzhifToq0nbkpKBA73H8VJS+cda975rUkQCWsDdDi10sl93nnU/I76 3R3eFCCjodDPGgGgTr10uTcTNXrGYxg+yxBT6/0zVTxIxNtyEYKyPyEE5PJ9sTLy n35rR7SCGS1SCZXHzJvlKW5GNEjt074gZ3PYAqy6idoiu5c86DMhNv0/fr+wL6Et d7OHzc/BVkLUcRfhO9VLGb8IYrOHbsP5oGZXectZGbOyDxDyz/y6hiw01lx9DJ1i YG6zOAYKK7vLtKEg7TU7 =rSTL -----END PGP SIGNATURE----- --Apple-Mail=_8F7D1C22-4024-4A81-9362-57DFA94F7889-- From Ron_Parker@affirmednetworks.com Fri Sep 27 06:48: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 015F221F9CA4 for ; Fri, 27 Sep 2013 06:48:15 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Swhjd66XIDKA for ; Fri, 27 Sep 2013 06:48:10 -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 35CFB21F9DBA for ; Fri, 27 Sep 2013 06:48:10 -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; Fri, 27 Sep 2013 06:48:00 -0700 From: Ron Parker To: Thomas Nadeau , "adrian@olddog.co.uk" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABuUAgAES7ICAAAQYAIAAARcAgAAEy4CAAADIgIAADB6AgABsDgCAAQOMgP//jWIA Date: Fri, 27 Sep 2013 13:47:59 +0000 Message-ID: References: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A3998@MISOUT7MSGUSR9I.ITServices.sbc.com> <028401cebb03$f0431ff0$d0c95fd0$@olddog.co.uk> <4DEFAA61-1964-48FB-A13D-A5A0147FE8DD@lucidvision.com> In-Reply-To: <4DEFAA61-1964-48FB-A13D-A5A0147FE8DD@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "'Jim Guichard \(jguichar\)'" , "'NAPIERALA, MARIA H'" Subject: Re: [nsc] New NSC 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, 27 Sep 2013 13:48:15 -0000 Sorry, but I'll jump in, too. I couldn't agree more that a single service header definition is necessary = to make this effort successful in terms of adoption and deployment and I su= pport stating that requirement up front, in the charter. Whether or not t= he service header is fixed length, variable length, TLV, AVP, carries this = kind of metadata or that, does not have to be in the charter. Another related topic that perhaps isn't quite as fundamental as to be incl= uded in the charter, but will quickly come to the fore during discussion of= our actual deliverables is whether a single "transport" encapsulation is t= o be utilized. For much the same reason that Tom describes about tweaking= many protocols to describe the service header, if we need to tweak many pr= otocols for how to transport our new unified service header we'll run into = the same issue (i.e., special ethertypes, special MPLS labels, etc, etc.). Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Nadeau Sent: Friday, September 27, 2013 9:30 AM To: adrian@olddog.co.uk Cc: nsc@ietf.org; 'Jim Guichard (jguichar)'; 'NAPIERALA, MARIA H' Subject: Re: [nsc] New NSC WG Charter On Sep 26, 2013:6:01 PM, at 6:01 PM, "Adrian Farrel" = wrote: > I have to pile in here :-( >=20 > Maria, I think you want to say "Don't require me to use a=20 > service-level encapsulation to achieve this function". > I don't believe you want to say "Allow me to have more than one=20 > service-level encapsulation to achieve this function." >=20 > The text does not in any way preclude having other mechanisms for doing s= tuff.=20 > In particular, configuring service chains at service nodes is an=20 > obvious approach. Similarly the service chain information might be=20 > distributed (ahead of > time) by some other protocol. >=20 > The text does say that there will be at most one service-level encapsulat= ion. > Because setting out to have more than one new encapsulation protocol=20 > to do the same thing. >=20 > Text also says that there will be a service-level encapsulation. > Why does it do that? > Because, if this WG goes off and decides to tweak every protocol that=20 > is out there to make a special way to carry service chain information=20 > in that protocol, it will be a disaster (IMNSHO). Agreed. This is very important to be clear on. --Tom >=20 > If this doesn't address your concern, Maria, perhaps rather than try=20 > to change the text or comment on what you think the text implies, you=20 > could say what it is you want to be able to do. That way we can say=20 > whether it is in or out of scope of the current text. >=20 > Thanks, > Adrian >=20 >=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >> NAPIERALA, MARIA H >> Sent: 26 September 2013 16:35 >> To: Jim Guichard (jguichar) >> Cc: nsc@ietf.org >> Subject: Re: [nsc] New NSC WG Charter >>=20 >> I understand. >> Why such document is specifically singled out in the charter? Let's=20 >> leave it > to the >> solutions. >>=20 >> Maria >>=20 >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Thursday, September 26, 2013 10:51 AM >>> To: NAPIERALA, MARIA H >>> Cc: nsc@ietf.org >>> Subject: Re: [nsc] New NSC WG Charter >>>=20 >>> That is talking about context information - notice all the *and's*=20 >>> in the sentence ;-) >>>=20 >>> On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: >>>=20 >>>> This paragraph is good. >>>>=20 >>>> I was pointing out that the item 3 (under "Specifically, the SFC WG=20 >>>> is chartered to deliver the following" heading) is implying a=20 >>>> specific solution (which is fine but it should not be the only one...)= : >>>>=20 >>>> "3) Generic Service Function Chaining Encapsulation: A document=20 >>>> will describe the single service-level data plane encapsulation=20 >>>> format for conveying the service function chain and the service=20 >>>> function path, >>> and >>>> for communicating context information between nodes that implement=20 >>>> service functions..." >>>>=20 >>>>=20 >>>> Maria >>>>=20 >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Thursday, September 26, 2013 10:31 AM >>>>> To: NAPIERALA, MARIA H >>>>> Cc: nsc@ietf.org >>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>=20 >>>>> Yes and I believe the following text from the charter covers that=20 >>>>> -> "The Service Function Chaining (SFC) working group will develop=20 >>>>> new approaches to service delivery and deployment. It will produce=20 >>>>> a framework for service function chaining that includes the=20 >>>>> necessary protocols or protocol extensions to convey the service=20 >>>>> path and service path information to nodes that implement service=20 >>>>> functions, as well as mechanisms for steering traffic through=20 >>>>> service functions." >>>>>=20 >>>>> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: >>>>>=20 >>>>>> Jim, >>>>>>=20 >>>>>> I said the opposite, i.e., how to carry metadata should be part=20 >>>>>> of >>> the >>>>>> charter but how to carry the metadata should not necessarily >>> dictate >>>>> how >>>>>> the service chain path itself is realized. >>>>>>=20 >>>>>> Maria >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>> Sent: Thursday, September 26, 2013 10:13 AM >>>>>>> To: NAPIERALA, MARIA H; Thomas Narten >>>>>>> Cc: nsc@ietf.org >>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>=20 >>>>>>> Hi Maria, >>>>>>>=20 >>>>>>> Hope you are well. I do not believe the new charter text=20 >>>>>>> prevents >>>>> the >>>>>>> realization of a service chain *without* metadata/context >>>>> information. >>>>>>>=20 >>>>>>> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: >>>>>>>=20 >>>>>>>> I believe the NSC architecture should not preclude the service >>>>> chain >>>>>>>> path/topology from being realized with some existing (and >>> standard >>>>> ;-) >>>>>>>> network overlay (=3Dvirtual network) technique. But if the >>> decision >>>>> is >>>>>>> made >>>>>>>> that it does then this should be clearly stated in the charter. >>>>>>>> What must be common to the service chain path solutions is,=20 >>>>>>>> IMO, >>>>> the >>>>>>>> method for carrying the metadata/context information. >>>>>>>>=20 >>>>>>>> Maria >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Thomas Narten [mailto:narten@us.ibm.com] >>>>>>>>> Sent: Wednesday, September 25, 2013 5:24 PM >>>>>>>>> To: NAPIERALA, MARIA H >>>>>>>>> Cc: Jim Guichard (jguichar); nsc@ietf.org >>>>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>>>=20 >>>>>>>>> "NAPIERALA, MARIA H" writes: >>>>>>>>>=20 >>>>>>>>>> The group charter's write-up says that: "The Service >>> Function >>>>>>>>>> Chaining (SFC) working group will develop new approaches to >>>>>>> service >>>>>>>>>> delivery ..." (i.e., not one "approach" but "approaches", >>> which >>>>>>>>>> means more than one). >>>>>>>>>=20 >>>>>>>>>> But then is states that a document will be developed such >>> that >>>>> it >>>>>>>>>> "will describe *the(?) single* service-level data plane=20 >>>>>>>>>> encapsulation format for conveying the service function >>> chain >>>>> and >>>>>>>>>> the service function path associated with data packets, and >>>>> for >>>>>>>>>> carrying context information between nodes that implement >>>>> service >>>>>>>>>> functions". >>>>>>>>>=20 >>>>>>>>>> How to do you reconcile those two statements? >>>>>>>>>=20 >>>>>>>>> Note: this inconsistency existed in the earlier charter, I >>> didn't >>>>>>>>> introduce it. :-) >>>>>>>>>=20 >>>>>>>>> I think for the service plane data encapsulation, we should >>> aim >>>>> for >>>>>>>>> one. I'm understand the concern about writing that into the >>>>> charter >>>>>>> in >>>>>>>>> absolute terms, as I think the WG should have room to discuss >>> and >>>>> it >>>>>>>>> may be too early to be definitive. But unless there is >>> compelling >>>>>>>>> reason, we should have one encap. (BTW, nothing new here.. >>> this >>>>> is >>>>>>>>> normal IETF.) >>>>>>>>>=20 >>>>>>>>> That said, I don't see the need for more than one encap. Does >>>>> anyone >>>>>>>>> think we do? And if so, why? >>>>>>>>>=20 >>>>>>>>>> In my opinion, we should open the door for more than one >>>>> solution >>>>>>> to >>>>>>>>>> service chaining. >>>>>>>>>=20 >>>>>>>>> Ah, "solution to service chaining" (to me) is more than the >>>>> encap, >>>>>>>>> including the control plane and related stuff. So even if we >>>>> develop >>>>>>>>> one encap, that doesn't necessarily mean there is only one=20 >>>>>>>>> "solution". So the inconsistency may not be quite as strong as >>>>> first >>>>>>>>> seems. >>>>>>>>>=20 >>>>>>>>> Suggestion. change: >>>>>>>>>=20 >>>>>>>>> A document will describe the single service-level data plane=20 >>>>>>>>> encapsulation format ... >>>>>>>>>=20 >>>>>>>>> To: >>>>>>>>>=20 >>>>>>>>> A document will describe a service-level data plane >>>>> encapsulation >>>>>>>>> format ... >>>>>>>>>=20 >>>>>>>>> this is a bit weaker, but still does (implicitely) suggest one >>>>>>> encap. >>>>>>>>>=20 >>>>>>>>> or, if folk think this is not good enough, we could add text >>>>> saying >>>>>>> we >>>>>>>>> are aiming for one, and will only do more if ... >>>>>>>>>=20 >>>>>>>>> But personally, I think it would be fine to have the charter >>> say >>>>> one >>>>>>>>> encap, and if the WG concludes that one encap isn't what is >>>>> needed, >>>>>>>>> then recharter. We shouldn't look at rechartering as >>>>> "impossible". >>>>>>> We >>>>>>>>> just need to be able to make the case that more than one encap >>> is >>>>>>>>> necessary. If we can do that, I wouldn't think rechartering >>> would >>>>> be >>>>>>> a >>>>>>>>> big deal. >>>>>>>>>=20 >>>>>>>>> Thomas >>>>>>>>=20 >>>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 From jguichar@cisco.com Fri Sep 27 06:59: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 CB17621F9C83 for ; Fri, 27 Sep 2013 06:58:57 -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=[AWL=0.000, 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 wU5pUgv8x88X for ; Fri, 27 Sep 2013 06:58:49 -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 9D3AB11E8150 for ; Fri, 27 Sep 2013 06:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11243; q=dns/txt; s=iport; t=1380290326; x=1381499926; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Ga35nKgZY8iR/jwcmmOSbRhsn1tNU4fKkSgJOPMV8g4=; b=nETEzIcUDxXHN7XN4PzIDC7XctKxFy+1B9LalSaRFZvxob5fshD5Mp+E OC8Z0Hj2T6kkcP8O1sLyzQgaCpkvj4DVV+h2JZ5LD3FBMKIypM/4zA8xU NZHHoGVGfNixGmkLewz1JGOiHE0HNI3sKb2UAJGJCz4ARlGDpiOA0R9cH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAH6ORVKtJV2Y/2dsb2JhbABZgwc4UsBLgRwWdIIlAQEBBAEBASQTLQcLDAYBCBEBAwEBAQoUCS4LFAMGCAIEAQ0FCBOHawy6MQSPIAYrBwIEgxeBAQOpdYMkgio X-IronPort-AV: E=Sophos;i="4.90,993,1371081600"; d="scan'208";a="265299116" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 27 Sep 2013 13:58:46 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8RDwjrW022222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 13:58:45 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 08:58:45 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker , Thomas Nadeau , "adrian@olddog.co.uk" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXSUUAgAAOJgCAAAZxgIAABuUAgADP2YCAAEcrAP//vgYAgABH3ID//723gIAATy+AgABsDgCAAQOMgIAABO+A//+/8QA= Date: Fri, 27 Sep 2013 13:58:44 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6B5820@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.181] Content-Type: text/plain; charset="us-ascii" Content-ID: <701832BCE81962438B162E6534C6CC21@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "'NAPIERALA, MARIA H'" Subject: Re: [nsc] New NSC 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, 27 Sep 2013 13:59:00 -0000 Hi Ron, It is certainly true that each transport will need some mechanism to indicate that our service header is present and there are 3 relevant drafts for this already written and associated with our WG efforts. However, an indication in the transport is much easier than trying to fit all of the "stuff" we need for services into each and every transport protocol.=20 On 9/27/13 9:47 AM, "Ron Parker" wrote: >Sorry, but I'll jump in, too. > >I couldn't agree more that a single service header definition is >necessary to make this effort successful in terms of adoption and >deployment and I support stating that requirement up front, in the >charter. Whether or not the service header is fixed length, variable >length, TLV, AVP, carries this kind of metadata or that, does not have to >be in the charter. > >Another related topic that perhaps isn't quite as fundamental as to be >included in the charter, but will quickly come to the fore during >discussion of our actual deliverables is whether a single "transport" >encapsulation is to be utilized. For much the same reason that Tom >describes about tweaking many protocols to describe the service header, >if we need to tweak many protocols for how to transport our new unified >service header we'll run into the same issue (i.e., special ethertypes, >special MPLS labels, etc, etc.). > > Ron > > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Thomas Nadeau >Sent: Friday, September 27, 2013 9:30 AM >To: adrian@olddog.co.uk >Cc: nsc@ietf.org; 'Jim Guichard (jguichar)'; 'NAPIERALA, MARIA H' >Subject: Re: [nsc] New NSC WG Charter > > >On Sep 26, 2013:6:01 PM, at 6:01 PM, "Adrian Farrel" > wrote: > >> I have to pile in here :-( >>=20 >> Maria, I think you want to say "Don't require me to use a >> service-level encapsulation to achieve this function". >> I don't believe you want to say "Allow me to have more than one >> service-level encapsulation to achieve this function." >>=20 >> The text does not in any way preclude having other mechanisms for doing >>stuff.=20 >> In particular, configuring service chains at service nodes is an >> obvious approach. Similarly the service chain information might be >> distributed (ahead of >> time) by some other protocol. >>=20 >> The text does say that there will be at most one service-level >>encapsulation. >> Because setting out to have more than one new encapsulation protocol >> to do the same thing. >>=20 >> Text also says that there will be a service-level encapsulation. >> Why does it do that? >> Because, if this WG goes off and decides to tweak every protocol that >> is out there to make a special way to carry service chain information >> in that protocol, it will be a disaster (IMNSHO). > > Agreed. This is very important to be clear on. > > --Tom > > >>=20 >> If this doesn't address your concern, Maria, perhaps rather than try >> to change the text or comment on what you think the text implies, you >> could say what it is you want to be able to do. That way we can say >> whether it is in or out of scope of the current text. >>=20 >> Thanks, >> Adrian >>=20 >>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>> NAPIERALA, MARIA H >>> Sent: 26 September 2013 16:35 >>> To: Jim Guichard (jguichar) >>> Cc: nsc@ietf.org >>> Subject: Re: [nsc] New NSC WG Charter >>>=20 >>> I understand. >>> Why such document is specifically singled out in the charter? Let's >>> leave it >> to the >>> solutions. >>>=20 >>> Maria >>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Thursday, September 26, 2013 10:51 AM >>>> To: NAPIERALA, MARIA H >>>> Cc: nsc@ietf.org >>>> Subject: Re: [nsc] New NSC WG Charter >>>>=20 >>>> That is talking about context information - notice all the *and's* >>>> in the sentence ;-) >>>>=20 >>>> On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: >>>>=20 >>>>> This paragraph is good. >>>>>=20 >>>>> I was pointing out that the item 3 (under "Specifically, the SFC WG >>>>> is chartered to deliver the following" heading) is implying a >>>>> specific solution (which is fine but it should not be the only >>>>>one...): >>>>>=20 >>>>> "3) Generic Service Function Chaining Encapsulation: A document >>>>> will describe the single service-level data plane encapsulation >>>>> format for conveying the service function chain and the service >>>>> function path, >>>> and >>>>> for communicating context information between nodes that implement >>>>> service functions..." >>>>>=20 >>>>>=20 >>>>> Maria >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>> Sent: Thursday, September 26, 2013 10:31 AM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: nsc@ietf.org >>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>=20 >>>>>> Yes and I believe the following text from the charter covers that >>>>>> -> "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." >>>>>>=20 >>>>>> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: >>>>>>=20 >>>>>>> Jim, >>>>>>>=20 >>>>>>> I said the opposite, i.e., how to carry metadata should be part >>>>>>> of >>>> the >>>>>>> charter but how to carry the metadata should not necessarily >>>> dictate >>>>>> how >>>>>>> the service chain path itself is realized. >>>>>>>=20 >>>>>>> Maria >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Thursday, September 26, 2013 10:13 AM >>>>>>>> To: NAPIERALA, MARIA H; Thomas Narten >>>>>>>> Cc: nsc@ietf.org >>>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>>=20 >>>>>>>> Hi Maria, >>>>>>>>=20 >>>>>>>> Hope you are well. I do not believe the new charter text >>>>>>>> prevents >>>>>> the >>>>>>>> realization of a service chain *without* metadata/context >>>>>> information. >>>>>>>>=20 >>>>>>>> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: >>>>>>>>=20 >>>>>>>>> I believe the NSC architecture should not preclude the service >>>>>> chain >>>>>>>>> path/topology from being realized with some existing (and >>>> standard >>>>>> ;-) >>>>>>>>> network overlay (=3Dvirtual network) technique. But if the >>>> decision >>>>>> is >>>>>>>> made >>>>>>>>> that it does then this should be clearly stated in the charter. >>>>>>>>> What must be common to the service chain path solutions is, >>>>>>>>> IMO, >>>>>> the >>>>>>>>> method for carrying the metadata/context information. >>>>>>>>>=20 >>>>>>>>> Maria >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Thomas Narten [mailto:narten@us.ibm.com] >>>>>>>>>> Sent: Wednesday, September 25, 2013 5:24 PM >>>>>>>>>> To: NAPIERALA, MARIA H >>>>>>>>>> Cc: Jim Guichard (jguichar); nsc@ietf.org >>>>>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>>>>=20 >>>>>>>>>> "NAPIERALA, MARIA H" writes: >>>>>>>>>>=20 >>>>>>>>>>> The group charter's write-up says that: "The Service >>>> Function >>>>>>>>>>> Chaining (SFC) working group will develop new approaches to >>>>>>>> service >>>>>>>>>>> delivery ..." (i.e., not one "approach" but "approaches", >>>> which >>>>>>>>>>> means more than one). >>>>>>>>>>=20 >>>>>>>>>>> But then is states that a document will be developed such >>>> that >>>>>> it >>>>>>>>>>> "will describe *the(?) single* service-level data plane >>>>>>>>>>> encapsulation format for conveying the service function >>>> chain >>>>>> and >>>>>>>>>>> the service function path associated with data packets, and >>>>>> for >>>>>>>>>>> carrying context information between nodes that implement >>>>>> service >>>>>>>>>>> functions". >>>>>>>>>>=20 >>>>>>>>>>> How to do you reconcile those two statements? >>>>>>>>>>=20 >>>>>>>>>> Note: this inconsistency existed in the earlier charter, I >>>> didn't >>>>>>>>>> introduce it. :-) >>>>>>>>>>=20 >>>>>>>>>> I think for the service plane data encapsulation, we should >>>> aim >>>>>> for >>>>>>>>>> one. I'm understand the concern about writing that into the >>>>>> charter >>>>>>>> in >>>>>>>>>> absolute terms, as I think the WG should have room to discuss >>>> and >>>>>> it >>>>>>>>>> may be too early to be definitive. But unless there is >>>> compelling >>>>>>>>>> reason, we should have one encap. (BTW, nothing new here.. >>>> this >>>>>> is >>>>>>>>>> normal IETF.) >>>>>>>>>>=20 >>>>>>>>>> That said, I don't see the need for more than one encap. Does >>>>>> anyone >>>>>>>>>> think we do? And if so, why? >>>>>>>>>>=20 >>>>>>>>>>> In my opinion, we should open the door for more than one >>>>>> solution >>>>>>>> to >>>>>>>>>>> service chaining. >>>>>>>>>>=20 >>>>>>>>>> Ah, "solution to service chaining" (to me) is more than the >>>>>> encap, >>>>>>>>>> including the control plane and related stuff. So even if we >>>>>> develop >>>>>>>>>> one encap, that doesn't necessarily mean there is only one >>>>>>>>>> "solution". So the inconsistency may not be quite as strong as >>>>>> first >>>>>>>>>> seems. >>>>>>>>>>=20 >>>>>>>>>> Suggestion. change: >>>>>>>>>>=20 >>>>>>>>>> A document will describe the single service-level data plane >>>>>>>>>> encapsulation format ... >>>>>>>>>>=20 >>>>>>>>>> To: >>>>>>>>>>=20 >>>>>>>>>> A document will describe a service-level data plane >>>>>> encapsulation >>>>>>>>>> format ... >>>>>>>>>>=20 >>>>>>>>>> this is a bit weaker, but still does (implicitely) suggest one >>>>>>>> encap. >>>>>>>>>>=20 >>>>>>>>>> or, if folk think this is not good enough, we could add text >>>>>> saying >>>>>>>> we >>>>>>>>>> are aiming for one, and will only do more if ... >>>>>>>>>>=20 >>>>>>>>>> But personally, I think it would be fine to have the charter >>>> say >>>>>> one >>>>>>>>>> encap, and if the WG concludes that one encap isn't what is >>>>>> needed, >>>>>>>>>> then recharter. We shouldn't look at rechartering as >>>>>> "impossible". >>>>>>>> We >>>>>>>>>> just need to be able to make the case that more than one encap >>>> is >>>>>>>>>> necessary. If we can do that, I wouldn't think rechartering >>>> would >>>>>> be >>>>>>>> a >>>>>>>>>> big deal. >>>>>>>>>>=20 >>>>>>>>>> Thomas >>>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >>=20 > From Ron_Parker@affirmednetworks.com Fri Sep 27 07:07:02 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8241321F9AA4 for ; Fri, 27 Sep 2013 07:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6GEyn+miu84 for ; Fri, 27 Sep 2013 07:06:57 -0700 (PDT) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id CF35211E8160 for ; Fri, 27 Sep 2013 07:06:22 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0123.003; Fri, 27 Sep 2013 07:06:22 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , Thomas Nadeau , "adrian@olddog.co.uk" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABuUAgAES7ICAAAQYAIAAARcAgAAEy4CAAADIgIAADB6AgABsDgCAAQOMgP//jWIAgAB6jgD//4yM4A== Date: Fri, 27 Sep 2013 14:06:21 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F6B5820@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6B5820@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "'NAPIERALA, MARIA H'" Subject: Re: [nsc] New NSC 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, 27 Sep 2013 14:07:02 -0000 Thanks, Jim. I agree and for that reason feel that we can and should take the transport = encapsulation issue up during WG discussions and not burden the charter wit= h this. Ron -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Friday, September 27, 2013 9:59 AM To: Ron Parker; Thomas Nadeau; adrian@olddog.co.uk Cc: nsc@ietf.org; 'NAPIERALA, MARIA H' Subject: Re: [nsc] New NSC WG Charter Hi Ron, It is certainly true that each transport will need some mechanism to indica= te that our service header is present and there are 3 relevant drafts for t= his already written and associated with our WG efforts. However, an indication in the transport is much easier than trying to fit a= ll of the "stuff" we need for services into each and every transport protoc= ol.=20 On 9/27/13 9:47 AM, "Ron Parker" wrote: >Sorry, but I'll jump in, too. > >I couldn't agree more that a single service header definition is=20 >necessary to make this effort successful in terms of adoption and=20 >deployment and I support stating that requirement up front, in the >charter. Whether or not the service header is fixed length, variable >length, TLV, AVP, carries this kind of metadata or that, does not have=20 >to be in the charter. > >Another related topic that perhaps isn't quite as fundamental as to be=20 >included in the charter, but will quickly come to the fore during=20 >discussion of our actual deliverables is whether a single "transport" >encapsulation is to be utilized. For much the same reason that Tom >describes about tweaking many protocols to describe the service header,=20 >if we need to tweak many protocols for how to transport our new unified=20 >service header we'll run into the same issue (i.e., special ethertypes,=20 >special MPLS labels, etc, etc.). > > Ron > > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >Thomas Nadeau >Sent: Friday, September 27, 2013 9:30 AM >To: adrian@olddog.co.uk >Cc: nsc@ietf.org; 'Jim Guichard (jguichar)'; 'NAPIERALA, MARIA H' >Subject: Re: [nsc] New NSC WG Charter > > >On Sep 26, 2013:6:01 PM, at 6:01 PM, "Adrian Farrel" > wrote: > >> I have to pile in here :-( >>=20 >> Maria, I think you want to say "Don't require me to use a=20 >> service-level encapsulation to achieve this function". >> I don't believe you want to say "Allow me to have more than one=20 >> service-level encapsulation to achieve this function." >>=20 >> The text does not in any way preclude having other mechanisms for=20 >>doing stuff. >> In particular, configuring service chains at service nodes is an =20 >>obvious approach. Similarly the service chain information might be =20 >>distributed (ahead of >> time) by some other protocol. >>=20 >> The text does say that there will be at most one service-level=20 >>encapsulation. >> Because setting out to have more than one new encapsulation protocol =20 >>to do the same thing. >>=20 >> Text also says that there will be a service-level encapsulation. >> Why does it do that? >> Because, if this WG goes off and decides to tweak every protocol that=20 >> is out there to make a special way to carry service chain information=20 >> in that protocol, it will be a disaster (IMNSHO). > > Agreed. This is very important to be clear on. > > --Tom > > >>=20 >> If this doesn't address your concern, Maria, perhaps rather than try=20 >> to change the text or comment on what you think the text implies, you=20 >> could say what it is you want to be able to do. That way we can say=20 >> whether it is in or out of scope of the current text. >>=20 >> Thanks, >> Adrian >>=20 >>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>> Of NAPIERALA, MARIA H >>> Sent: 26 September 2013 16:35 >>> To: Jim Guichard (jguichar) >>> Cc: nsc@ietf.org >>> Subject: Re: [nsc] New NSC WG Charter >>>=20 >>> I understand. >>> Why such document is specifically singled out in the charter? Let's=20 >>> leave it >> to the >>> solutions. >>>=20 >>> Maria >>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Thursday, September 26, 2013 10:51 AM >>>> To: NAPIERALA, MARIA H >>>> Cc: nsc@ietf.org >>>> Subject: Re: [nsc] New NSC WG Charter >>>>=20 >>>> That is talking about context information - notice all the *and's*=20 >>>> in the sentence ;-) >>>>=20 >>>> On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: >>>>=20 >>>>> This paragraph is good. >>>>>=20 >>>>> I was pointing out that the item 3 (under "Specifically, the SFC=20 >>>>>WG is chartered to deliver the following" heading) is implying a =20 >>>>>specific solution (which is fine but it should not be the only >>>>>one...): >>>>>=20 >>>>> "3) Generic Service Function Chaining Encapsulation: A document=20 >>>>> will describe the single service-level data plane encapsulation=20 >>>>> format for conveying the service function chain and the service=20 >>>>> function path, >>>> and >>>>> for communicating context information between nodes that implement=20 >>>>> service functions..." >>>>>=20 >>>>>=20 >>>>> Maria >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>> Sent: Thursday, September 26, 2013 10:31 AM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: nsc@ietf.org >>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>=20 >>>>>> Yes and I believe the following text from the charter covers that >>>>>> -> "The Service Function Chaining (SFC) working group will=20 >>>>>> -> develop >>>>>> new approaches to service delivery and deployment. It will=20 >>>>>> produce a framework for service function chaining that includes=20 >>>>>> the necessary protocols or protocol extensions to convey the=20 >>>>>> service path and service path information to nodes that implement=20 >>>>>> service functions, as well as mechanisms for steering traffic=20 >>>>>> through service functions." >>>>>>=20 >>>>>> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: >>>>>>=20 >>>>>>> Jim, >>>>>>>=20 >>>>>>> I said the opposite, i.e., how to carry metadata should be part=20 >>>>>>> of >>>> the >>>>>>> charter but how to carry the metadata should not necessarily >>>> dictate >>>>>> how >>>>>>> the service chain path itself is realized. >>>>>>>=20 >>>>>>> Maria >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Thursday, September 26, 2013 10:13 AM >>>>>>>> To: NAPIERALA, MARIA H; Thomas Narten >>>>>>>> Cc: nsc@ietf.org >>>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>>=20 >>>>>>>> Hi Maria, >>>>>>>>=20 >>>>>>>> Hope you are well. I do not believe the new charter text=20 >>>>>>>> prevents >>>>>> the >>>>>>>> realization of a service chain *without* metadata/context >>>>>> information. >>>>>>>>=20 >>>>>>>> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" wrote: >>>>>>>>=20 >>>>>>>>> I believe the NSC architecture should not preclude the service >>>>>> chain >>>>>>>>> path/topology from being realized with some existing (and >>>> standard >>>>>> ;-) >>>>>>>>> network overlay (=3Dvirtual network) technique. But if the >>>> decision >>>>>> is >>>>>>>> made >>>>>>>>> that it does then this should be clearly stated in the charter. >>>>>>>>> What must be common to the service chain path solutions is,=20 >>>>>>>>> IMO, >>>>>> the >>>>>>>>> method for carrying the metadata/context information. >>>>>>>>>=20 >>>>>>>>> Maria >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Thomas Narten [mailto:narten@us.ibm.com] >>>>>>>>>> Sent: Wednesday, September 25, 2013 5:24 PM >>>>>>>>>> To: NAPIERALA, MARIA H >>>>>>>>>> Cc: Jim Guichard (jguichar); nsc@ietf.org >>>>>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>>>>=20 >>>>>>>>>> "NAPIERALA, MARIA H" writes: >>>>>>>>>>=20 >>>>>>>>>>> The group charter's write-up says that: "The Service >>>> Function >>>>>>>>>>> Chaining (SFC) working group will develop new approaches to >>>>>>>> service >>>>>>>>>>> delivery ..." (i.e., not one "approach" but "approaches", >>>> which >>>>>>>>>>> means more than one). >>>>>>>>>>=20 >>>>>>>>>>> But then is states that a document will be developed such >>>> that >>>>>> it >>>>>>>>>>> "will describe *the(?) single* service-level data plane=20 >>>>>>>>>>> encapsulation format for conveying the service function >>>> chain >>>>>> and >>>>>>>>>>> the service function path associated with data packets, and >>>>>> for >>>>>>>>>>> carrying context information between nodes that implement >>>>>> service >>>>>>>>>>> functions". >>>>>>>>>>=20 >>>>>>>>>>> How to do you reconcile those two statements? >>>>>>>>>>=20 >>>>>>>>>> Note: this inconsistency existed in the earlier charter, I >>>> didn't >>>>>>>>>> introduce it. :-) >>>>>>>>>>=20 >>>>>>>>>> I think for the service plane data encapsulation, we should >>>> aim >>>>>> for >>>>>>>>>> one. I'm understand the concern about writing that into the >>>>>> charter >>>>>>>> in >>>>>>>>>> absolute terms, as I think the WG should have room to discuss >>>> and >>>>>> it >>>>>>>>>> may be too early to be definitive. But unless there is >>>> compelling >>>>>>>>>> reason, we should have one encap. (BTW, nothing new here.. >>>> this >>>>>> is >>>>>>>>>> normal IETF.) >>>>>>>>>>=20 >>>>>>>>>> That said, I don't see the need for more than one encap. Does >>>>>> anyone >>>>>>>>>> think we do? And if so, why? >>>>>>>>>>=20 >>>>>>>>>>> In my opinion, we should open the door for more than one >>>>>> solution >>>>>>>> to >>>>>>>>>>> service chaining. >>>>>>>>>>=20 >>>>>>>>>> Ah, "solution to service chaining" (to me) is more than the >>>>>> encap, >>>>>>>>>> including the control plane and related stuff. So even if we >>>>>> develop >>>>>>>>>> one encap, that doesn't necessarily mean there is only one=20 >>>>>>>>>> "solution". So the inconsistency may not be quite as strong=20 >>>>>>>>>> as >>>>>> first >>>>>>>>>> seems. >>>>>>>>>>=20 >>>>>>>>>> Suggestion. change: >>>>>>>>>>=20 >>>>>>>>>> A document will describe the single service-level data plane=20 >>>>>>>>>> encapsulation format ... >>>>>>>>>>=20 >>>>>>>>>> To: >>>>>>>>>>=20 >>>>>>>>>> A document will describe a service-level data plane >>>>>> encapsulation >>>>>>>>>> format ... >>>>>>>>>>=20 >>>>>>>>>> this is a bit weaker, but still does (implicitely) suggest=20 >>>>>>>>>> one >>>>>>>> encap. >>>>>>>>>>=20 >>>>>>>>>> or, if folk think this is not good enough, we could add text >>>>>> saying >>>>>>>> we >>>>>>>>>> are aiming for one, and will only do more if ... >>>>>>>>>>=20 >>>>>>>>>> But personally, I think it would be fine to have the charter >>>> say >>>>>> one >>>>>>>>>> encap, and if the WG concludes that one encap isn't what is >>>>>> needed, >>>>>>>>>> then recharter. We shouldn't look at rechartering as >>>>>> "impossible". >>>>>>>> We >>>>>>>>>> just need to be able to make the case that more than one=20 >>>>>>>>>> encap >>>> is >>>>>>>>>> necessary. If we can do that, I wouldn't think rechartering >>>> would >>>>>> be >>>>>>>> a >>>>>>>>>> big deal. >>>>>>>>>>=20 >>>>>>>>>> Thomas >>>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >>=20 > From mn1921@att.com Fri Sep 27 07:14: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 4688F11E814F for ; Fri, 27 Sep 2013 07:14:56 -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 IGtbIJv+0m85 for ; Fri, 27 Sep 2013 07:14:50 -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 BB22521F9E6A for ; Fri, 27 Sep 2013 07:14:49 -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 9d295425.2aab05067940.9849116.00-565.27117402.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 27 Sep 2013 14:14:49 +0000 (UTC) X-MXL-Hash: 524592d931b7faa6-39251a56e192fd6d9c40a9b743c1403ccf68eb25 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 7d295425.0.9849106.00-163.27117353.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 27 Sep 2013 14:14:48 +0000 (UTC) X-MXL-Hash: 524592d876b08d42-3da574efe2f2c3ca7bd1ec46311beea1af2ad26a 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 r8REEkZN014448; Fri, 27 Sep 2013 10:14:47 -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 r8REEX8p014273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Sep 2013 10:14:38 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 27 Sep 2013 14:14:18 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.03.0158.001; Fri, 27 Sep 2013 10:14:17 -0400 From: "NAPIERALA, MARIA H" To: Ron Parker , Thomas Nadeau , "adrian@olddog.co.uk" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABuUAgAES7ICAAAQYAIAAARcAgAAEy4CAAADIgIAADB6AgABsDgCAAQOMgP//jWIAgAAGdnA= Date: Fri, 27 Sep 2013 14:14:15 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012A4374@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A3998@MISOUT7MSGUSR9I.ITServices.sbc.com> <028401cebb03$f0431ff0$d0c95fd0$@olddog.co.uk> <4DEFAA61-1964-48FB-A13D-A5A0147FE8DD@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.31.73] 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=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=c0Nk4_4ZelIA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=FFZ-zzI3G] X-AnalysisOut: [zMA:10 a=48vgC7mUAAAA:8 a=AEDFM0qtAAAA:8 a=AUd_NHdVAAAA:8 ] X-AnalysisOut: [a=VnNF1IyMAAAA:8 a=POaBsNWNEr05UvIGBmQA:9 a=CjuIK1q_8ugA:1] X-AnalysisOut: [0 a=lZB815dzVvQA:10 a=jqlaW5bC1iAA:10 a=JfD0Fch1gWkA:10 a=] X-AnalysisOut: [Hz7IrDYlS0cA:10 a=3F6Y6jd7UcuBkiv0:21 a=38ChMn4FZyR_ShEq:2] X-AnalysisOut: [1] Cc: "nsc@ietf.org" , "'Jim Guichard \(jguichar\)'" Subject: Re: [nsc] New NSC 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, 27 Sep 2013 14:14:56 -0000 Ron, > I couldn't agree more that a single service header definition is > necessary to make this effort successful in terms of adoption and > deployment and I support stating that requirement up front, in the > charter. Whether or not the service header is fixed length, variable > length, TLV, AVP, carries this kind of metadata or that, does not have > to be in the charter. I agree. But currently the charter lists some specific pieces of header inf= ormation like service function chain ID and the service function path. IMO,= this should not be part of the charter. This belongs to the solutions.=20 Maria > >=20 >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Thomas Nadeau > Sent: Friday, September 27, 2013 9:30 AM > To: adrian@olddog.co.uk > Cc: nsc@ietf.org; 'Jim Guichard (jguichar)'; 'NAPIERALA, MARIA H' > Subject: Re: [nsc] New NSC WG Charter >=20 >=20 > On Sep 26, 2013:6:01 PM, at 6:01 PM, "Adrian Farrel" > wrote: >=20 > > I have to pile in here :-( > > > > Maria, I think you want to say "Don't require me to use a > > service-level encapsulation to achieve this function". > > I don't believe you want to say "Allow me to have more than one > > service-level encapsulation to achieve this function." > > > > The text does not in any way preclude having other mechanisms for > doing stuff. > > In particular, configuring service chains at service nodes is an > > obvious approach. Similarly the service chain information might be > > distributed (ahead of > > time) by some other protocol. > > > > The text does say that there will be at most one service-level > encapsulation. > > Because setting out to have more than one new encapsulation protocol > > to do the same thing. > > > > Text also says that there will be a service-level encapsulation. > > Why does it do that? > > Because, if this WG goes off and decides to tweak every protocol that > > is out there to make a special way to carry service chain information > > in that protocol, it will be a disaster (IMNSHO). >=20 > Agreed. This is very important to be clear on. >=20 > --Tom >=20 >=20 > > > > If this doesn't address your concern, Maria, perhaps rather than try > > to change the text or comment on what you think the text implies, you > > could say what it is you want to be able to do. That way we can say > > whether it is in or out of scope of the current text. > > > > Thanks, > > Adrian > > > > > >> -----Original Message----- > >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > >> NAPIERALA, MARIA H > >> Sent: 26 September 2013 16:35 > >> To: Jim Guichard (jguichar) > >> Cc: nsc@ietf.org > >> Subject: Re: [nsc] New NSC WG Charter > >> > >> I understand. > >> Why such document is specifically singled out in the charter? Let's > >> leave it > > to the > >> solutions. > >> > >> Maria > >> > >>> -----Original Message----- > >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >>> Sent: Thursday, September 26, 2013 10:51 AM > >>> To: NAPIERALA, MARIA H > >>> Cc: nsc@ietf.org > >>> Subject: Re: [nsc] New NSC WG Charter > >>> > >>> That is talking about context information - notice all the *and's* > >>> in the sentence ;-) > >>> > >>> On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: > >>> > >>>> This paragraph is good. > >>>> > >>>> I was pointing out that the item 3 (under "Specifically, the SFC > WG > >>>> is chartered to deliver the following" heading) is implying a > >>>> specific solution (which is fine but it should not be the only > one...): > >>>> > >>>> "3) Generic Service Function Chaining Encapsulation: A document > >>>> will describe the single service-level data plane encapsulation > >>>> format for conveying the service function chain and the service > >>>> function path, > >>> and > >>>> for communicating context information between nodes that implement > >>>> service functions..." > >>>> > >>>> > >>>> Maria > >>>> > >>>>> -----Original Message----- > >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >>>>> Sent: Thursday, September 26, 2013 10:31 AM > >>>>> To: NAPIERALA, MARIA H > >>>>> Cc: nsc@ietf.org > >>>>> Subject: Re: [nsc] New NSC WG Charter > >>>>> > >>>>> Yes and I believe the following text from the charter covers that > >>>>> -> "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." > >>>>> > >>>>> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: > >>>>> > >>>>>> Jim, > >>>>>> > >>>>>> I said the opposite, i.e., how to carry metadata should be part > >>>>>> of > >>> the > >>>>>> charter but how to carry the metadata should not necessarily > >>> dictate > >>>>> how > >>>>>> the service chain path itself is realized. > >>>>>> > >>>>>> Maria > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >>>>>>> Sent: Thursday, September 26, 2013 10:13 AM > >>>>>>> To: NAPIERALA, MARIA H; Thomas Narten > >>>>>>> Cc: nsc@ietf.org > >>>>>>> Subject: Re: [nsc] New NSC WG Charter > >>>>>>> > >>>>>>> Hi Maria, > >>>>>>> > >>>>>>> Hope you are well. I do not believe the new charter text > >>>>>>> prevents > >>>>> the > >>>>>>> realization of a service chain *without* metadata/context > >>>>> information. > >>>>>>> > >>>>>>> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" > wrote: > >>>>>>> > >>>>>>>> I believe the NSC architecture should not preclude the service > >>>>> chain > >>>>>>>> path/topology from being realized with some existing (and > >>> standard > >>>>> ;-) > >>>>>>>> network overlay (=3Dvirtual network) technique. But if the > >>> decision > >>>>> is > >>>>>>> made > >>>>>>>> that it does then this should be clearly stated in the > charter. > >>>>>>>> What must be common to the service chain path solutions is, > >>>>>>>> IMO, > >>>>> the > >>>>>>>> method for carrying the metadata/context information. > >>>>>>>> > >>>>>>>> Maria > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Thomas Narten [mailto:narten@us.ibm.com] > >>>>>>>>> Sent: Wednesday, September 25, 2013 5:24 PM > >>>>>>>>> To: NAPIERALA, MARIA H > >>>>>>>>> Cc: Jim Guichard (jguichar); nsc@ietf.org > >>>>>>>>> Subject: Re: [nsc] New NSC WG Charter > >>>>>>>>> > >>>>>>>>> "NAPIERALA, MARIA H" writes: > >>>>>>>>> > >>>>>>>>>> The group charter's write-up says that: "The Service > >>> Function > >>>>>>>>>> Chaining (SFC) working group will develop new approaches to > >>>>>>> service > >>>>>>>>>> delivery ..." (i.e., not one "approach" but "approaches", > >>> which > >>>>>>>>>> means more than one). > >>>>>>>>> > >>>>>>>>>> But then is states that a document will be developed such > >>> that > >>>>> it > >>>>>>>>>> "will describe *the(?) single* service-level data plane > >>>>>>>>>> encapsulation format for conveying the service function > >>> chain > >>>>> and > >>>>>>>>>> the service function path associated with data packets, and > >>>>> for > >>>>>>>>>> carrying context information between nodes that implement > >>>>> service > >>>>>>>>>> functions". > >>>>>>>>> > >>>>>>>>>> How to do you reconcile those two statements? > >>>>>>>>> > >>>>>>>>> Note: this inconsistency existed in the earlier charter, I > >>> didn't > >>>>>>>>> introduce it. :-) > >>>>>>>>> > >>>>>>>>> I think for the service plane data encapsulation, we should > >>> aim > >>>>> for > >>>>>>>>> one. I'm understand the concern about writing that into the > >>>>> charter > >>>>>>> in > >>>>>>>>> absolute terms, as I think the WG should have room to discuss > >>> and > >>>>> it > >>>>>>>>> may be too early to be definitive. But unless there is > >>> compelling > >>>>>>>>> reason, we should have one encap. (BTW, nothing new here.. > >>> this > >>>>> is > >>>>>>>>> normal IETF.) > >>>>>>>>> > >>>>>>>>> That said, I don't see the need for more than one encap. Does > >>>>> anyone > >>>>>>>>> think we do? And if so, why? > >>>>>>>>> > >>>>>>>>>> In my opinion, we should open the door for more than one > >>>>> solution > >>>>>>> to > >>>>>>>>>> service chaining. > >>>>>>>>> > >>>>>>>>> Ah, "solution to service chaining" (to me) is more than the > >>>>> encap, > >>>>>>>>> including the control plane and related stuff. So even if we > >>>>> develop > >>>>>>>>> one encap, that doesn't necessarily mean there is only one > >>>>>>>>> "solution". So the inconsistency may not be quite as strong > as > >>>>> first > >>>>>>>>> seems. > >>>>>>>>> > >>>>>>>>> Suggestion. change: > >>>>>>>>> > >>>>>>>>> A document will describe the single service-level data plane > >>>>>>>>> encapsulation format ... > >>>>>>>>> > >>>>>>>>> To: > >>>>>>>>> > >>>>>>>>> A document will describe a service-level data plane > >>>>> encapsulation > >>>>>>>>> format ... > >>>>>>>>> > >>>>>>>>> this is a bit weaker, but still does (implicitely) suggest > one > >>>>>>> encap. > >>>>>>>>> > >>>>>>>>> or, if folk think this is not good enough, we could add text > >>>>> saying > >>>>>>> we > >>>>>>>>> are aiming for one, and will only do more if ... > >>>>>>>>> > >>>>>>>>> But personally, I think it would be fine to have the charter > >>> say > >>>>> one > >>>>>>>>> encap, and if the WG concludes that one encap isn't what is > >>>>> needed, > >>>>>>>>> then recharter. We shouldn't look at rechartering as > >>>>> "impossible". > >>>>>>> We > >>>>>>>>> just need to be able to make the case that more than one > encap > >>> is > >>>>>>>>> necessary. If we can do that, I wouldn't think rechartering > >>> would > >>>>> be > >>>>>>> a > >>>>>>>>> big deal. > >>>>>>>>> > >>>>>>>>> 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 Fri Sep 27 07:26: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 4149221E808A for ; Fri, 27 Sep 2013 07:26:29 -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=[AWL=0.000, 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 1Q4EFAIHltBz for ; Fri, 27 Sep 2013 07:26:21 -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 94C7021E8097 for ; Fri, 27 Sep 2013 07:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11325; q=dns/txt; s=iport; t=1380291981; x=1381501581; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VXWU8+smRt6Ph3sIsmTL+k/uqair41AGl1MhSHXSQn4=; b=J59diAP1FQzsxYagyonSsB7Mi5+4m+xW1xlg4tDBKZlimisd5VRmzkAh G0zcWND5bL0xYgbBjKKd4aLRSgrPCkhS95ek5lrXX4UrLhPQlKqqjSDjP 2R5SWKkH4wDP3dnf8TLykDP6LbXBy1p0YKah7o7A07OTWxkb5KsHuX7E4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAA2VRVKtJV2Z/2dsb2JhbABagwc4UsBLgRwWdIIlAQEBBAEBASQTLQcLDAYBCBEBAwEBAQoUCS4LFAMGCAIEAQ0FCBOHawy6OgSPIDEHBoMXgQEDqXWDJIIq X-IronPort-AV: E=Sophos;i="4.90,993,1371081600"; d="scan'208";a="265325334" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 27 Sep 2013 14:26:20 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8REQKFX021850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 14:26:20 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 09:26:20 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" , Ron Parker , Thomas Nadeau , "adrian@olddog.co.uk" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXSUUAgAAOJgCAAAZxgIAABuUAgADP2YCAAEcrAP//vgYAgABH3ID//723gIAATy+AgABsDgCAAQOMgIAABO+AgAAHV4D//8BMgA== Date: Fri, 27 Sep 2013 14:26:19 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6B5975@xmb-rcd-x01.cisco.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012A4374@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.2.3.120616 x-originating-ip: [10.98.43.181] 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 NSC 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, 27 Sep 2013 14:26:31 -0000 Hi Maria, The charter does not specify "service function chain ID" but rather says "encapsulation format for conveying the service function chain and the service function path" - in other words it does not specify the format of the encapsulation but simply states that it will carry information pertaining to the SFC and SFP. On 9/27/13 10:14 AM, "NAPIERALA, MARIA H" wrote: >Ron, > >> I couldn't agree more that a single service header definition is >> necessary to make this effort successful in terms of adoption and >> deployment and I support stating that requirement up front, in the >> charter. Whether or not the service header is fixed length, variable >> length, TLV, AVP, carries this kind of metadata or that, does not have >> to be in the charter. > >I agree. But currently the charter lists some specific pieces of header >information like service function chain ID and the service function path. >IMO, this should not be part of the charter. This belongs to the >solutions.=20 > >Maria > >> >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Thomas Nadeau >> Sent: Friday, September 27, 2013 9:30 AM >> To: adrian@olddog.co.uk >> Cc: nsc@ietf.org; 'Jim Guichard (jguichar)'; 'NAPIERALA, MARIA H' >> Subject: Re: [nsc] New NSC WG Charter >>=20 >>=20 >> On Sep 26, 2013:6:01 PM, at 6:01 PM, "Adrian Farrel" >> wrote: >>=20 >> > I have to pile in here :-( >> > >> > Maria, I think you want to say "Don't require me to use a >> > service-level encapsulation to achieve this function". >> > I don't believe you want to say "Allow me to have more than one >> > service-level encapsulation to achieve this function." >> > >> > The text does not in any way preclude having other mechanisms for >> doing stuff. >> > In particular, configuring service chains at service nodes is an >> > obvious approach. Similarly the service chain information might be >> > distributed (ahead of >> > time) by some other protocol. >> > >> > The text does say that there will be at most one service-level >> encapsulation. >> > Because setting out to have more than one new encapsulation protocol >> > to do the same thing. >> > >> > Text also says that there will be a service-level encapsulation. >> > Why does it do that? >> > Because, if this WG goes off and decides to tweak every protocol that >> > is out there to make a special way to carry service chain information >> > in that protocol, it will be a disaster (IMNSHO). >>=20 >> Agreed. This is very important to be clear on. >>=20 >> --Tom >>=20 >>=20 >> > >> > If this doesn't address your concern, Maria, perhaps rather than try >> > to change the text or comment on what you think the text implies, you >> > could say what it is you want to be able to do. That way we can say >> > whether it is in or out of scope of the current text. >> > >> > Thanks, >> > Adrian >> > >> > >> >> -----Original Message----- >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >> >> NAPIERALA, MARIA H >> >> Sent: 26 September 2013 16:35 >> >> To: Jim Guichard (jguichar) >> >> Cc: nsc@ietf.org >> >> Subject: Re: [nsc] New NSC WG Charter >> >> >> >> I understand. >> >> Why such document is specifically singled out in the charter? Let's >> >> leave it >> > to the >> >> solutions. >> >> >> >> Maria >> >> >> >>> -----Original Message----- >> >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> >>> Sent: Thursday, September 26, 2013 10:51 AM >> >>> To: NAPIERALA, MARIA H >> >>> Cc: nsc@ietf.org >> >>> Subject: Re: [nsc] New NSC WG Charter >> >>> >> >>> That is talking about context information - notice all the *and's* >> >>> in the sentence ;-) >> >>> >> >>> On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: >> >>> >> >>>> This paragraph is good. >> >>>> >> >>>> I was pointing out that the item 3 (under "Specifically, the SFC >> WG >> >>>> is chartered to deliver the following" heading) is implying a >> >>>> specific solution (which is fine but it should not be the only >> one...): >> >>>> >> >>>> "3) Generic Service Function Chaining Encapsulation: A document >> >>>> will describe the single service-level data plane encapsulation >> >>>> format for conveying the service function chain and the service >> >>>> function path, >> >>> and >> >>>> for communicating context information between nodes that implement >> >>>> service functions..." >> >>>> >> >>>> >> >>>> Maria >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> >>>>> Sent: Thursday, September 26, 2013 10:31 AM >> >>>>> To: NAPIERALA, MARIA H >> >>>>> Cc: nsc@ietf.org >> >>>>> Subject: Re: [nsc] New NSC WG Charter >> >>>>> >> >>>>> Yes and I believe the following text from the charter covers that >> >>>>> -> "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." >> >>>>> >> >>>>> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: >> >>>>> >> >>>>>> Jim, >> >>>>>> >> >>>>>> I said the opposite, i.e., how to carry metadata should be part >> >>>>>> of >> >>> the >> >>>>>> charter but how to carry the metadata should not necessarily >> >>> dictate >> >>>>> how >> >>>>>> the service chain path itself is realized. >> >>>>>> >> >>>>>> Maria >> >>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> >>>>>>> Sent: Thursday, September 26, 2013 10:13 AM >> >>>>>>> To: NAPIERALA, MARIA H; Thomas Narten >> >>>>>>> Cc: nsc@ietf.org >> >>>>>>> Subject: Re: [nsc] New NSC WG Charter >> >>>>>>> >> >>>>>>> Hi Maria, >> >>>>>>> >> >>>>>>> Hope you are well. I do not believe the new charter text >> >>>>>>> prevents >> >>>>> the >> >>>>>>> realization of a service chain *without* metadata/context >> >>>>> information. >> >>>>>>> >> >>>>>>> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" >> wrote: >> >>>>>>> >> >>>>>>>> I believe the NSC architecture should not preclude the service >> >>>>> chain >> >>>>>>>> path/topology from being realized with some existing (and >> >>> standard >> >>>>> ;-) >> >>>>>>>> network overlay (=3Dvirtual network) technique. But if the >> >>> decision >> >>>>> is >> >>>>>>> made >> >>>>>>>> that it does then this should be clearly stated in the >> charter. >> >>>>>>>> What must be common to the service chain path solutions is, >> >>>>>>>> IMO, >> >>>>> the >> >>>>>>>> method for carrying the metadata/context information. >> >>>>>>>> >> >>>>>>>> Maria >> >>>>>>>> >> >>>>>>>>> -----Original Message----- >> >>>>>>>>> From: Thomas Narten [mailto:narten@us.ibm.com] >> >>>>>>>>> Sent: Wednesday, September 25, 2013 5:24 PM >> >>>>>>>>> To: NAPIERALA, MARIA H >> >>>>>>>>> Cc: Jim Guichard (jguichar); nsc@ietf.org >> >>>>>>>>> Subject: Re: [nsc] New NSC WG Charter >> >>>>>>>>> >> >>>>>>>>> "NAPIERALA, MARIA H" writes: >> >>>>>>>>> >> >>>>>>>>>> The group charter's write-up says that: "The Service >> >>> Function >> >>>>>>>>>> Chaining (SFC) working group will develop new approaches to >> >>>>>>> service >> >>>>>>>>>> delivery ..." (i.e., not one "approach" but "approaches", >> >>> which >> >>>>>>>>>> means more than one). >> >>>>>>>>> >> >>>>>>>>>> But then is states that a document will be developed such >> >>> that >> >>>>> it >> >>>>>>>>>> "will describe *the(?) single* service-level data plane >> >>>>>>>>>> encapsulation format for conveying the service function >> >>> chain >> >>>>> and >> >>>>>>>>>> the service function path associated with data packets, and >> >>>>> for >> >>>>>>>>>> carrying context information between nodes that implement >> >>>>> service >> >>>>>>>>>> functions". >> >>>>>>>>> >> >>>>>>>>>> How to do you reconcile those two statements? >> >>>>>>>>> >> >>>>>>>>> Note: this inconsistency existed in the earlier charter, I >> >>> didn't >> >>>>>>>>> introduce it. :-) >> >>>>>>>>> >> >>>>>>>>> I think for the service plane data encapsulation, we should >> >>> aim >> >>>>> for >> >>>>>>>>> one. I'm understand the concern about writing that into the >> >>>>> charter >> >>>>>>> in >> >>>>>>>>> absolute terms, as I think the WG should have room to discuss >> >>> and >> >>>>> it >> >>>>>>>>> may be too early to be definitive. But unless there is >> >>> compelling >> >>>>>>>>> reason, we should have one encap. (BTW, nothing new here.. >> >>> this >> >>>>> is >> >>>>>>>>> normal IETF.) >> >>>>>>>>> >> >>>>>>>>> That said, I don't see the need for more than one encap. Does >> >>>>> anyone >> >>>>>>>>> think we do? And if so, why? >> >>>>>>>>> >> >>>>>>>>>> In my opinion, we should open the door for more than one >> >>>>> solution >> >>>>>>> to >> >>>>>>>>>> service chaining. >> >>>>>>>>> >> >>>>>>>>> Ah, "solution to service chaining" (to me) is more than the >> >>>>> encap, >> >>>>>>>>> including the control plane and related stuff. So even if we >> >>>>> develop >> >>>>>>>>> one encap, that doesn't necessarily mean there is only one >> >>>>>>>>> "solution". So the inconsistency may not be quite as strong >> as >> >>>>> first >> >>>>>>>>> seems. >> >>>>>>>>> >> >>>>>>>>> Suggestion. change: >> >>>>>>>>> >> >>>>>>>>> A document will describe the single service-level data plane >> >>>>>>>>> encapsulation format ... >> >>>>>>>>> >> >>>>>>>>> To: >> >>>>>>>>> >> >>>>>>>>> A document will describe a service-level data plane >> >>>>> encapsulation >> >>>>>>>>> format ... >> >>>>>>>>> >> >>>>>>>>> this is a bit weaker, but still does (implicitely) suggest >> one >> >>>>>>> encap. >> >>>>>>>>> >> >>>>>>>>> or, if folk think this is not good enough, we could add text >> >>>>> saying >> >>>>>>> we >> >>>>>>>>> are aiming for one, and will only do more if ... >> >>>>>>>>> >> >>>>>>>>> But personally, I think it would be fine to have the charter >> >>> say >> >>>>> one >> >>>>>>>>> encap, and if the WG concludes that one encap isn't what is >> >>>>> needed, >> >>>>>>>>> then recharter. We shouldn't look at rechartering as >> >>>>> "impossible". >> >>>>>>> We >> >>>>>>>>> just need to be able to make the case that more than one >> encap >> >>> is >> >>>>>>>>> necessary. If we can do that, I wouldn't think rechartering >> >>> would >> >>>>> be >> >>>>>>> a >> >>>>>>>>> big deal. >> >>>>>>>>> >> >>>>>>>>> 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 Fri Sep 27 07:30: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 0791311E80E9 for ; Fri, 27 Sep 2013 07:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFgpQ-c3wdik for ; Fri, 27 Sep 2013 07:30:45 -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 8CB7111E814D for ; Fri, 27 Sep 2013 07:30:41 -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.0123.003; Fri, 27 Sep 2013 07:30:35 -0700 From: Ron Parker To: "NAPIERALA, MARIA H" , Thomas Nadeau , "adrian@olddog.co.uk" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABuUAgAES7ICAAAQYAIAAARcAgAAEy4CAAADIgIAADB6AgABsDgCAAQOMgP//jWIAgAAGdnCAAAXhsA== Date: Fri, 27 Sep 2013 14:30:34 +0000 Message-ID: References: <1D70D757A2C9D54D83B4CBD7625FA80E012A38B4@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6A12C2@xmb-rcd-x01.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A3998@MISOUT7MSGUSR9I.ITServices.sbc.com> <028401cebb03$f0431ff0$d0c95fd0$@olddog.co.uk> <4DEFAA61-1964-48FB-A13D-A5A0147FE8DD@lucidvision.com> <1D70D757A2C9D54D83B4CBD7625FA80E012A4374@MISOUT7MSGUSR9I.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012A4374@MISOUT7MSGUSR9I.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "'Jim Guichard \(jguichar\)'" Subject: Re: [nsc] New NSC 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, 27 Sep 2013 14:30:50 -0000 Hi, Maria. I do think that a certain baseline of capability in the service header is w= ithin bounds to state as mandatory in the charter. A certain amount of d= ata is required to allow (non-classifying) service nodes to know how to pro= gress the traffic to the next service node, or whether the service node in = question is at the end of the chain. I realize that even this concept is= controversial when evaluated against SDN techniques. But we've also stat= ed that the service nodes must be reachable over arbitrary topologies and n= ot restricted to a single data center, for example.=20 Ron -----Original Message----- From: NAPIERALA, MARIA H [mailto:mn1921@att.com]=20 Sent: Friday, September 27, 2013 10:14 AM To: Ron Parker; Thomas Nadeau; adrian@olddog.co.uk Cc: nsc@ietf.org; 'Jim Guichard (jguichar)' Subject: RE: [nsc] New NSC WG Charter Ron, > I couldn't agree more that a single service header definition is=20 > necessary to make this effort successful in terms of adoption and=20 > deployment and I support stating that requirement up front, in the > charter. Whether or not the service header is fixed length, variable > length, TLV, AVP, carries this kind of metadata or that, does not have=20 > to be in the charter. I agree. But currently the charter lists some specific pieces of header inf= ormation like service function chain ID and the service function path. IMO,= this should not be part of the charter. This belongs to the solutions.=20 Maria > >=20 >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 > Thomas Nadeau > Sent: Friday, September 27, 2013 9:30 AM > To: adrian@olddog.co.uk > Cc: nsc@ietf.org; 'Jim Guichard (jguichar)'; 'NAPIERALA, MARIA H' > Subject: Re: [nsc] New NSC WG Charter >=20 >=20 > On Sep 26, 2013:6:01 PM, at 6:01 PM, "Adrian Farrel" > wrote: >=20 > > I have to pile in here :-( > > > > Maria, I think you want to say "Don't require me to use a=20 > > service-level encapsulation to achieve this function". > > I don't believe you want to say "Allow me to have more than one=20 > > service-level encapsulation to achieve this function." > > > > The text does not in any way preclude having other mechanisms for > doing stuff. > > In particular, configuring service chains at service nodes is an=20 > > obvious approach. Similarly the service chain information might be=20 > > distributed (ahead of > > time) by some other protocol. > > > > The text does say that there will be at most one service-level > encapsulation. > > Because setting out to have more than one new encapsulation protocol=20 > > to do the same thing. > > > > Text also says that there will be a service-level encapsulation. > > Why does it do that? > > Because, if this WG goes off and decides to tweak every protocol=20 > > that is out there to make a special way to carry service chain=20 > > information in that protocol, it will be a disaster (IMNSHO). >=20 > Agreed. This is very important to be clear on. >=20 > --Tom >=20 >=20 > > > > If this doesn't address your concern, Maria, perhaps rather than try=20 > > to change the text or comment on what you think the text implies,=20 > > you could say what it is you want to be able to do. That way we can=20 > > say whether it is in or out of scope of the current text. > > > > Thanks, > > Adrian > > > > > >> -----Original Message----- > >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > >> NAPIERALA, MARIA H > >> Sent: 26 September 2013 16:35 > >> To: Jim Guichard (jguichar) > >> Cc: nsc@ietf.org > >> Subject: Re: [nsc] New NSC WG Charter > >> > >> I understand. > >> Why such document is specifically singled out in the charter? Let's=20 > >> leave it > > to the > >> solutions. > >> > >> Maria > >> > >>> -----Original Message----- > >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >>> Sent: Thursday, September 26, 2013 10:51 AM > >>> To: NAPIERALA, MARIA H > >>> Cc: nsc@ietf.org > >>> Subject: Re: [nsc] New NSC WG Charter > >>> > >>> That is talking about context information - notice all the *and's*=20 > >>> in the sentence ;-) > >>> > >>> On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" wrote: > >>> > >>>> This paragraph is good. > >>>> > >>>> I was pointing out that the item 3 (under "Specifically, the SFC > WG > >>>> is chartered to deliver the following" heading) is implying a=20 > >>>> specific solution (which is fine but it should not be the only > one...): > >>>> > >>>> "3) Generic Service Function Chaining Encapsulation: A document=20 > >>>> will describe the single service-level data plane encapsulation=20 > >>>> format for conveying the service function chain and the service=20 > >>>> function path, > >>> and > >>>> for communicating context information between nodes that=20 > >>>> implement service functions..." > >>>> > >>>> > >>>> Maria > >>>> > >>>>> -----Original Message----- > >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >>>>> Sent: Thursday, September 26, 2013 10:31 AM > >>>>> To: NAPIERALA, MARIA H > >>>>> Cc: nsc@ietf.org > >>>>> Subject: Re: [nsc] New NSC WG Charter > >>>>> > >>>>> Yes and I believe the following text from the charter covers=20 > >>>>> that > >>>>> -> "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=20 > >>>>> necessary protocols or protocol extensions to convey the service=20 > >>>>> path and service path information to nodes that implement=20 > >>>>> service functions, as well as mechanisms for steering traffic=20 > >>>>> through service functions." > >>>>> > >>>>> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" wrote: > >>>>> > >>>>>> Jim, > >>>>>> > >>>>>> I said the opposite, i.e., how to carry metadata should be part=20 > >>>>>> of > >>> the > >>>>>> charter but how to carry the metadata should not necessarily > >>> dictate > >>>>> how > >>>>>> the service chain path itself is realized. > >>>>>> > >>>>>> Maria > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >>>>>>> Sent: Thursday, September 26, 2013 10:13 AM > >>>>>>> To: NAPIERALA, MARIA H; Thomas Narten > >>>>>>> Cc: nsc@ietf.org > >>>>>>> Subject: Re: [nsc] New NSC WG Charter > >>>>>>> > >>>>>>> Hi Maria, > >>>>>>> > >>>>>>> Hope you are well. I do not believe the new charter text=20 > >>>>>>> prevents > >>>>> the > >>>>>>> realization of a service chain *without* metadata/context > >>>>> information. > >>>>>>> > >>>>>>> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" > wrote: > >>>>>>> > >>>>>>>> I believe the NSC architecture should not preclude the=20 > >>>>>>>> service > >>>>> chain > >>>>>>>> path/topology from being realized with some existing (and > >>> standard > >>>>> ;-) > >>>>>>>> network overlay (=3Dvirtual network) technique. But if the > >>> decision > >>>>> is > >>>>>>> made > >>>>>>>> that it does then this should be clearly stated in the > charter. > >>>>>>>> What must be common to the service chain path solutions is,=20 > >>>>>>>> IMO, > >>>>> the > >>>>>>>> method for carrying the metadata/context information. > >>>>>>>> > >>>>>>>> Maria > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Thomas Narten [mailto:narten@us.ibm.com] > >>>>>>>>> Sent: Wednesday, September 25, 2013 5:24 PM > >>>>>>>>> To: NAPIERALA, MARIA H > >>>>>>>>> Cc: Jim Guichard (jguichar); nsc@ietf.org > >>>>>>>>> Subject: Re: [nsc] New NSC WG Charter > >>>>>>>>> > >>>>>>>>> "NAPIERALA, MARIA H" writes: > >>>>>>>>> > >>>>>>>>>> The group charter's write-up says that: "The Service > >>> Function > >>>>>>>>>> Chaining (SFC) working group will develop new approaches to > >>>>>>> service > >>>>>>>>>> delivery ..." (i.e., not one "approach" but "approaches", > >>> which > >>>>>>>>>> means more than one). > >>>>>>>>> > >>>>>>>>>> But then is states that a document will be developed such > >>> that > >>>>> it > >>>>>>>>>> "will describe *the(?) single* service-level data plane=20 > >>>>>>>>>> encapsulation format for conveying the service function > >>> chain > >>>>> and > >>>>>>>>>> the service function path associated with data packets, and > >>>>> for > >>>>>>>>>> carrying context information between nodes that implement > >>>>> service > >>>>>>>>>> functions". > >>>>>>>>> > >>>>>>>>>> How to do you reconcile those two statements? > >>>>>>>>> > >>>>>>>>> Note: this inconsistency existed in the earlier charter, I > >>> didn't > >>>>>>>>> introduce it. :-) > >>>>>>>>> > >>>>>>>>> I think for the service plane data encapsulation, we should > >>> aim > >>>>> for > >>>>>>>>> one. I'm understand the concern about writing that into the > >>>>> charter > >>>>>>> in > >>>>>>>>> absolute terms, as I think the WG should have room to=20 > >>>>>>>>> discuss > >>> and > >>>>> it > >>>>>>>>> may be too early to be definitive. But unless there is > >>> compelling > >>>>>>>>> reason, we should have one encap. (BTW, nothing new here.. > >>> this > >>>>> is > >>>>>>>>> normal IETF.) > >>>>>>>>> > >>>>>>>>> That said, I don't see the need for more than one encap.=20 > >>>>>>>>> Does > >>>>> anyone > >>>>>>>>> think we do? And if so, why? > >>>>>>>>> > >>>>>>>>>> In my opinion, we should open the door for more than one > >>>>> solution > >>>>>>> to > >>>>>>>>>> service chaining. > >>>>>>>>> > >>>>>>>>> Ah, "solution to service chaining" (to me) is more than the > >>>>> encap, > >>>>>>>>> including the control plane and related stuff. So even if we > >>>>> develop > >>>>>>>>> one encap, that doesn't necessarily mean there is only one=20 > >>>>>>>>> "solution". So the inconsistency may not be quite as strong > as > >>>>> first > >>>>>>>>> seems. > >>>>>>>>> > >>>>>>>>> Suggestion. change: > >>>>>>>>> > >>>>>>>>> A document will describe the single service-level data plane=20 > >>>>>>>>> encapsulation format ... > >>>>>>>>> > >>>>>>>>> To: > >>>>>>>>> > >>>>>>>>> A document will describe a service-level data plane > >>>>> encapsulation > >>>>>>>>> format ... > >>>>>>>>> > >>>>>>>>> this is a bit weaker, but still does (implicitely) suggest > one > >>>>>>> encap. > >>>>>>>>> > >>>>>>>>> or, if folk think this is not good enough, we could add text > >>>>> saying > >>>>>>> we > >>>>>>>>> are aiming for one, and will only do more if ... > >>>>>>>>> > >>>>>>>>> But personally, I think it would be fine to have the charter > >>> say > >>>>> one > >>>>>>>>> encap, and if the WG concludes that one encap isn't what is > >>>>> needed, > >>>>>>>>> then recharter. We shouldn't look at rechartering as > >>>>> "impossible". > >>>>>>> We > >>>>>>>>> just need to be able to make the case that more than one > encap > >>> is > >>>>>>>>> necessary. If we can do that, I wouldn't think rechartering > >>> would > >>>>> be > >>>>>>> a > >>>>>>>>> big deal. > >>>>>>>>> > >>>>>>>>> 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 mn1921@att.com Fri Sep 27 07:34: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 9A65621F9FED for ; Fri, 27 Sep 2013 07:34:35 -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 vhJdEIGX749A for ; Fri, 27 Sep 2013 07:34:29 -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 D283D21F9E26 for ; Fri, 27 Sep 2013 07:34:21 -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 d6795425.2aaaed441940.9861986.00-545.27154077.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 27 Sep 2013 14:34:21 +0000 (UTC) X-MXL-Hash: 5245976d0b17d6b7-4e297ee059c035d20eb775adc8f14cff718f4ead 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 c6795425.0.9861976.00-081.27154020.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 27 Sep 2013 14:34:21 +0000 (UTC) X-MXL-Hash: 5245976d42ddb7e6-a97b01766c5d8e17294b1ba33656cdef2dac7fcd 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 r8REYIAk008150; Fri, 27 Sep 2013 10:34:19 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8REY1P0007875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Sep 2013 10:34:13 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 27 Sep 2013 14:33:47 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, 27 Sep 2013 10:33:46 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , Ron Parker , Thomas Nadeau , "adrian@olddog.co.uk" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnXaswAgAAOJgCAAAZxgIAABuUAgAES7ICAAAQYAIAAARcAgAAEy4CAAADIgIAADB6AgABsDgCAAQOMgP//jWIAgAAGdnCAAEmDgP//vXWw Date: Fri, 27 Sep 2013 14:33:46 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012A43EE@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <1D70D757A2C9D54D83B4CBD7625FA80E012A4374@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F6B5975@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6B5975@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.31.73] 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=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=c0Nk4_4ZelIA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=FFZ-zzI3G] X-AnalysisOut: [zMA:10 a=AUd_NHdVAAAA:8 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=VnNF1IyMAAAA:8 a=WSPQUueikSNa_GgoD7QA:9 a=CjuIK1q_8ugA:1] X-AnalysisOut: [0 a=JfD0Fch1gWkA:10 a=jqlaW5bC1iAA:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [Hz7IrDYlS0cA:10 a=fH6C96bqzU1G97Rh:21 a=FoTN1RSOCB0YIacl:2] X-AnalysisOut: [1] Cc: "nsc@ietf.org" Subject: Re: [nsc] New NSC 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, 27 Sep 2013 14:34:35 -0000 Jim, there might be solutions where such information is not needed to be carried= in the data plane.=20 So, what I am proposing is not to list it explicitly in the charter. Maria > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Friday, September 27, 2013 10:26 AM > To: NAPIERALA, MARIA H; Ron Parker; Thomas Nadeau; adrian@olddog.co.uk > Cc: nsc@ietf.org > Subject: Re: [nsc] New NSC WG Charter >=20 > Hi Maria, >=20 > The charter does not specify "service function chain ID" but rather > says > "encapsulation format for conveying the service function chain and the > service function path" - in other words it does not specify the format > of > the encapsulation but simply states that it will carry information > pertaining to the SFC and SFP. >=20 > On 9/27/13 10:14 AM, "NAPIERALA, MARIA H" wrote: >=20 > >Ron, > > > >> I couldn't agree more that a single service header definition is > >> necessary to make this effort successful in terms of adoption and > >> deployment and I support stating that requirement up front, in the > >> charter. Whether or not the service header is fixed length, > variable > >> length, TLV, AVP, carries this kind of metadata or that, does not > have > >> to be in the charter. > > > >I agree. But currently the charter lists some specific pieces of > header > >information like service function chain ID and the service function > path. > >IMO, this should not be part of the charter. This belongs to the > >solutions. > > > >Maria > > > >> > >> > >> > >> -----Original Message----- > >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > >> Thomas Nadeau > >> Sent: Friday, September 27, 2013 9:30 AM > >> To: adrian@olddog.co.uk > >> Cc: nsc@ietf.org; 'Jim Guichard (jguichar)'; 'NAPIERALA, MARIA H' > >> Subject: Re: [nsc] New NSC WG Charter > >> > >> > >> On Sep 26, 2013:6:01 PM, at 6:01 PM, "Adrian Farrel" > >> wrote: > >> > >> > I have to pile in here :-( > >> > > >> > Maria, I think you want to say "Don't require me to use a > >> > service-level encapsulation to achieve this function". > >> > I don't believe you want to say "Allow me to have more than one > >> > service-level encapsulation to achieve this function." > >> > > >> > The text does not in any way preclude having other mechanisms for > >> doing stuff. > >> > In particular, configuring service chains at service nodes is an > >> > obvious approach. Similarly the service chain information might be > >> > distributed (ahead of > >> > time) by some other protocol. > >> > > >> > The text does say that there will be at most one service-level > >> encapsulation. > >> > Because setting out to have more than one new encapsulation > protocol > >> > to do the same thing. > >> > > >> > Text also says that there will be a service-level encapsulation. > >> > Why does it do that? > >> > Because, if this WG goes off and decides to tweak every protocol > that > >> > is out there to make a special way to carry service chain > information > >> > in that protocol, it will be a disaster (IMNSHO). > >> > >> Agreed. This is very important to be clear on. > >> > >> --Tom > >> > >> > >> > > >> > If this doesn't address your concern, Maria, perhaps rather than > try > >> > to change the text or comment on what you think the text implies, > you > >> > could say what it is you want to be able to do. That way we can > say > >> > whether it is in or out of scope of the current text. > >> > > >> > Thanks, > >> > Adrian > >> > > >> > > >> >> -----Original Message----- > >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > Behalf > >> Of > >> >> NAPIERALA, MARIA H > >> >> Sent: 26 September 2013 16:35 > >> >> To: Jim Guichard (jguichar) > >> >> Cc: nsc@ietf.org > >> >> Subject: Re: [nsc] New NSC WG Charter > >> >> > >> >> I understand. > >> >> Why such document is specifically singled out in the charter? > Let's > >> >> leave it > >> > to the > >> >> solutions. > >> >> > >> >> Maria > >> >> > >> >>> -----Original Message----- > >> >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> >>> Sent: Thursday, September 26, 2013 10:51 AM > >> >>> To: NAPIERALA, MARIA H > >> >>> Cc: nsc@ietf.org > >> >>> Subject: Re: [nsc] New NSC WG Charter > >> >>> > >> >>> That is talking about context information - notice all the > *and's* > >> >>> in the sentence ;-) > >> >>> > >> >>> On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" > wrote: > >> >>> > >> >>>> This paragraph is good. > >> >>>> > >> >>>> I was pointing out that the item 3 (under "Specifically, the > SFC > >> WG > >> >>>> is chartered to deliver the following" heading) is implying a > >> >>>> specific solution (which is fine but it should not be the only > >> one...): > >> >>>> > >> >>>> "3) Generic Service Function Chaining Encapsulation: A document > >> >>>> will describe the single service-level data plane encapsulation > >> >>>> format for conveying the service function chain and the service > >> >>>> function path, > >> >>> and > >> >>>> for communicating context information between nodes that > implement > >> >>>> service functions..." > >> >>>> > >> >>>> > >> >>>> Maria > >> >>>> > >> >>>>> -----Original Message----- > >> >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> >>>>> Sent: Thursday, September 26, 2013 10:31 AM > >> >>>>> To: NAPIERALA, MARIA H > >> >>>>> Cc: nsc@ietf.org > >> >>>>> Subject: Re: [nsc] New NSC WG Charter > >> >>>>> > >> >>>>> Yes and I believe the following text from the charter covers > that > >> >>>>> -> "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." > >> >>>>> > >> >>>>> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" > wrote: > >> >>>>> > >> >>>>>> Jim, > >> >>>>>> > >> >>>>>> I said the opposite, i.e., how to carry metadata should be > part > >> >>>>>> of > >> >>> the > >> >>>>>> charter but how to carry the metadata should not necessarily > >> >>> dictate > >> >>>>> how > >> >>>>>> the service chain path itself is realized. > >> >>>>>> > >> >>>>>> Maria > >> >>>>>> > >> >>>>>>> -----Original Message----- > >> >>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> >>>>>>> Sent: Thursday, September 26, 2013 10:13 AM > >> >>>>>>> To: NAPIERALA, MARIA H; Thomas Narten > >> >>>>>>> Cc: nsc@ietf.org > >> >>>>>>> Subject: Re: [nsc] New NSC WG Charter > >> >>>>>>> > >> >>>>>>> Hi Maria, > >> >>>>>>> > >> >>>>>>> Hope you are well. I do not believe the new charter text > >> >>>>>>> prevents > >> >>>>> the > >> >>>>>>> realization of a service chain *without* metadata/context > >> >>>>> information. > >> >>>>>>> > >> >>>>>>> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" > >> wrote: > >> >>>>>>> > >> >>>>>>>> I believe the NSC architecture should not preclude the > service > >> >>>>> chain > >> >>>>>>>> path/topology from being realized with some existing (and > >> >>> standard > >> >>>>> ;-) > >> >>>>>>>> network overlay (=3Dvirtual network) technique. But if the > >> >>> decision > >> >>>>> is > >> >>>>>>> made > >> >>>>>>>> that it does then this should be clearly stated in the > >> charter. > >> >>>>>>>> What must be common to the service chain path solutions is, > >> >>>>>>>> IMO, > >> >>>>> the > >> >>>>>>>> method for carrying the metadata/context information. > >> >>>>>>>> > >> >>>>>>>> Maria > >> >>>>>>>> > >> >>>>>>>>> -----Original Message----- > >> >>>>>>>>> From: Thomas Narten [mailto:narten@us.ibm.com] > >> >>>>>>>>> Sent: Wednesday, September 25, 2013 5:24 PM > >> >>>>>>>>> To: NAPIERALA, MARIA H > >> >>>>>>>>> Cc: Jim Guichard (jguichar); nsc@ietf.org > >> >>>>>>>>> Subject: Re: [nsc] New NSC WG Charter > >> >>>>>>>>> > >> >>>>>>>>> "NAPIERALA, MARIA H" writes: > >> >>>>>>>>> > >> >>>>>>>>>> The group charter's write-up says that: "The Service > >> >>> Function > >> >>>>>>>>>> Chaining (SFC) working group will develop new approaches > to > >> >>>>>>> service > >> >>>>>>>>>> delivery ..." (i.e., not one "approach" but "approaches", > >> >>> which > >> >>>>>>>>>> means more than one). > >> >>>>>>>>> > >> >>>>>>>>>> But then is states that a document will be developed such > >> >>> that > >> >>>>> it > >> >>>>>>>>>> "will describe *the(?) single* service-level data plane > >> >>>>>>>>>> encapsulation format for conveying the service function > >> >>> chain > >> >>>>> and > >> >>>>>>>>>> the service function path associated with data packets, > and > >> >>>>> for > >> >>>>>>>>>> carrying context information between nodes that implement > >> >>>>> service > >> >>>>>>>>>> functions". > >> >>>>>>>>> > >> >>>>>>>>>> How to do you reconcile those two statements? > >> >>>>>>>>> > >> >>>>>>>>> Note: this inconsistency existed in the earlier charter, I > >> >>> didn't > >> >>>>>>>>> introduce it. :-) > >> >>>>>>>>> > >> >>>>>>>>> I think for the service plane data encapsulation, we > should > >> >>> aim > >> >>>>> for > >> >>>>>>>>> one. I'm understand the concern about writing that into > the > >> >>>>> charter > >> >>>>>>> in > >> >>>>>>>>> absolute terms, as I think the WG should have room to > discuss > >> >>> and > >> >>>>> it > >> >>>>>>>>> may be too early to be definitive. But unless there is > >> >>> compelling > >> >>>>>>>>> reason, we should have one encap. (BTW, nothing new here.. > >> >>> this > >> >>>>> is > >> >>>>>>>>> normal IETF.) > >> >>>>>>>>> > >> >>>>>>>>> That said, I don't see the need for more than one encap. > Does > >> >>>>> anyone > >> >>>>>>>>> think we do? And if so, why? > >> >>>>>>>>> > >> >>>>>>>>>> In my opinion, we should open the door for more than one > >> >>>>> solution > >> >>>>>>> to > >> >>>>>>>>>> service chaining. > >> >>>>>>>>> > >> >>>>>>>>> Ah, "solution to service chaining" (to me) is more than > the > >> >>>>> encap, > >> >>>>>>>>> including the control plane and related stuff. So even if > we > >> >>>>> develop > >> >>>>>>>>> one encap, that doesn't necessarily mean there is only one > >> >>>>>>>>> "solution". So the inconsistency may not be quite as > strong > >> as > >> >>>>> first > >> >>>>>>>>> seems. > >> >>>>>>>>> > >> >>>>>>>>> Suggestion. change: > >> >>>>>>>>> > >> >>>>>>>>> A document will describe the single service-level data > plane > >> >>>>>>>>> encapsulation format ... > >> >>>>>>>>> > >> >>>>>>>>> To: > >> >>>>>>>>> > >> >>>>>>>>> A document will describe a service-level data plane > >> >>>>> encapsulation > >> >>>>>>>>> format ... > >> >>>>>>>>> > >> >>>>>>>>> this is a bit weaker, but still does (implicitely) suggest > >> one > >> >>>>>>> encap. > >> >>>>>>>>> > >> >>>>>>>>> or, if folk think this is not good enough, we could add > text > >> >>>>> saying > >> >>>>>>> we > >> >>>>>>>>> are aiming for one, and will only do more if ... > >> >>>>>>>>> > >> >>>>>>>>> But personally, I think it would be fine to have the > charter > >> >>> say > >> >>>>> one > >> >>>>>>>>> encap, and if the WG concludes that one encap isn't what > is > >> >>>>> needed, > >> >>>>>>>>> then recharter. We shouldn't look at rechartering as > >> >>>>> "impossible". > >> >>>>>>> We > >> >>>>>>>>> just need to be able to make the case that more than one > >> encap > >> >>> is > >> >>>>>>>>> necessary. If we can do that, I wouldn't think > rechartering > >> >>> would > >> >>>>> be > >> >>>>>>> a > >> >>>>>>>>> big deal. > >> >>>>>>>>> > >> >>>>>>>>> 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 Fri Sep 27 08:13: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 ABF9821F9EAD for ; Fri, 27 Sep 2013 08:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 4zYjC4mR42tj for ; Fri, 27 Sep 2013 08:13:24 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id C793621F9EDB for ; Fri, 27 Sep 2013 08:13:24 -0700 (PDT) Received: from mail100-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE027.bigfish.com (10.243.66.90) with Microsoft SMTP Server id 14.1.225.22; Fri, 27 Sep 2013 15:13:24 +0000 Received: from mail100-co1 (localhost [127.0.0.1]) by mail100-co1-R.bigfish.com (Postfix) with ESMTP id 3909E9C032E; Fri, 27 Sep 2013 15:13:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371I542I1dbaI1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail100-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(164054003)(76104003)(51704005)(479174003)(377454003)(199002)(189002)(13464003)(76176001)(83072001)(79102001)(81542001)(74366001)(54356001)(77982001)(65816001)(36756003)(56776001)(76796001)(76786001)(54316002)(59766001)(81342001)(77096001)(56816003)(53806001)(80022001)(81816001)(76482001)(81686001)(47976001)(83506001)(69226001)(19580395003)(83322001)(80976001)(47736001)(19580405001)(74706001)(50986001)(15975445006)(74502001)(74876001)(63696002)(31966008)(4396001)(46102001)(51856001)(74662001)(49866001)(47446002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB082; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail100-co1 (localhost.localdomain [127.0.0.1]) by mail100-co1 (MessageSwitch) id 1380294802146825_29112; Fri, 27 Sep 2013 15:13:22 +0000 (UTC) Received: from CO1EHSMHS008.bigfish.com (unknown [10.243.78.240]) by mail100-co1.bigfish.com (Postfix) with ESMTP id 1623720061; Fri, 27 Sep 2013 15:13:22 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS008.bigfish.com (10.243.66.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 27 Sep 2013 15:13:22 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.359.1; Fri, 27 Sep 2013 15:13:16 +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.775.9; Fri, 27 Sep 2013 15:13:15 +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.0775.005; Fri, 27 Sep 2013 15:13:15 +0000 From: Ken Gray To: "NAPIERALA, MARIA H" , "Jim Guichard (jguichar)" , Ron Parker , Thomas Nadeau , "adrian@olddog.co.uk" Thread-Topic: [nsc] New NSC WG Charter Thread-Index: AQHOsIqpjNDm9Ck3Z02ziiq2gsI2IpnW9XQAgAAOJQCAAAZxgIAABuUAgAES7ICAAAQYAIAAARcAgAAEy4CAAADIgIAADB6AgABsDgCAAQOMgIAABPCAgAAHVoCAAANggIAAAhQA///H6wA= Date: Fri, 27 Sep 2013 15:13:14 +0000 Message-ID: In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012A43EE@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: 098291215C Content-Type: text/plain; charset="us-ascii" Content-ID: <1FDFF0AFAB7C5F49AAB67D49AB083CEB@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] New NSC 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, 27 Sep 2013 15:13:29 -0000 I would propose that we work out that detail in the WG and not the charter. The charter isn't supposed to work out all the use cases. The consensus seems (to me) that passing the information listed in the charter is valuable (at least in some cases) as part and parcel of building service chains and we therefor do need a header. I think the WG docs can take up "transparency" of the header that passes that information (you can always ignore it, but the idea is multi-vendor interop) and the format of that header (even if it's the NULL set of what is listed in the charter). On 9/27/13 10:33 AM, "NAPIERALA, MARIA H" wrote: >Jim, > >there might be solutions where such information is not needed to be >carried in the data plane. >So, what I am proposing is not to list it explicitly in the charter. > >Maria > >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Friday, September 27, 2013 10:26 AM >> To: NAPIERALA, MARIA H; Ron Parker; Thomas Nadeau; adrian@olddog.co.uk >> Cc: nsc@ietf.org >> Subject: Re: [nsc] New NSC WG Charter >>=20 >> Hi Maria, >>=20 >> The charter does not specify "service function chain ID" but rather >> says >> "encapsulation format for conveying the service function chain and the >> service function path" - in other words it does not specify the format >> of >> the encapsulation but simply states that it will carry information >> pertaining to the SFC and SFP. >>=20 >> On 9/27/13 10:14 AM, "NAPIERALA, MARIA H" wrote: >>=20 >> >Ron, >> > >> >> I couldn't agree more that a single service header definition is >> >> necessary to make this effort successful in terms of adoption and >> >> deployment and I support stating that requirement up front, in the >> >> charter. Whether or not the service header is fixed length, >> variable >> >> length, TLV, AVP, carries this kind of metadata or that, does not >> have >> >> to be in the charter. >> > >> >I agree. But currently the charter lists some specific pieces of >> header >> >information like service function chain ID and the service function >> path. >> >IMO, this should not be part of the charter. This belongs to the >> >solutions. >> > >> >Maria >> > >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >> >> Thomas Nadeau >> >> Sent: Friday, September 27, 2013 9:30 AM >> >> To: adrian@olddog.co.uk >> >> Cc: nsc@ietf.org; 'Jim Guichard (jguichar)'; 'NAPIERALA, MARIA H' >> >> Subject: Re: [nsc] New NSC WG Charter >> >> >> >> >> >> On Sep 26, 2013:6:01 PM, at 6:01 PM, "Adrian Farrel" >> >> wrote: >> >> >> >> > I have to pile in here :-( >> >> > >> >> > Maria, I think you want to say "Don't require me to use a >> >> > service-level encapsulation to achieve this function". >> >> > I don't believe you want to say "Allow me to have more than one >> >> > service-level encapsulation to achieve this function." >> >> > >> >> > The text does not in any way preclude having other mechanisms for >> >> doing stuff. >> >> > In particular, configuring service chains at service nodes is an >> >> > obvious approach. Similarly the service chain information might be >> >> > distributed (ahead of >> >> > time) by some other protocol. >> >> > >> >> > The text does say that there will be at most one service-level >> >> encapsulation. >> >> > Because setting out to have more than one new encapsulation >> protocol >> >> > to do the same thing. >> >> > >> >> > Text also says that there will be a service-level encapsulation. >> >> > Why does it do that? >> >> > Because, if this WG goes off and decides to tweak every protocol >> that >> >> > is out there to make a special way to carry service chain >> information >> >> > in that protocol, it will be a disaster (IMNSHO). >> >> >> >> Agreed. This is very important to be clear on. >> >> >> >> --Tom >> >> >> >> >> >> > >> >> > If this doesn't address your concern, Maria, perhaps rather than >> try >> >> > to change the text or comment on what you think the text implies, >> you >> >> > could say what it is you want to be able to do. That way we can >> say >> >> > whether it is in or out of scope of the current text. >> >> > >> >> > Thanks, >> >> > Adrian >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> Behalf >> >> Of >> >> >> NAPIERALA, MARIA H >> >> >> Sent: 26 September 2013 16:35 >> >> >> To: Jim Guichard (jguichar) >> >> >> Cc: nsc@ietf.org >> >> >> Subject: Re: [nsc] New NSC WG Charter >> >> >> >> >> >> I understand. >> >> >> Why such document is specifically singled out in the charter? >> Let's >> >> >> leave it >> >> > to the >> >> >> solutions. >> >> >> >> >> >> Maria >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> >> >>> Sent: Thursday, September 26, 2013 10:51 AM >> >> >>> To: NAPIERALA, MARIA H >> >> >>> Cc: nsc@ietf.org >> >> >>> Subject: Re: [nsc] New NSC WG Charter >> >> >>> >> >> >>> That is talking about context information - notice all the >> *and's* >> >> >>> in the sentence ;-) >> >> >>> >> >> >>> On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" >> wrote: >> >> >>> >> >> >>>> This paragraph is good. >> >> >>>> >> >> >>>> I was pointing out that the item 3 (under "Specifically, the >> SFC >> >> WG >> >> >>>> is chartered to deliver the following" heading) is implying a >> >> >>>> specific solution (which is fine but it should not be the only >> >> one...): >> >> >>>> >> >> >>>> "3) Generic Service Function Chaining Encapsulation: A document >> >> >>>> will describe the single service-level data plane encapsulation >> >> >>>> format for conveying the service function chain and the service >> >> >>>> function path, >> >> >>> and >> >> >>>> for communicating context information between nodes that >> implement >> >> >>>> service functions..." >> >> >>>> >> >> >>>> >> >> >>>> Maria >> >> >>>> >> >> >>>>> -----Original Message----- >> >> >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> >> >>>>> Sent: Thursday, September 26, 2013 10:31 AM >> >> >>>>> To: NAPIERALA, MARIA H >> >> >>>>> Cc: nsc@ietf.org >> >> >>>>> Subject: Re: [nsc] New NSC WG Charter >> >> >>>>> >> >> >>>>> Yes and I believe the following text from the charter covers >> that >> >> >>>>> -> "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." >> >> >>>>> >> >> >>>>> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" >> wrote: >> >> >>>>> >> >> >>>>>> Jim, >> >> >>>>>> >> >> >>>>>> I said the opposite, i.e., how to carry metadata should be >> part >> >> >>>>>> of >> >> >>> the >> >> >>>>>> charter but how to carry the metadata should not necessarily >> >> >>> dictate >> >> >>>>> how >> >> >>>>>> the service chain path itself is realized. >> >> >>>>>> >> >> >>>>>> Maria >> >> >>>>>> >> >> >>>>>>> -----Original Message----- >> >> >>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> >> >>>>>>> Sent: Thursday, September 26, 2013 10:13 AM >> >> >>>>>>> To: NAPIERALA, MARIA H; Thomas Narten >> >> >>>>>>> Cc: nsc@ietf.org >> >> >>>>>>> Subject: Re: [nsc] New NSC WG Charter >> >> >>>>>>> >> >> >>>>>>> Hi Maria, >> >> >>>>>>> >> >> >>>>>>> Hope you are well. I do not believe the new charter text >> >> >>>>>>> prevents >> >> >>>>> the >> >> >>>>>>> realization of a service chain *without* metadata/context >> >> >>>>> information. >> >> >>>>>>> >> >> >>>>>>> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" >> >> wrote: >> >> >>>>>>> >> >> >>>>>>>> I believe the NSC architecture should not preclude the >> service >> >> >>>>> chain >> >> >>>>>>>> path/topology from being realized with some existing (and >> >> >>> standard >> >> >>>>> ;-) >> >> >>>>>>>> network overlay (=3Dvirtual network) technique. But if the >> >> >>> decision >> >> >>>>> is >> >> >>>>>>> made >> >> >>>>>>>> that it does then this should be clearly stated in the >> >> charter. >> >> >>>>>>>> What must be common to the service chain path solutions is, >> >> >>>>>>>> IMO, >> >> >>>>> the >> >> >>>>>>>> method for carrying the metadata/context information. >> >> >>>>>>>> >> >> >>>>>>>> Maria >> >> >>>>>>>> >> >> >>>>>>>>> -----Original Message----- >> >> >>>>>>>>> From: Thomas Narten [mailto:narten@us.ibm.com] >> >> >>>>>>>>> Sent: Wednesday, September 25, 2013 5:24 PM >> >> >>>>>>>>> To: NAPIERALA, MARIA H >> >> >>>>>>>>> Cc: Jim Guichard (jguichar); nsc@ietf.org >> >> >>>>>>>>> Subject: Re: [nsc] New NSC WG Charter >> >> >>>>>>>>> >> >> >>>>>>>>> "NAPIERALA, MARIA H" writes: >> >> >>>>>>>>> >> >> >>>>>>>>>> The group charter's write-up says that: "The Service >> >> >>> Function >> >> >>>>>>>>>> Chaining (SFC) working group will develop new approaches >> to >> >> >>>>>>> service >> >> >>>>>>>>>> delivery ..." (i.e., not one "approach" but "approaches", >> >> >>> which >> >> >>>>>>>>>> means more than one). >> >> >>>>>>>>> >> >> >>>>>>>>>> But then is states that a document will be developed such >> >> >>> that >> >> >>>>> it >> >> >>>>>>>>>> "will describe *the(?) single* service-level data plane >> >> >>>>>>>>>> encapsulation format for conveying the service function >> >> >>> chain >> >> >>>>> and >> >> >>>>>>>>>> the service function path associated with data packets, >> and >> >> >>>>> for >> >> >>>>>>>>>> carrying context information between nodes that implement >> >> >>>>> service >> >> >>>>>>>>>> functions". >> >> >>>>>>>>> >> >> >>>>>>>>>> How to do you reconcile those two statements? >> >> >>>>>>>>> >> >> >>>>>>>>> Note: this inconsistency existed in the earlier charter, I >> >> >>> didn't >> >> >>>>>>>>> introduce it. :-) >> >> >>>>>>>>> >> >> >>>>>>>>> I think for the service plane data encapsulation, we >> should >> >> >>> aim >> >> >>>>> for >> >> >>>>>>>>> one. I'm understand the concern about writing that into >> the >> >> >>>>> charter >> >> >>>>>>> in >> >> >>>>>>>>> absolute terms, as I think the WG should have room to >> discuss >> >> >>> and >> >> >>>>> it >> >> >>>>>>>>> may be too early to be definitive. But unless there is >> >> >>> compelling >> >> >>>>>>>>> reason, we should have one encap. (BTW, nothing new here.. >> >> >>> this >> >> >>>>> is >> >> >>>>>>>>> normal IETF.) >> >> >>>>>>>>> >> >> >>>>>>>>> That said, I don't see the need for more than one encap. >> Does >> >> >>>>> anyone >> >> >>>>>>>>> think we do? And if so, why? >> >> >>>>>>>>> >> >> >>>>>>>>>> In my opinion, we should open the door for more than one >> >> >>>>> solution >> >> >>>>>>> to >> >> >>>>>>>>>> service chaining. >> >> >>>>>>>>> >> >> >>>>>>>>> Ah, "solution to service chaining" (to me) is more than >> the >> >> >>>>> encap, >> >> >>>>>>>>> including the control plane and related stuff. So even if >> we >> >> >>>>> develop >> >> >>>>>>>>> one encap, that doesn't necessarily mean there is only one >> >> >>>>>>>>> "solution". So the inconsistency may not be quite as >> strong >> >> as >> >> >>>>> first >> >> >>>>>>>>> seems. >> >> >>>>>>>>> >> >> >>>>>>>>> Suggestion. change: >> >> >>>>>>>>> >> >> >>>>>>>>> A document will describe the single service-level data >> plane >> >> >>>>>>>>> encapsulation format ... >> >> >>>>>>>>> >> >> >>>>>>>>> To: >> >> >>>>>>>>> >> >> >>>>>>>>> A document will describe a service-level data plane >> >> >>>>> encapsulation >> >> >>>>>>>>> format ... >> >> >>>>>>>>> >> >> >>>>>>>>> this is a bit weaker, but still does (implicitely) suggest >> >> one >> >> >>>>>>> encap. >> >> >>>>>>>>> >> >> >>>>>>>>> or, if folk think this is not good enough, we could add >> text >> >> >>>>> saying >> >> >>>>>>> we >> >> >>>>>>>>> are aiming for one, and will only do more if ... >> >> >>>>>>>>> >> >> >>>>>>>>> But personally, I think it would be fine to have the >> charter >> >> >>> say >> >> >>>>> one >> >> >>>>>>>>> encap, and if the WG concludes that one encap isn't what >> is >> >> >>>>> needed, >> >> >>>>>>>>> then recharter. We shouldn't look at rechartering as >> >> >>>>> "impossible". >> >> >>>>>>> We >> >> >>>>>>>>> just need to be able to make the case that more than one >> >> encap >> >> >>> is >> >> >>>>>>>>> necessary. If we can do that, I wouldn't think >> rechartering >> >> >>> would >> >> >>>>> be >> >> >>>>>>> a >> >> >>>>>>>>> big deal. >> >> >>>>>>>>> >> >> >>>>>>>>> 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 tnadeau@lucidvision.com Fri Sep 27 08:26: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 5E62C11E80E7 for ; Fri, 27 Sep 2013 08:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 bPZPmpIylyHU for ; Fri, 27 Sep 2013 08:26:50 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3F921F9F5B for ; Fri, 27 Sep 2013 08:26:49 -0700 (PDT) Received: from [192.168.1.100] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id CDB43258686F; Fri, 27 Sep 2013 11:26:48 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_BDF246C1-F20C-4CA8-A743-36B4713647AF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 27 Sep 2013 11:26:48 -0400 Message-Id: References: To: Ken Gray X-Mailer: Apple Mail (2.1510) Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Ron Parker , "NAPIERALA, MARIA H" , "adrian@olddog.co.uk" Subject: Re: [nsc] New NSC 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, 27 Sep 2013 15:26:55 -0000 --Apple-Mail=_BDF246C1-F20C-4CA8-A743-36B4713647AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 27, 2013:11:13 AM, at 11:13 AM, Ken Gray = wrote: > I would propose that we work out that detail in the WG and not the > charter. The charter isn't supposed to work out all the use cases. Precisely; its sufficient to say, "work on X use cases, produce = a document by date Y." > The consensus seems (to me) that passing the information listed in the > charter is valuable (at least in some cases) as part and parcel of > building service chains and we therefor do need a header. >=20 > I think the WG docs can take up "transparency" of the header that = passes > that information (you can always ignore it, but the idea is = multi-vendor > interop) and the format of that header (even if it's the NULL set of = what > is listed in the charter). This is an important point to put into the charter though. If = the statement of "The WG will work on transparency issues" or something = isn't there, we might debate whether or not documents are valid. Putting = it into the charter now makes it an explicitly valid thing to work on. = Remember, the charter is a "ring fence" that sets boundaries for the WG. = This is why I think it should explicitly go in there. --Tom >=20 >=20 >=20 > On 9/27/13 10:33 AM, "NAPIERALA, MARIA H" wrote: >=20 >> Jim, >>=20 >> there might be solutions where such information is not needed to be >> carried in the data plane. >> So, what I am proposing is not to list it explicitly in the charter. >>=20 >> Maria >>=20 >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Friday, September 27, 2013 10:26 AM >>> To: NAPIERALA, MARIA H; Ron Parker; Thomas Nadeau; = adrian@olddog.co.uk >>> Cc: nsc@ietf.org >>> Subject: Re: [nsc] New NSC WG Charter >>>=20 >>> Hi Maria, >>>=20 >>> The charter does not specify "service function chain ID" but rather >>> says >>> "encapsulation format for conveying the service function chain and = the >>> service function path" - in other words it does not specify the = format >>> of >>> the encapsulation but simply states that it will carry information >>> pertaining to the SFC and SFP. >>>=20 >>> On 9/27/13 10:14 AM, "NAPIERALA, MARIA H" wrote: >>>=20 >>>> Ron, >>>>=20 >>>>> I couldn't agree more that a single service header definition is >>>>> necessary to make this effort successful in terms of adoption and >>>>> deployment and I support stating that requirement up front, in the >>>>> charter. Whether or not the service header is fixed length, >>> variable >>>>> length, TLV, AVP, carries this kind of metadata or that, does not >>> have >>>>> to be in the charter. >>>>=20 >>>> I agree. But currently the charter lists some specific pieces of >>> header >>>> information like service function chain ID and the service function >>> path. >>>> IMO, this should not be part of the charter. This belongs to the >>>> solutions. >>>>=20 >>>> Maria >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>> Of >>>>> Thomas Nadeau >>>>> Sent: Friday, September 27, 2013 9:30 AM >>>>> To: adrian@olddog.co.uk >>>>> Cc: nsc@ietf.org; 'Jim Guichard (jguichar)'; 'NAPIERALA, MARIA H' >>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>=20 >>>>>=20 >>>>> On Sep 26, 2013:6:01 PM, at 6:01 PM, "Adrian Farrel" >>>>> wrote: >>>>>=20 >>>>>> I have to pile in here :-( >>>>>>=20 >>>>>> Maria, I think you want to say "Don't require me to use a >>>>>> service-level encapsulation to achieve this function". >>>>>> I don't believe you want to say "Allow me to have more than one >>>>>> service-level encapsulation to achieve this function." >>>>>>=20 >>>>>> The text does not in any way preclude having other mechanisms for >>>>> doing stuff. >>>>>> In particular, configuring service chains at service nodes is an >>>>>> obvious approach. Similarly the service chain information might = be >>>>>> distributed (ahead of >>>>>> time) by some other protocol. >>>>>>=20 >>>>>> The text does say that there will be at most one service-level >>>>> encapsulation. >>>>>> Because setting out to have more than one new encapsulation >>> protocol >>>>>> to do the same thing. >>>>>>=20 >>>>>> Text also says that there will be a service-level encapsulation. >>>>>> Why does it do that? >>>>>> Because, if this WG goes off and decides to tweak every protocol >>> that >>>>>> is out there to make a special way to carry service chain >>> information >>>>>> in that protocol, it will be a disaster (IMNSHO). >>>>>=20 >>>>> Agreed. This is very important to be clear on. >>>>>=20 >>>>> --Tom >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> If this doesn't address your concern, Maria, perhaps rather than >>> try >>>>>> to change the text or comment on what you think the text implies, >>> you >>>>>> could say what it is you want to be able to do. That way we can >>> say >>>>>> whether it is in or out of scope of the current text. >>>>>>=20 >>>>>> Thanks, >>>>>> Adrian >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> Behalf >>>>> Of >>>>>>> NAPIERALA, MARIA H >>>>>>> Sent: 26 September 2013 16:35 >>>>>>> To: Jim Guichard (jguichar) >>>>>>> Cc: nsc@ietf.org >>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>=20 >>>>>>> I understand. >>>>>>> Why such document is specifically singled out in the charter? >>> Let's >>>>>>> leave it >>>>>> to the >>>>>>> solutions. >>>>>>>=20 >>>>>>> Maria >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Thursday, September 26, 2013 10:51 AM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: nsc@ietf.org >>>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>>=20 >>>>>>>> That is talking about context information - notice all the >>> *and's* >>>>>>>> in the sentence ;-) >>>>>>>>=20 >>>>>>>> On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" >>> wrote: >>>>>>>>=20 >>>>>>>>> This paragraph is good. >>>>>>>>>=20 >>>>>>>>> I was pointing out that the item 3 (under "Specifically, the >>> SFC >>>>> WG >>>>>>>>> is chartered to deliver the following" heading) is implying a >>>>>>>>> specific solution (which is fine but it should not be the only >>>>> one...): >>>>>>>>>=20 >>>>>>>>> "3) Generic Service Function Chaining Encapsulation: A = document >>>>>>>>> will describe the single service-level data plane = encapsulation >>>>>>>>> format for conveying the service function chain and the = service >>>>>>>>> function path, >>>>>>>> and >>>>>>>>> for communicating context information between nodes that >>> implement >>>>>>>>> service functions..." >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Maria >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>>>> Sent: Thursday, September 26, 2013 10:31 AM >>>>>>>>>> To: NAPIERALA, MARIA H >>>>>>>>>> Cc: nsc@ietf.org >>>>>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>>>>=20 >>>>>>>>>> Yes and I believe the following text from the charter covers >>> that >>>>>>>>>> -> "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." >>>>>>>>>>=20 >>>>>>>>>> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" >>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Jim, >>>>>>>>>>>=20 >>>>>>>>>>> I said the opposite, i.e., how to carry metadata should be >>> part >>>>>>>>>>> of >>>>>>>> the >>>>>>>>>>> charter but how to carry the metadata should not necessarily >>>>>>>> dictate >>>>>>>>>> how >>>>>>>>>>> the service chain path itself is realized. >>>>>>>>>>>=20 >>>>>>>>>>> Maria >>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>>>>>> Sent: Thursday, September 26, 2013 10:13 AM >>>>>>>>>>>> To: NAPIERALA, MARIA H; Thomas Narten >>>>>>>>>>>> Cc: nsc@ietf.org >>>>>>>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Maria, >>>>>>>>>>>>=20 >>>>>>>>>>>> Hope you are well. I do not believe the new charter text >>>>>>>>>>>> prevents >>>>>>>>>> the >>>>>>>>>>>> realization of a service chain *without* metadata/context >>>>>>>>>> information. >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" >>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> I believe the NSC architecture should not preclude the >>> service >>>>>>>>>> chain >>>>>>>>>>>>> path/topology from being realized with some existing (and >>>>>>>> standard >>>>>>>>>> ;-) >>>>>>>>>>>>> network overlay (=3Dvirtual network) technique. But if the >>>>>>>> decision >>>>>>>>>> is >>>>>>>>>>>> made >>>>>>>>>>>>> that it does then this should be clearly stated in the >>>>> charter. >>>>>>>>>>>>> What must be common to the service chain path solutions = is, >>>>>>>>>>>>> IMO, >>>>>>>>>> the >>>>>>>>>>>>> method for carrying the metadata/context information. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Maria >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Thomas Narten [mailto:narten@us.ibm.com] >>>>>>>>>>>>>> Sent: Wednesday, September 25, 2013 5:24 PM >>>>>>>>>>>>>> To: NAPIERALA, MARIA H >>>>>>>>>>>>>> Cc: Jim Guichard (jguichar); nsc@ietf.org >>>>>>>>>>>>>> Subject: Re: [nsc] New NSC WG Charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> "NAPIERALA, MARIA H" writes: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The group charter's write-up says that: "The Service >>>>>>>> Function >>>>>>>>>>>>>>> Chaining (SFC) working group will develop new approaches >>> to >>>>>>>>>>>> service >>>>>>>>>>>>>>> delivery ..." (i.e., not one "approach" but = "approaches", >>>>>>>> which >>>>>>>>>>>>>>> means more than one). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> But then is states that a document will be developed = such >>>>>>>> that >>>>>>>>>> it >>>>>>>>>>>>>>> "will describe *the(?) single* service-level data plane >>>>>>>>>>>>>>> encapsulation format for conveying the service function >>>>>>>> chain >>>>>>>>>> and >>>>>>>>>>>>>>> the service function path associated with data packets, >>> and >>>>>>>>>> for >>>>>>>>>>>>>>> carrying context information between nodes that = implement >>>>>>>>>> service >>>>>>>>>>>>>>> functions". >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> How to do you reconcile those two statements? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Note: this inconsistency existed in the earlier charter, = I >>>>>>>> didn't >>>>>>>>>>>>>> introduce it. :-) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I think for the service plane data encapsulation, we >>> should >>>>>>>> aim >>>>>>>>>> for >>>>>>>>>>>>>> one. I'm understand the concern about writing that into >>> the >>>>>>>>>> charter >>>>>>>>>>>> in >>>>>>>>>>>>>> absolute terms, as I think the WG should have room to >>> discuss >>>>>>>> and >>>>>>>>>> it >>>>>>>>>>>>>> may be too early to be definitive. But unless there is >>>>>>>> compelling >>>>>>>>>>>>>> reason, we should have one encap. (BTW, nothing new = here.. >>>>>>>> this >>>>>>>>>> is >>>>>>>>>>>>>> normal IETF.) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> That said, I don't see the need for more than one encap. >>> Does >>>>>>>>>> anyone >>>>>>>>>>>>>> think we do? And if so, why? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> In my opinion, we should open the door for more than one >>>>>>>>>> solution >>>>>>>>>>>> to >>>>>>>>>>>>>>> service chaining. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ah, "solution to service chaining" (to me) is more than >>> the >>>>>>>>>> encap, >>>>>>>>>>>>>> including the control plane and related stuff. So even if >>> we >>>>>>>>>> develop >>>>>>>>>>>>>> one encap, that doesn't necessarily mean there is only = one >>>>>>>>>>>>>> "solution". So the inconsistency may not be quite as >>> strong >>>>> as >>>>>>>>>> first >>>>>>>>>>>>>> seems. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Suggestion. change: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A document will describe the single service-level data >>> plane >>>>>>>>>>>>>> encapsulation format ... >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> To: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A document will describe a service-level data plane >>>>>>>>>> encapsulation >>>>>>>>>>>>>> format ... >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> this is a bit weaker, but still does (implicitely) = suggest >>>>> one >>>>>>>>>>>> encap. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> or, if folk think this is not good enough, we could add >>> text >>>>>>>>>> saying >>>>>>>>>>>> we >>>>>>>>>>>>>> are aiming for one, and will only do more if ... >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> But personally, I think it would be fine to have the >>> charter >>>>>>>> say >>>>>>>>>> one >>>>>>>>>>>>>> encap, and if the WG concludes that one encap isn't what >>> is >>>>>>>>>> needed, >>>>>>>>>>>>>> then recharter. We shouldn't look at rechartering as >>>>>>>>>> "impossible". >>>>>>>>>>>> We >>>>>>>>>>>>>> just need to be able to make the case that more than one >>>>> encap >>>>>>>> is >>>>>>>>>>>>>> necessary. If we can do that, I wouldn't think >>> rechartering >>>>>>>> would >>>>>>>>>> be >>>>>>>>>>>> a >>>>>>>>>>>>>> big deal. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Thomas >>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>=20 >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_BDF246C1-F20C-4CA8-A743-36B4713647AF 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 iQIcBAEBCgAGBQJSRaO4AAoJEPcO+I7eiUJZcVUP/AtSo5hVNQ91yCYiSQBILHki xKUfDnl8jvpSqrAsQ4+S9qBJ2g+HjjJsBFJ7ZHsKqHzCYd0xALZcAPysPi44jxTC MDeyAD4yNxzc5y0kS0AlaqOntTztSYeJwOQfyHp8BhXpaGwLEgcpU1Sgu0+t/gzE sg2J9sHnmdRWJvIWvS5JHsaxEvy/OqYxkw7WkFXfdDJFAgfbcxvH6Vpu4jYxQEX2 JXI1NImrJjAJHiDSTU7Qbb8runHPzBo1ZCn4ikkgz9/5BFR3ZgjYYm+l7m4IsC18 DZLJTH/qbnH4GBfU/Ui26/3KyAqLL9A9xfWd9RNlhtQT+dNpEGTuxqVz8A5VStfY nTVhS4S0RJq0V74oYCnp07yNDklJobV/4ZAEFzgLH0Di8J+wvfQaseh3MpNY+2sc yF0LLktRHIYJ1FzWxoxjpyxK2vYyTCPeBkqssmMaDMwCcrYlc1aHIe18A7rfGM6Z 1jcYCzj30hhBpNa+DfhPSNKkCslxPm6M1D1esGDUYih4U+6/uUVu9OtELESwaYI2 rs6+Plw5AJ7G1/c5cRp0pWCAd/mrqA6WdoE2Q07z1lxy2r4wwRjoqvTKnzE0TUXx wrxf1COBXlEQd0ngtPiuHZt1EmnOzzdkkkIlj/GLtm9Vqz0VgoGXvdnxW3ixHq3N pMj3sI0oLCH8w0nAywXR =ZIWI -----END PGP SIGNATURE----- --Apple-Mail=_BDF246C1-F20C-4CA8-A743-36B4713647AF--