From nobody Mon Jan 5 01:46:26 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2861A2130 for ; Mon, 5 Jan 2015 01:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H0X-VQY3QqG for ; Mon, 5 Jan 2015 01:46:23 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0898D1A212D for ; Mon, 5 Jan 2015 01:46:23 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id et14so28497370pad.29 for ; Mon, 05 Jan 2015 01:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=9xHgq79og6ptMo0q4OWqQeIfzSoJJfh2dsF5oA9rWMI=; b=vmTgVgIoyuuYvykyKqRgqCzZgCO1OqQw+hdCOxgyR3yFi3ibzuuE/oF8tdbKz/fp2C /Kvh2oiXpLcxBl92twWYV6vMrNO6q6zBEBaeBf1RO86EvKBxgAKRUlTd4238ltR4uL9n fzSoxNPucmRjqalpakILHobK9rLZGZy/30pefHPRjehfWUmpBLQibO7v4l9eYGmznuGD efBDfK59u7+PI5bsjbR2/KIZRK9XOzu3Qil+25V692hiWgGhTXF3o0wwYo9l4LF+w55h KV2XFAYH2ovM8Fq0HG5Tc22AIEcibMzpJ0VRftNS95vLSIlGNGkxL/02UFRJ6MJpzzJ4 2H+g== X-Received: by 10.70.91.208 with SMTP id cg16mr144230185pdb.144.1420451182196; Mon, 05 Jan 2015 01:46:22 -0800 (PST) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id gm8sm20618695pbc.25.2015.01.05.01.46.18 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 05 Jan 2015 01:46:21 -0800 (PST) From: "Lizhong Jin" To: Date: Mon, 5 Jan 2015 17:46:14 +0800 Message-ID: <00ce01d028cc$75733bb0$6059b310$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01D0290F.8397DB40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAoy6bOS6ROISegTU+mGS2rLqpB1w== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lq9FyBbiR35MlasN3ZeTqNncKEY Cc: jguichar@cisco.com, bill.wu@huawei.com, sfc@ietf.org Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 09:46:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CF_01D0290F.8397DB40 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Unlike the first case and the third case, in the second case, control = plane application doesn=A1=AFt need to inform SFC edge switch/router about the = change to the existing service chain since it is still a same service function chain. But control plane application needs to communicate with the service functions that is preceding the CDN cache = and one that is following the CDN cache about forwarding change. Let me know = if my understanding is correct. Ramki: Your statement is confusing. The chain needs to be manipulated = for all the use cases. [Qin]: In the CDN case, the SFC edge switch/router as Classifier = doesn=A1=AFt need to know whether or not you add a new service function into the = existing service chain since traffic flow still corresponds to the same chain. = But in the transparent firewall case and IPSEC Gateway case, the flow should be switched from one service chain to another new chain, the SFC edge switch/router MUST know binding change between the traffic flow and the service chain. Does this clarify? Ramki1: You are mistaken in the CDN case. Please look at my previous = answers and I would suggest you to carefully read section 3.1, the Long-tail = content CDN event sequence. [Lizhong] actually I have similar understanding as Qin when reading = section 3.1. The =A1=B0service chain=A1=B1 in point 2 could be explained as the = same =A1=B0service chain=A1=B1 implicitly said in point 1. We may change the = description of point 2 as below: =A1=B0the CDN Monitoring System instructs the SFC Control Plane = Application to dynamically establish the service chain with CDN cache for that = content=A1=B1 =20 Regards Lizhong =20 Regards! -Qin =B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces at ietf.org = ] =B4=FA=B1=ED Jim Guichard (jguichar) =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA12=D4=C215=C8=D5 23:15 =CA=D5=BC=FE=C8=CB: sfc at ietf.org =20 =D6=F7=CC=E2: [sfc] WG LC for = draft-ietf-sfc-long-lived-flow-use-cases-01 =20 Dear WG: =20 This note begins a 2-week WG LC on = draft-ietf-sfc-long-lived-flow-use-cases. 01.txt. =20 The document authors have indicated that they have addressed all known comments and that there are no open issues with the current version of = the document.=20 =20 Substantive comments to the list please, editorial comments can go = directly to the document editors. =20 Jim & Thomas =20 =20 =20 ------=_NextPart_000_00CF_01D0290F.8397DB40 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Unlike the first case and the = third case, in the second case, control plane application doesn=A1=AFt = need to inform SFC edge switch/router about the change to the existing = service chain since it is still

a = same service function chain. But control plane application needs to = communicate with the service functions that is preceding the CDN cache = and one that is following the CDN cache about forwarding change. Let me = know if my understanding is correct.

Ramki: Your statement is confusing. The chain = needs to be manipulated for all the use cases.

[Qin]: In the CDN case, the SFC = edge switch/router as Classifier doesn=A1=AFt need to know whether or = not you add a new service function into the existing service chain since = traffic flow still corresponds to the same chain. But in the transparent = firewall case and IPSEC Gateway case, the flow should be switched from = one service chain to another new chain, the SFC edge switch/router MUST = know binding change between the traffic flow and the service chain. Does = this clarify?

Ramki1: You are mistaken in the CDN case. Please = look at my previous answers and I would suggest you to carefully read = section 3.1, the Long-tail content CDN event = sequence.

[Lizhong] actually I have similar understanding = as Qin when reading section 3.1. The =A1=B0service chain=A1=B1 in point = 2 could be explained as the same =A1=B0service chain=A1=B1 implicitly = said in point 1. We may change the description of point 2 as = below:

=A1=B0the CDN Monitoring System instructs the = SFC Control Plane Application to dynamically establish the service chain = with CDN cache for that content=A1=B1

 

Regards

Lizhong

 

Regards!

-Qin

=B7=A2=BC= =FE=C8=CB:<= /b> sfc [mailto:sfc-bounces at = ietf.org] =B4=FA=B1=ED Jim Guichard = (jguichar)
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA12=D4=C215=C8=D5 23:15
=CA=D5=BC=FE=C8=CB: sfc at ietf.org
=D6=F7=CC=E2: [sfc] WG LC for = draft-ietf-sfc-long-lived-flow-use-cases-01

 

Dear WG:

 

This note begins a 2-week WG LC = on draft-ietf-sfc-long-lived-flow-use-cases.01.txt.

 

The document authors have = indicated that they have addressed all known comments and that there are = no open issues with the current version of the = document. 

 

Substantive comments to the list = please, editorial comments can go directly to the document = editors.

 

Jim & Thomas

 

 

 

------=_NextPart_000_00CF_01D0290F.8397DB40-- From nobody Mon Jan 5 02:15:37 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA9D1A3BA4 for ; Mon, 5 Jan 2015 02:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.55 X-Spam-Level: X-Spam-Status: No, score=0.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kubJ-JmQxIka for ; Mon, 5 Jan 2015 02:15:33 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76551A3BA1 for ; Mon, 5 Jan 2015 02:15:33 -0800 (PST) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id t059Rtt1015078; Mon, 5 Jan 2015 02:15:21 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1rnk7myx0p-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 05 Jan 2015 02:15:21 -0800 Received: from HQ1WP-EXMB11.corp.brocade.com (10.70.20.185) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Jan 2015 02:15:19 -0800 Received: from HQ1WP-EXMB11.corp.brocade.com (10.70.20.185) by HQ1WP-EXMB11.corp.brocade.com (10.70.20.185) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 5 Jan 2015 02:15:19 -0800 Received: from HQ1WP-EXMB11.corp.brocade.com ([fe80::aa:5ef3:93e5:ed6d]) by HQ1WP-EXMB11.corp.brocade.com ([fe80::aa:5ef3:93e5:ed6d%18]) with mapi id 15.00.0995.031; Mon, 5 Jan 2015 02:15:19 -0800 From: Ramki Krishnan To: Lizhong Jin Thread-Topic: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AdAoy6bOS6ROISegTU+mGS2rLqpB1wAA3cPQ Date: Mon, 5 Jan 2015 10:15:18 +0000 Message-ID: <0b46db1f32cf4b16aa33be576642f027@HQ1WP-EXMB11.corp.brocade.com> References: <00ce01d028cc$75733bb0$6059b310$@gmail.com> In-Reply-To: <00ce01d028cc$75733bb0$6059b310$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.180.50] Content-Type: multipart/alternative; boundary="_000_0b46db1f32cf4b16aa33be576642f027HQ1WPEXMB11corpbrocadec_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-05_01:2015-01-02,2015-01-04,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-1402240000 definitions=main-1501050104 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/U4e4IbnVmq3o1S26scyp8HPkk9k Cc: "jguichar@cisco.com" , "bill.wu@huawei.com" , "sfc@ietf.org" Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 10:15:36 -0000 --_000_0b46db1f32cf4b16aa33be576642f027HQ1WPEXMB11corpbrocadec_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RXZlbiBpbiB0aGUgc2Vjb25kIGNhc2UsIHRoZSBTRkMgY29udHJvbCBwbGFuZSBhcHBsaWNhdGlv biAqZG9lcyBuZWVkKiB0byBpbmZvcm0gdGhlIFNGQyBlZGdlIHN3aXRjaC9yb3V0ZXIgYWJvdXQg dGhlIGNoYW5nZSB0byB0aGUgc2VydmljZSBjaGFpbi4gUGVyaGFwcyB0aGUgZXhpc3RpbmcgdGV4 dCBkb2VzIG5vdCBleHByZXNzIHRoaXMgYXNwZWN0IGNsZWFybHkuIFdlIHdpbGwgY2xhcmlmeSB0 aGlzIGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkb2N1bWVudCB1c2luZyB0ZXh0IGFsb25n IHRoZSBsaW5lcyBkZXNjcmliZWQgYmVsb3cuDQoNCkV2ZW50IFNlcXVlbmNlIGZvciBDRE4gKG1v ZGlmaWVkIHZlcnNpb24pDQoNCjEuIFRoZSBDRE4gTW9uaXRvcmluZyBTeXN0ZW0gbW9uaXRvcnMg dGhlIG51bWJlcnMgb2YgdXNlcnMgYW5kIHR5cGUgb2YgY29udGVudCBiZWluZyBhY2Nlc3NlZC4g QnkgZGVmYXVsdCwgd2UgYXNzdW1lIHRoZSBDRE4gQ2FjaGUgaXMgYnlwYXNzZWQuDQoyLiAgICAg IElmIHRoZSBudW1iZXIgb2YgdXNlcnMgdmlld2luZyB0aGUgc2FtZSBjb250ZW50IGV4Y2VlZHMg YSBwcmUtcHJvZ3JhbW1lZCB1cC10aHJlc2hvbGQgYW5kIHRoZSBjb250ZW50IGlzIGxvbmctbGl2 ZWQsIHRoZSBDRE4gTW9uaXRvcmluZyBTeXN0ZW0gaW5zdHJ1Y3RzIHRoZSBTRkMgQ29udHJvbCBQ bGFuZSBBcHBsaWNhdGlvbiB0byAgZHluYW1pY2FsbHkgc3dpdGNoIGZyb20gdGhlIGV4aXN0aW5n IHNlcnZpY2UgY2hhaW4gQSB0byBhbm90aGVyIHNlcnZpY2UgY2hhaW4gQiB3aGljaCBpbmNsdWRl cyBhIENETiBjYWNoZSBmb3IgY2FjaGluZyB0aGUgIGNvbnRlbnQgaW4gYWRkaXRpb24gdG8gYWxs IG9mIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBzZXJ2aWNlIGNoYWluIEEgaW4gdGhlIHNhbWUg b3JkZXIuIFRoaXMgaXMgZG9uZSBieSBpbnN0YWxsaW5nIGEgcnVsZSBmb3IgdGhlIGZsb3cgY29y cmVzcG9uZGluZyB0byB0aGUgY29udGVudCBpbiB0aGUgU0ZDIGVkZ2Ugc3dpdGNoL3JvdXRlci4N CjMuICAgICAgSWYgdGhlIG51bWJlciBvZiB1c2VycyB2aWV3aW5nIHRoZSBzYW1lIGNvbnRlbnQg ZmFsbHMgYmVsb3cgYW5vdGhlciBwcmUtcHJvZ3JhbW1lZCBkb3duLXRocmVzaG9sZCBhbmQgdGhl IGNvbnRlbnQgaXMgbG9uZy1saXZlZCwgdGhlIG1vbml0b3Jpbmcgc2VydmVyIGluc3RydWN0cyB0 aGUgU0ZDIENvbnRyb2wgUGxhbmUgQXBwbGljYXRpb24gdG8gZHluYW1pY2FsbHkgc3dpdGNoIHRo ZSBmbG93IGZyb20gdGhlIGV4aXN0aW5nIHNlcnZpY2UgY2hhaW4gQiAodGhlIG9uZSB0aGF0IHdh cyB1c2VkIGluIHRoZSBwcmV2aW91cyBldmVudCkgdG8gc2VydmljZSBjaGFpbiBBIChhZ2Fpbiwg d2hpY2ggaW5jbHVkZXMgYWxsIG9mIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBzZXJ2aWNlIGNo YWluIEIgb3RoZXIgdGhhbiB0aGUgQ0ROIGNhY2hlKS4gVGhpcyBpcyBkb25lIGJ5IHJlbW92aW5n IHRoZSBwcmV2aW91c2x5IGluc3RhbGxlZCBydWxlIGZvciB0aGUgZmxvdyBjb3JyZXNwb25kaW5n IHRvIHRoZSBjb250ZW50IGZyb20gdGhlIFNGQyBlZGdlIHN3aXRjaC9yb3V0ZXIuDQpUaGFua3Ms DQpSYW1raQ0KDQpGcm9tOiBMaXpob25nIEppbiBbbWFpbHRvOmxpemhvLmppbkBnbWFpbC5jb21d DQpTZW50OiBNb25kYXksIEphbnVhcnkgMDUsIDIwMTUgMzoxNiBQTQ0KVG86IFJhbWtpIEtyaXNo bmFuDQpDYzogYmlsbC53dUBodWF3ZWkuY29tOyBqZ3VpY2hhckBjaXNjby5jb207IHNmY0BpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIFdHIExDIGZvciBkcmFmdC1pZXRmLXNmYy1sb25nLWxp dmVkLWZsb3ctdXNlLWNhc2VzLTAxDQoNClVubGlrZSB0aGUgZmlyc3QgY2FzZSBhbmQgdGhlIHRo aXJkIGNhc2UsIGluIHRoZSBzZWNvbmQgY2FzZSwgY29udHJvbCBwbGFuZSBhcHBsaWNhdGlvbiBk b2VzbqGvdCBuZWVkIHRvIGluZm9ybSBTRkMgZWRnZSBzd2l0Y2gvcm91dGVyIGFib3V0IHRoZSBj aGFuZ2UgdG8gdGhlIGV4aXN0aW5nIHNlcnZpY2UgY2hhaW4gc2luY2UgaXQgaXMgc3RpbGwNCmEg c2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluLiBCdXQgY29udHJvbCBwbGFuZSBhcHBsaWNhdGlv biBuZWVkcyB0byBjb21tdW5pY2F0ZSB3aXRoIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IGlz IHByZWNlZGluZyB0aGUgQ0ROIGNhY2hlIGFuZCBvbmUgdGhhdCBpcyBmb2xsb3dpbmcgdGhlIENE TiBjYWNoZSBhYm91dCBmb3J3YXJkaW5nIGNoYW5nZS4gTGV0IG1lIGtub3cgaWYgbXkgdW5kZXJz dGFuZGluZyBpcyBjb3JyZWN0Lg0KUmFta2k6IFlvdXIgc3RhdGVtZW50IGlzIGNvbmZ1c2luZy4g VGhlIGNoYWluIG5lZWRzIHRvIGJlIG1hbmlwdWxhdGVkIGZvciBhbGwgdGhlIHVzZSBjYXNlcy4N CltRaW5dOiBJbiB0aGUgQ0ROIGNhc2UsIHRoZSBTRkMgZWRnZSBzd2l0Y2gvcm91dGVyIGFzIENs YXNzaWZpZXIgZG9lc26hr3QgbmVlZCB0byBrbm93IHdoZXRoZXIgb3Igbm90IHlvdSBhZGQgYSBu ZXcgc2VydmljZSBmdW5jdGlvbiBpbnRvIHRoZSBleGlzdGluZyBzZXJ2aWNlIGNoYWluIHNpbmNl IHRyYWZmaWMgZmxvdyBzdGlsbCBjb3JyZXNwb25kcyB0byB0aGUgc2FtZSBjaGFpbi4gQnV0IGlu IHRoZSB0cmFuc3BhcmVudCBmaXJld2FsbCBjYXNlIGFuZCBJUFNFQyBHYXRld2F5IGNhc2UsIHRo ZSBmbG93IHNob3VsZCBiZSBzd2l0Y2hlZCBmcm9tIG9uZSBzZXJ2aWNlIGNoYWluIHRvIGFub3Ro ZXIgbmV3IGNoYWluLCB0aGUgU0ZDIGVkZ2Ugc3dpdGNoL3JvdXRlciBNVVNUIGtub3cgYmluZGlu ZyBjaGFuZ2UgYmV0d2VlbiB0aGUgdHJhZmZpYyBmbG93IGFuZCB0aGUgc2VydmljZSBjaGFpbi4g RG9lcyB0aGlzIGNsYXJpZnk/DQpSYW1raTE6IFlvdSBhcmUgbWlzdGFrZW4gaW4gdGhlIENETiBj YXNlLiBQbGVhc2UgbG9vayBhdCBteSBwcmV2aW91cyBhbnN3ZXJzIGFuZCBJIHdvdWxkIHN1Z2dl c3QgeW91IHRvIGNhcmVmdWxseSByZWFkIHNlY3Rpb24gMy4xLCB0aGUgTG9uZy10YWlsIGNvbnRl bnQgQ0ROIGV2ZW50IHNlcXVlbmNlLg0KW0xpemhvbmddIGFjdHVhbGx5IEkgaGF2ZSBzaW1pbGFy IHVuZGVyc3RhbmRpbmcgYXMgUWluIHdoZW4gcmVhZGluZyBzZWN0aW9uIDMuMS4gVGhlIKGwc2Vy dmljZSBjaGFpbqGxIGluIHBvaW50IDIgY291bGQgYmUgZXhwbGFpbmVkIGFzIHRoZSBzYW1lIKGw c2VydmljZSBjaGFpbqGxIGltcGxpY2l0bHkgc2FpZCBpbiBwb2ludCAxLiBXZSBtYXkgY2hhbmdl IHRoZSBkZXNjcmlwdGlvbiBvZiBwb2ludCAyIGFzIGJlbG93Og0KobB0aGUgQ0ROIE1vbml0b3Jp bmcgU3lzdGVtIGluc3RydWN0cyB0aGUgU0ZDIENvbnRyb2wgUGxhbmUgQXBwbGljYXRpb24gdG8g ZHluYW1pY2FsbHkgZXN0YWJsaXNoIHRoZSBzZXJ2aWNlIGNoYWluIHdpdGggQ0ROIGNhY2hlIGZv ciB0aGF0IGNvbnRlbnShsQ0KDQpSZWdhcmRzDQpMaXpob25nDQoNClJlZ2FyZHMhDQotUWluDQq3 orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzIGF0IGlldGYub3JnPG1haWx0bzpzZmMtYm91 bmNlcyUyMGF0JTIwaWV0Zi5vcmc+XSC0+rHtIEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQq3osvN yrG85DogMjAxNMTqMTLUwjE1yNUgMjM6MTUNCsrVvP7Iyzogc2ZjIGF0IGlldGYub3JnPG1haWx0 bzpzZmMlMjBhdCUyMGlldGYub3JnPg0K1vfM4jogW3NmY10gV0cgTEMgZm9yIGRyYWZ0LWlldGYt c2ZjLWxvbmctbGl2ZWQtZmxvdy11c2UtY2FzZXMtMDENCg0KRGVhciBXRzoNCg0KVGhpcyBub3Rl IGJlZ2lucyBhIDItd2VlayBXRyBMQyBvbiBkcmFmdC1pZXRmLXNmYy1sb25nLWxpdmVkLWZsb3ct dXNlLWNhc2VzLjAxLnR4dC4NCg0KVGhlIGRvY3VtZW50IGF1dGhvcnMgaGF2ZSBpbmRpY2F0ZWQg dGhhdCB0aGV5IGhhdmUgYWRkcmVzc2VkIGFsbCBrbm93biBjb21tZW50cyBhbmQgdGhhdCB0aGVy ZSBhcmUgbm8gb3BlbiBpc3N1ZXMgd2l0aCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkb2N1 bWVudC4NCg0KU3Vic3RhbnRpdmUgY29tbWVudHMgdG8gdGhlIGxpc3QgcGxlYXNlLCBlZGl0b3Jp YWwgY29tbWVudHMgY2FuIGdvIGRpcmVjdGx5IHRvIHRoZSBkb2N1bWVudCBlZGl0b3JzLg0KDQpK aW0gJiBUaG9tYXMNCg0KDQoNCg== --_000_0b46db1f32cf4b16aa33be576642f027HQ1WPEXMB11corpbrocadec_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Even in t= he second case, the SFC control plane application *does = need* to inform the SFC edge switch/router about the change to the serv= ice chain. Perhaps the existing text does not express this aspect clearly. = We will clarify this in the next revision of the document using text along the lines described below.

 

Event Sequence for = CDN (modified version)

 

1= . The CDN Monitoring System monitors the numbe= rs of users and type of content being accessed. By default, we assume the C= DN Cache is bypassed.

2.      If the number of users viewing the same content exc= eeds a pre-programmed up-threshold and the content is long-lived, the CDN M= onitoring System instructs the SFC Control Plane Application to  dynam= ically switch from the existing service chain A to another service chain B which includes a CDN cache for caching = the  content in addition to all of the service functions in service ch= ain A in the same order. This is done by installing a rule for the flow cor= responding to the content in the SFC edge switch/router.

3.      If the number of users viewing the same content fal= ls below another pre-programmed down-threshold and the content is long-live= d, the monitoring server instructs the SFC Control Plane Application to dyn= amically switch the flow from the existing service chain B (the one that was used in the previous event) to = service chain A (again, which includes all of the service functions in serv= ice chain B other than the CDN cache). This is done by removing the previou= sly installed rule for the flow corresponding to the content from the SFC edge switch/router. <= /p>

Thanks,

Ramki

 

From: Lizhong Jin [mailto:lizho.jin@gmail.com= ]
Sent: Monday, January 05, 2015 3:16 PM
To: Ramki Krishnan
Cc: bill.wu@huawei.com; jguichar@cisco.com; sfc@ietf.org
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-case= s-01

 

Unlike the first ca= se and the third case, in the second case, control plane application doesn= =A1=AFt need to inform SFC edge switch/router about the change to the existing service chain since it is still

a same service function chai= n. But control plane application needs to communicate with the service func= tions that is preceding the CDN cache and one that is following the CDN cac= he about forwarding change. Let me know if my understanding is correct.

Ramki: Your statement is confusing. = The chain needs to be manipulated for all the use cases.

[Qin]: In the CDN c= ase, the SFC edge switch/router as Classifier doesn=A1=AFt need to know whe= ther or not you add a new service function into the existing service chain since traffic flow still corresponds to th= e same chain. But in the transparent firewall case and IPSEC Gateway case, = the flow should be switched from one service chain to another new chain, th= e SFC edge switch/router MUST know binding change between the traffic flow and the service chain. Does this c= larify?

Ramki1: You are mistaken in the CDN = case. Please look at my previous answers and I would suggest you to careful= ly read section 3.1, the Long-tail content CDN event sequence.

[Lizhong] actually I have similar un= derstanding as Qin when reading section 3.1. The =A1=B0service chain=A1=B1 = in point 2 could be explained as the same =A1=B0service chain=A1=B1 implicitly said in point 1. We may change the description of p= oint 2 as below:

=A1=B0the CDN Monitoring System inst= ructs the SFC Control Plane Application to dynamically establish the servic= e chain with CDN cache for that content=A1=B1

 

Regards

Lizhong

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces at ietf= .org] =B4=FA=B1=ED <= /span>Jim Guichard (jguichar)
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1= 2=D4=C215=C8=D5 23:15
=CA=D5=BC=FE=C8=CB: sfc at= ietf.org
=D6=F7=CC=E2: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-= cases-01

 =

Dear WG:

 

This note begins a 2-= week WG LC on draft-ietf-sfc-long-lived-flow-use-cases.01.txt.

 

The document authors = have indicated that they have addressed all known comments and that there a= re no open issues with the current version of the document. 

 

Substantive comments = to the list please, editorial comments can go directly to the document edit= ors.

 

Jim & Thomas

 

 

 

--_000_0b46db1f32cf4b16aa33be576642f027HQ1WPEXMB11corpbrocadec_-- From nobody Mon Jan 5 06:31:48 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDC21A8864 for ; Mon, 5 Jan 2015 06:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL2KnmgppiT3 for ; Mon, 5 Jan 2015 06:31:39 -0800 (PST) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877C31A887B for ; Mon, 5 Jan 2015 06:31:21 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0174.001; Mon, 5 Jan 2015 06:31:20 -0800 From: Ron Parker To: Ramki Krishnan , Lizhong Jin Thread-Topic: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AdAoy6bOS6ROISegTU+mGS2rLqpB1wAA3cPQAAjxB/A= Date: Mon, 5 Jan 2015 14:31:20 +0000 Message-ID: References: <00ce01d028cc$75733bb0$6059b310$@gmail.com> <0b46db1f32cf4b16aa33be576642f027@HQ1WP-EXMB11.corp.brocade.com> In-Reply-To: <0b46db1f32cf4b16aa33be576642f027@HQ1WP-EXMB11.corp.brocade.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_CDF2F015F4429F458815ED2A6C2B6B0B2E7D7F3EMBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/m8slOX93j0JJJJ1HknHIaTWkpVY Cc: "jguichar@cisco.com" , "bill.wu@huawei.com" , "sfc@ietf.org" Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:31:47 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E7D7F3EMBX021W3CA2exch_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SW4gb3JkZXIgdG8gZWZmZWN0IGR5bmFtaWMgY2hhbmdlcyBpbiB0aGUgc2VydmljZSBmdW5jdGlv biBjaGFpbmluZyBmb3IgbG9uZyBsaXZlZCBmbG93cywgdGhlcmUgYXJlIDIgcGFyYWRpZ21zIHRo YXQgY29tZSB0byBtaW5kLiAgIE9uZSBpcyB0aGF0IHdoZW4gYSBzZXJ2aWNlIGZ1bmN0aW9uIGRl dGVybWluZXMgdGhhdCBpdCBubyBsb25nZXIgbmVlZHMgdG8gcGFydGljaXBhdGUgZm9yIGEgZ2l2 ZW4gZmxvdywgdGhlIGZsb3cgaXMgc3dpdGNoZWQgdG8gYSBkaWZmZXJlbnQgc2VydmljZSBmdW5j dGlvbiBjaGFpbiAocGF0aCkgdGhhdCBkb2VzIG5vdCBpbmNsdWRlIHRoZSBhZmZlY3RlZCBzZXJ2 aWNlIGZ1bmN0aW9uLg0KDQpBbiBhbHRlcm5hdGUgcGFyYWRpZ20gaXMgdG8gY29uc2lkZXIgdGhh dCB0aGUgYWZmZWN0ZWQgc2VydmljZSBmdW5jdGlvbiBpcyBiZWluZyBkeW5hbWljYWxseSBieXBh c3NlZCCoQyB0aGF0IGlzLCB0aGUgY2hhaW4vcGF0aCBpcyBzdGlsbCB0aGUgc2FtZSwgYnV0IGxv Y2FsIHN0YXRlIGF0IHRoZSBjbGFzc2lmaWVyIGFuZC9vciBTRkahr3MgbWFuYWdlIHRoZSBmYWN0 IHRoYXQgdGhlIHNlcnZpY2UgZnVuY3Rpb24gaGFzIHdpdGhkcmF3biBmcm9tIHRoZSBjaGFpbiBm b3IgdGhhdCBwYXJ0aWN1bGFyIGZsb3cuICAgIFRoaXMgc2Vjb25kIGFwcHJvYWNoIGRvZXMgaW5k ZWVkIGltcGx5IHN0YXRlZnVsIFNGRqGvcywgYnV0IHdpdGggdGhlIGJlbmVmaXQgb2YgY29udHJv bCBwbGFuZSBzaW1wbGlmaWNhdGlvbi4gICAgIFdpdGggdGhpcyBzZWNvbmQgYXBwcm9hY2gsIGNv bnRyb2wgcGxhbmUgaW52b2x2ZW1lbnQgd291bGQgYmUgYmFzZWQgb24gdGhlIGRlc2lyZWQgbGV2 ZWwgb2Ygb3B0aW1pemF0aW9uLiAgICBJZiBpdCBpcyBzdWZmaWNpZW50IHRoYXQgdGhlIHBhY2tl dHMgY29udGludWUgdG8gZm9sbG93IHRoZSBvcmlnaW5hbCBzZXF1ZW5jZSBvZiBTRkahr3MsIGV2 ZW4gdGhvdWdoIHRoZSBTRkahr3MgbWF5IG5vIGxvbmdlciBpbnZva2UgYW55IG9mIHRoZWlyIHNl cnZpY2UgZnVuY3Rpb24gaW5zdGFuY2VzIGZvciB0aGF0IGZsb3csIHRoZW4gbm8gY29udHJvbCBw bGFuZSBjb29yZGluYXRpb24gaXMgbmVjZXNzYXJ5LiAgIElmLCBob3dldmVyLCBpdCBpcyBkZXNp cmVkIGV2ZW4gdG8gYXZvaWQgdGhlIKGwbnVsbKGxIFNGRqGvcyBmb3IgdGhhdCBmbG93LCB0aGVu IGNvb3JkaW5hdGlvbiB3aWxsIGJlIG5lY2Vzc2FyeS4NCg0KSW4gZHJhZnQtemhhbmctc2ZjLXNj aC0wMywgd2UgaW5jbHVkZSBhIKGwYnlwYXNzobEgYml0IGluIHRoZSBmaXhlZCBwb3J0aW9uIG9m IHRoZSBTQ0ggaGVhZGVyIHRvIHJlYWxpemUgdGhlIHNlY29uZCBhcHByb2FjaCwgYWJvdmU6DQoN CiAgIEIgYml0OiBUaGUgQiAoQnlwYXNzKSBiaXQsIHdoZW4gc2V0IHRvIDEsIGl0IGlzIHVzZWQg YnkgYSBTZXJ2aWNlDQogICAgICBGdW5jdGlvbiB0byBzaWduYWwgdG8gaXRzIFNlcnZpY2UgRnVu Y3Rpb24gRm9yd2FyZGVyIHRoYXQgbm8NCiAgICAgIGZ1cnRoZXIgcGFja2V0cyBhcmUgdG8gYmUg c2VudCB0byBpdCBmb3IgdGhlIGZsb3cgc3BlY2lmaWVkIGluDQogICAgICBlbmNhcHN1bGF0ZWQg cGFja2V0Lg0KDQpUaGFua3MuDQoNCiAgICBSb24NCg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFta2kgS3Jpc2huYW4NClNlbnQ6IE1v bmRheSwgSmFudWFyeSA1LCAyMDE1IDU6MTUgQU0NClRvOiBMaXpob25nIEppbg0KQ2M6IGpndWlj aGFyQGNpc2NvLmNvbTsgYmlsbC53dUBodWF3ZWkuY29tOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbc2ZjXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1zZmMtbG9uZy1saXZlZC1mbG93LXVzZS1j YXNlcy0wMQ0KDQpFdmVuIGluIHRoZSBzZWNvbmQgY2FzZSwgdGhlIFNGQyBjb250cm9sIHBsYW5l IGFwcGxpY2F0aW9uICpkb2VzIG5lZWQqIHRvIGluZm9ybSB0aGUgU0ZDIGVkZ2Ugc3dpdGNoL3Jv dXRlciBhYm91dCB0aGUgY2hhbmdlIHRvIHRoZSBzZXJ2aWNlIGNoYWluLiBQZXJoYXBzIHRoZSBl eGlzdGluZyB0ZXh0IGRvZXMgbm90IGV4cHJlc3MgdGhpcyBhc3BlY3QgY2xlYXJseS4gV2Ugd2ls bCBjbGFyaWZ5IHRoaXMgaW4gdGhlIG5leHQgcmV2aXNpb24gb2YgdGhlIGRvY3VtZW50IHVzaW5n IHRleHQgYWxvbmcgdGhlIGxpbmVzIGRlc2NyaWJlZCBiZWxvdy4NCg0KRXZlbnQgU2VxdWVuY2Ug Zm9yIENETiAobW9kaWZpZWQgdmVyc2lvbikNCg0KMS4gVGhlIENETiBNb25pdG9yaW5nIFN5c3Rl bSBtb25pdG9ycyB0aGUgbnVtYmVycyBvZiB1c2VycyBhbmQgdHlwZSBvZiBjb250ZW50IGJlaW5n IGFjY2Vzc2VkLiBCeSBkZWZhdWx0LCB3ZSBhc3N1bWUgdGhlIENETiBDYWNoZSBpcyBieXBhc3Nl ZC4NCjIuICAgICAgSWYgdGhlIG51bWJlciBvZiB1c2VycyB2aWV3aW5nIHRoZSBzYW1lIGNvbnRl bnQgZXhjZWVkcyBhIHByZS1wcm9ncmFtbWVkIHVwLXRocmVzaG9sZCBhbmQgdGhlIGNvbnRlbnQg aXMgbG9uZy1saXZlZCwgdGhlIENETiBNb25pdG9yaW5nIFN5c3RlbSBpbnN0cnVjdHMgdGhlIFNG QyBDb250cm9sIFBsYW5lIEFwcGxpY2F0aW9uIHRvICBkeW5hbWljYWxseSBzd2l0Y2ggZnJvbSB0 aGUgZXhpc3Rpbmcgc2VydmljZSBjaGFpbiBBIHRvIGFub3RoZXIgc2VydmljZSBjaGFpbiBCIHdo aWNoIGluY2x1ZGVzIGEgQ0ROIGNhY2hlIGZvciBjYWNoaW5nIHRoZSAgY29udGVudCBpbiBhZGRp dGlvbiB0byBhbGwgb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIGluIHNlcnZpY2UgY2hhaW4gQSBp biB0aGUgc2FtZSBvcmRlci4gVGhpcyBpcyBkb25lIGJ5IGluc3RhbGxpbmcgYSBydWxlIGZvciB0 aGUgZmxvdyBjb3JyZXNwb25kaW5nIHRvIHRoZSBjb250ZW50IGluIHRoZSBTRkMgZWRnZSBzd2l0 Y2gvcm91dGVyLg0KMy4gICAgICBJZiB0aGUgbnVtYmVyIG9mIHVzZXJzIHZpZXdpbmcgdGhlIHNh bWUgY29udGVudCBmYWxscyBiZWxvdyBhbm90aGVyIHByZS1wcm9ncmFtbWVkIGRvd24tdGhyZXNo b2xkIGFuZCB0aGUgY29udGVudCBpcyBsb25nLWxpdmVkLCB0aGUgbW9uaXRvcmluZyBzZXJ2ZXIg aW5zdHJ1Y3RzIHRoZSBTRkMgQ29udHJvbCBQbGFuZSBBcHBsaWNhdGlvbiB0byBkeW5hbWljYWxs eSBzd2l0Y2ggdGhlIGZsb3cgZnJvbSB0aGUgZXhpc3Rpbmcgc2VydmljZSBjaGFpbiBCICh0aGUg b25lIHRoYXQgd2FzIHVzZWQgaW4gdGhlIHByZXZpb3VzIGV2ZW50KSB0byBzZXJ2aWNlIGNoYWlu IEEgKGFnYWluLCB3aGljaCBpbmNsdWRlcyBhbGwgb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIGlu IHNlcnZpY2UgY2hhaW4gQiBvdGhlciB0aGFuIHRoZSBDRE4gY2FjaGUpLiBUaGlzIGlzIGRvbmUg YnkgcmVtb3ZpbmcgdGhlIHByZXZpb3VzbHkgaW5zdGFsbGVkIHJ1bGUgZm9yIHRoZSBmbG93IGNv cnJlc3BvbmRpbmcgdG8gdGhlIGNvbnRlbnQgZnJvbSB0aGUgU0ZDIGVkZ2Ugc3dpdGNoL3JvdXRl ci4NClRoYW5rcywNClJhbWtpDQoNCkZyb206IExpemhvbmcgSmluIFttYWlsdG86bGl6aG8uamlu QGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAwNSwgMjAxNSAzOjE2IFBNDQpUbzog UmFta2kgS3Jpc2huYW4NCkNjOiBiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRvOmJpbGwud3VAaHVh d2VpLmNvbT47IGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPjsg c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gV0cg TEMgZm9yIGRyYWZ0LWlldGYtc2ZjLWxvbmctbGl2ZWQtZmxvdy11c2UtY2FzZXMtMDENCg0KVW5s aWtlIHRoZSBmaXJzdCBjYXNlIGFuZCB0aGUgdGhpcmQgY2FzZSwgaW4gdGhlIHNlY29uZCBjYXNl LCBjb250cm9sIHBsYW5lIGFwcGxpY2F0aW9uIGRvZXNuoa90IG5lZWQgdG8gaW5mb3JtIFNGQyBl ZGdlIHN3aXRjaC9yb3V0ZXIgYWJvdXQgdGhlIGNoYW5nZSB0byB0aGUgZXhpc3Rpbmcgc2Vydmlj ZSBjaGFpbiBzaW5jZSBpdCBpcyBzdGlsbA0KYSBzYW1lIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4u IEJ1dCBjb250cm9sIHBsYW5lIGFwcGxpY2F0aW9uIG5lZWRzIHRvIGNvbW11bmljYXRlIHdpdGgg dGhlIHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgaXMgcHJlY2VkaW5nIHRoZSBDRE4gY2FjaGUgYW5k IG9uZSB0aGF0IGlzIGZvbGxvd2luZyB0aGUgQ0ROIGNhY2hlIGFib3V0IGZvcndhcmRpbmcgY2hh bmdlLiBMZXQgbWUga25vdyBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QuDQpSYW1raTog WW91ciBzdGF0ZW1lbnQgaXMgY29uZnVzaW5nLiBUaGUgY2hhaW4gbmVlZHMgdG8gYmUgbWFuaXB1 bGF0ZWQgZm9yIGFsbCB0aGUgdXNlIGNhc2VzLg0KW1Fpbl06IEluIHRoZSBDRE4gY2FzZSwgdGhl IFNGQyBlZGdlIHN3aXRjaC9yb3V0ZXIgYXMgQ2xhc3NpZmllciBkb2VzbqGvdCBuZWVkIHRvIGtu b3cgd2hldGhlciBvciBub3QgeW91IGFkZCBhIG5ldyBzZXJ2aWNlIGZ1bmN0aW9uIGludG8gdGhl IGV4aXN0aW5nIHNlcnZpY2UgY2hhaW4gc2luY2UgdHJhZmZpYyBmbG93IHN0aWxsIGNvcnJlc3Bv bmRzIHRvIHRoZSBzYW1lIGNoYWluLiBCdXQgaW4gdGhlIHRyYW5zcGFyZW50IGZpcmV3YWxsIGNh c2UgYW5kIElQU0VDIEdhdGV3YXkgY2FzZSwgdGhlIGZsb3cgc2hvdWxkIGJlIHN3aXRjaGVkIGZy b20gb25lIHNlcnZpY2UgY2hhaW4gdG8gYW5vdGhlciBuZXcgY2hhaW4sIHRoZSBTRkMgZWRnZSBz d2l0Y2gvcm91dGVyIE1VU1Qga25vdyBiaW5kaW5nIGNoYW5nZSBiZXR3ZWVuIHRoZSB0cmFmZmlj IGZsb3cgYW5kIHRoZSBzZXJ2aWNlIGNoYWluLiBEb2VzIHRoaXMgY2xhcmlmeT8NClJhbWtpMTog WW91IGFyZSBtaXN0YWtlbiBpbiB0aGUgQ0ROIGNhc2UuIFBsZWFzZSBsb29rIGF0IG15IHByZXZp b3VzIGFuc3dlcnMgYW5kIEkgd291bGQgc3VnZ2VzdCB5b3UgdG8gY2FyZWZ1bGx5IHJlYWQgc2Vj dGlvbiAzLjEsIHRoZSBMb25nLXRhaWwgY29udGVudCBDRE4gZXZlbnQgc2VxdWVuY2UuDQpbTGl6 aG9uZ10gYWN0dWFsbHkgSSBoYXZlIHNpbWlsYXIgdW5kZXJzdGFuZGluZyBhcyBRaW4gd2hlbiBy ZWFkaW5nIHNlY3Rpb24gMy4xLiBUaGUgobBzZXJ2aWNlIGNoYWluobEgaW4gcG9pbnQgMiBjb3Vs ZCBiZSBleHBsYWluZWQgYXMgdGhlIHNhbWUgobBzZXJ2aWNlIGNoYWluobEgaW1wbGljaXRseSBz YWlkIGluIHBvaW50IDEuIFdlIG1heSBjaGFuZ2UgdGhlIGRlc2NyaXB0aW9uIG9mIHBvaW50IDIg YXMgYmVsb3c6DQqhsHRoZSBDRE4gTW9uaXRvcmluZyBTeXN0ZW0gaW5zdHJ1Y3RzIHRoZSBTRkMg Q29udHJvbCBQbGFuZSBBcHBsaWNhdGlvbiB0byBkeW5hbWljYWxseSBlc3RhYmxpc2ggdGhlIHNl cnZpY2UgY2hhaW4gd2l0aCBDRE4gY2FjaGUgZm9yIHRoYXQgY29udGVudKGxDQoNClJlZ2FyZHMN CkxpemhvbmcNCg0KUmVnYXJkcyENCi1RaW4NCreivP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXMgYXQgaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzJTIwYXQlMjBpZXRmLm9yZz5dILT6se0g SmltIEd1aWNoYXJkIChqZ3VpY2hhcikNCreiy83KsbzkOiAyMDE0xOoxMtTCMTXI1SAyMzoxNQ0K ytW8/sjLOiBzZmMgYXQgaWV0Zi5vcmc8bWFpbHRvOnNmYyUyMGF0JTIwaWV0Zi5vcmc+DQrW98zi OiBbc2ZjXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1zZmMtbG9uZy1saXZlZC1mbG93LXVzZS1jYXNl cy0wMQ0KDQpEZWFyIFdHOg0KDQpUaGlzIG5vdGUgYmVnaW5zIGEgMi13ZWVrIFdHIExDIG9uIGRy YWZ0LWlldGYtc2ZjLWxvbmctbGl2ZWQtZmxvdy11c2UtY2FzZXMuMDEudHh0Lg0KDQpUaGUgZG9j dW1lbnQgYXV0aG9ycyBoYXZlIGluZGljYXRlZCB0aGF0IHRoZXkgaGF2ZSBhZGRyZXNzZWQgYWxs IGtub3duIGNvbW1lbnRzIGFuZCB0aGF0IHRoZXJlIGFyZSBubyBvcGVuIGlzc3VlcyB3aXRoIHRo ZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50Lg0KDQpTdWJzdGFudGl2ZSBjb21tZW50 cyB0byB0aGUgbGlzdCBwbGVhc2UsIGVkaXRvcmlhbCBjb21tZW50cyBjYW4gZ28gZGlyZWN0bHkg dG8gdGhlIGRvY3VtZW50IGVkaXRvcnMuDQoNCkppbSAmIFRob21hcw0KDQoNCg0K --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E7D7F3EMBX021W3CA2exch_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

In order to effect dynamic changes in the service function chaining fo= r long lived flows, there are 2 paradigms that come to mind.   On= e is that when a service function determines that it no longer needs to participate for a given flow, the flow is switched t= o a different service function chain (path) that does not include the affec= ted service function.  

 

An alternate paradigm is to consider that the affected service functio= n is being dynamically bypassed =A8C that is, the chain/path is still the s= ame, but local state at the classifier and/or SFF=A1=AFs manage the fact that the service function has withdrawn = from the chain for that particular flow.    This second appr= oach does indeed imply stateful SFF=A1=AFs, but with the benefit of control= plane simplification.     With this second approach, c= ontrol plane involvement would be based on the desired level of optimization.&nbs= p;   If it is sufficient that the packets continue to follow the = original sequence of SFF=A1=AFs, even though the SFF=A1=AFs may no longer i= nvoke any of their service function instances for that flow, then no control plane coordination is necessary.   If, however, = it is desired even to avoid the =A1=B0null=A1=B1 SFF=A1=AFs for that flow, = then coordination will be necessary.

 

In draft-zhang-sfc-sch-03, we include a =A1=B0bypass=A1=B1 bit in the = fixed portion of the SCH header to realize the second approach, above:=

 

   B bit: The B (Bypa= ss) bit, when set to 1, it is used by a Service

      = Function to signal to its Service Function Forwarder that no

      = further packets are to be sent to it for the flow specified in

      = encapsulated packet.

 

Thanks.

 

    Ron

 

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On= Behalf Of Ramki Krishnan
Sent: Monday, January 5, 2015 5:15 AM
To: Lizhong Jin
Cc: jguichar@cisco.com; bill.wu@huawei.com; sfc@ietf.org
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-case= s-01

 

Even in t= he second case, the SFC control plane application *does = need* to inform the SFC edge switch/router about the change to the serv= ice chain. Perhaps the existing text does not express this aspect clearly. = We will clarify this in the next revision of the document using text along the lines described below.

 

Event Sequence for = CDN (modified version)

 

1= . The CDN Monitoring System monitors the numbe= rs of users and type of content being accessed. By default, we assume the C= DN Cache is bypassed.

2.      If the number of users viewing the same content exc= eeds a pre-programmed up-threshold and the content is long-lived, the CDN M= onitoring System instructs the SFC Control Plane Application to  dynam= ically switch from the existing service chain A to another service chain B which includes a CDN cache for caching = the  content in addition to all of the service functions in service ch= ain A in the same order. This is done by installing a rule for the flow cor= responding to the content in the SFC edge switch/router.

3.      If the number of users viewing the same content fal= ls below another pre-programmed down-threshold and the content is long-live= d, the monitoring server instructs the SFC Control Plane Application to dyn= amically switch the flow from the existing service chain B (the one that was used in the previous event) to = service chain A (again, which includes all of the service functions in serv= ice chain B other than the CDN cache). This is done by removing the previou= sly installed rule for the flow corresponding to the content from the SFC edge switch/router. <= /p>

Thanks,

Ramki

 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: Monday, January 05, 2015 3:16 PM
To: Ramki Krishnan
Cc: bill.wu@huawei.com; jguichar@cisco.com; sfc@ietf.org Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-case= s-01

 

Unlike the first ca= se and the third case, in the second case, control plane application doesn= =A1=AFt need to inform SFC edge switch/router about the change to the existing service chain since it is still

a same service function chai= n. But control plane application needs to communicate with the service func= tions that is preceding the CDN cache and one that is following the CDN cac= he about forwarding change. Let me know if my understanding is correct.

Ramki: Your statement is confusing. = The chain needs to be manipulated for all the use cases.

[Qin]: In the CDN c= ase, the SFC edge switch/router as Classifier doesn=A1=AFt need to know whe= ther or not you add a new service function into the existing service chain since traffic flow still corresponds to th= e same chain. But in the transparent firewall case and IPSEC Gateway case, = the flow should be switched from one service chain to another new chain, th= e SFC edge switch/router MUST know binding change between the traffic flow and the service chain. Does this c= larify?

Ramki1: You are mistaken in the CDN = case. Please look at my previous answers and I would suggest you to careful= ly read section 3.1, the Long-tail content CDN event sequence.

[Lizhong] actually I have similar un= derstanding as Qin when reading section 3.1. The =A1=B0service chain=A1=B1 = in point 2 could be explained as the same =A1=B0service chain=A1=B1 implicitly said in point 1. We may change the description of p= oint 2 as below:

=A1=B0the CDN Monitoring System inst= ructs the SFC Control Plane Application to dynamically establish the servic= e chain with CDN cache for that content=A1=B1

 

Regards

Lizhong

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces at ietf= .org] =B4=FA=B1=ED <= /span>Jim Guichard (jguichar)
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1= 2=D4=C215=C8=D5 23:15
=CA=D5=BC=FE=C8=CB: sfc at= ietf.org
=D6=F7=CC=E2: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-= cases-01

 =

Dear WG:

 

This note begins a 2-= week WG LC on draft-ietf-sfc-long-lived-flow-use-cases.01.txt.

 

The document authors = have indicated that they have addressed all known comments and that there a= re no open issues with the current version of the document. 

 

Substantive comments = to the list please, editorial comments can go directly to the document edit= ors.

 

Jim & Thomas

 

 

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B2E7D7F3EMBX021W3CA2exch_-- From nobody Mon Jan 5 10:49:43 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1851A87C1 for ; Mon, 5 Jan 2015 10:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWEU0ZXDcRRi for ; Mon, 5 Jan 2015 10:49:39 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4101A87AA for ; Mon, 5 Jan 2015 10:49:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DDE981C01EE; Mon, 5 Jan 2015 10:49:38 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-121.clppva.east.verizon.net [70.106.135.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E8B9F1C0159; Mon, 5 Jan 2015 10:49:36 -0800 (PST) Message-ID: <54AADCBA.1050903@joelhalpern.com> Date: Mon, 05 Jan 2015 13:49:30 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ron Parker , Ramki Krishnan , Lizhong Jin References: <00ce01d028cc$75733bb0$6059b310$@gmail.com> <0b46db1f32cf4b16aa33be576642f027@HQ1WP-EXMB11.corp.brocade.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bneJRshl5CdbwwmD8VTWUKfscH8 Cc: "jguichar@cisco.com" , "bill.wu@huawei.com" , "sfc@ietf.org" Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 18:49:42 -0000 The bypass bit is clearly useful (which is why we already have a draft calling for it). Thank you for including it in the SCH work. There are clearly plenty of cases where that is not sufficient, and the control interactions will be needed to make the adjustments. So I believe we need both tools. Yours, Joel On 1/5/15 9:31 AM, Ron Parker wrote: > In order to effect dynamic changes in the service function chaining for > long lived flows, there are 2 paradigms that come to mind. One is that > when a service function determines that it no longer needs to > participate for a given flow, the flow is switched to a different > service function chain (path) that does not include the affected service > function. > > An alternate paradigm is to consider that the affected service function > is being dynamically bypassed – that is, the chain/path is still the > same, but local state at the classifier and/or SFF’s manage the fact > that the service function has withdrawn from the chain for that > particular flow. This second approach does indeed imply stateful > SFF’s, but with the benefit of control plane simplification. With > this second approach, control plane involvement would be based on the > desired level of optimization. If it is sufficient that the packets > continue to follow the original sequence of SFF’s, even though the SFF’s > may no longer invoke any of their service function instances for that > flow, then no control plane coordination is necessary. If, however, it > is desired even to avoid the “null†SFF’s for that flow, then > coordination will be necessary. > > In draft-zhang-sfc-sch-03, we include a “bypass†bit in the fixed > portion of the SCH header to realize the second approach, above: > > B bit: The B (Bypass) bit, when set to 1, it is used by a Service > > Function to signal to its Service Function Forwarder that no > > further packets are to be sent to it for the flow specified in > > encapsulated packet. > > Thanks. > > Ron > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ramki Krishnan > *Sent:* Monday, January 5, 2015 5:15 AM > *To:* Lizhong Jin > *Cc:* jguichar@cisco.com; bill.wu@huawei.com; sfc@ietf.org > *Subject:* Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Even in the second case, the SFC control plane application **does need** > to inform the SFC edge switch/router about the change to the service > chain. Perhaps the existing text does not express this aspect clearly. > We will clarify this in the next revision of the document using text > along the lines described below. > > Event Sequence for CDN (modified version) > > 1.The CDN Monitoring System monitors the numbers of users and type of > content being accessed. By default, we assume the CDN Cache is bypassed. > > 2.If the number of users viewing the same content exceeds a > pre-programmed up-threshold and the content is long-lived, the CDN > Monitoring System instructs the SFC Control Plane Application to > dynamically switch from the existing service chain A to another service > chain B which includes a CDN cache for caching the content in addition > to all of the service functions in service chain A in the same order. > This is done by installing a rule for the flow corresponding to the > content in the SFC edge switch/router. > > 3.If the number of users viewing the same content falls below another > pre-programmed down-threshold and the content is long-lived, the > monitoring server instructs the SFC Control Plane Application to > dynamically switch the flow from the existing service chain B (the one > that was used in the previous event) to service chain A (again, which > includes all of the service functions in service chain B other than the > CDN cache). This is done by removing the previously installed rule for > the flow corresponding to the content from the SFC edge switch/router. > > Thanks, > > Ramki > > *From:* Lizhong Jin [mailto:lizho.jin@gmail.com] > *Sent:* Monday, January 05, 2015 3:16 PM > *To:* Ramki Krishnan > *Cc:* bill.wu@huawei.com ; jguichar@cisco.com > ; sfc@ietf.org > *Subject:* Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Unlike the first case and the third case, in the second case, control > plane application doesn’t need to inform SFC edge switch/router about > the change to the existing service chain since it is still > > a same service function chain. But control plane application needs to > communicate with the service functions that is preceding the CDN cache > and one that is following the CDN cache about forwarding change. Let me > know if my understanding is correct. > > Ramki: Your statement is confusing. The chain needs to be manipulated > for all the use cases. > > [Qin]: In the CDN case, the SFC edge switch/router as Classifier doesn’t > need to know whether or not you add a new service function into the > existing service chain since traffic flow still corresponds to the same > chain. But in the transparent firewall case and IPSEC Gateway case, the > flow should be switched from one service chain to another new chain, the > SFC edge switch/router MUST know binding change between the traffic flow > and the service chain. Does this clarify? > > Ramki1: You are mistaken in the CDN case. Please look at my previous > answers and I would suggest you to carefully read section 3.1, the > Long-tail content CDN event sequence. > > [Lizhong] actually I have similar understanding as Qin when reading > section 3.1. The “service chain†in point 2 could be explained as the > same “service chain†implicitly said in point 1. We may change the > description of point 2 as below: > > “the CDN Monitoring System instructs the SFC Control Plane Application > to dynamically establish the service chain with CDN cache for that content†> > Regards > > Lizhong > > Regards! > > -Qin > > *å‘件人**:*sfc [mailto:sfc-bounces at ietf.org > ]*代表*Jim Guichard (jguichar) > *å‘é€æ—¶é—´:*2014å¹´12月15æ—¥23:15 > *收件人:*sfc at ietf.org > *主题:*[sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Dear WG: > > This note begins a 2-week WG LC on > draft-ietf-sfc-long-lived-flow-use-cases.01.txt. > > The document authors have indicated that they have addressed all known > comments and that there are no open issues with the current version of > the document. > > Substantive comments to the list please, editorial comments can go > directly to the document editors. > > Jim & Thomas > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jan 5 12:04:18 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693EE1A89B1; Mon, 5 Jan 2015 12:04:15 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3KShJBwFq_A; Mon, 5 Jan 2015 12:04:11 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963241A89B3; Mon, 5 Jan 2015 11:54:35 -0800 (PST) Received: by mail-yk0-f176.google.com with SMTP id 79so3746133ykr.21; Mon, 05 Jan 2015 11:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iYxJzaeY23XBtuKiaXHE0g4032bVqTNKGPO9xrBf0tM=; b=aETd6sFxkhpRMQ6r36cdgviMDuaR0uuiMVCSwh1f9vXFGMasKTNJgheyu7mPLthwY+ jm4EAiLTu336RgZn7PAJ+q539P7a/xl47q8YCFpVR5+PK18zktgEM9bLXsedteqYD6UE eFAkCq5vUZhdDsoDAetJv6elBE1QyBneo8gLCePBnZO5zzjMEnclGSegVQj2Qd3h9tZE 7SvSbq1rKY1VcRoZKBJUTgr6UKGZe8pE/Fzpvtq8CmIAKVboRMhwab+nPma9yR7LYyWD VZL91fE9a2wCChLXAIeASomjRzQeql3hwytEPuukkydYgCpx+3HMidIeWPSUfFGAiGK4 E95Q== MIME-Version: 1.0 X-Received: by 10.170.39.70 with SMTP id 67mr66432293ykh.36.1420487674733; Mon, 05 Jan 2015 11:54:34 -0800 (PST) Received: by 10.170.133.18 with HTTP; Mon, 5 Jan 2015 11:54:34 -0800 (PST) In-Reply-To: <54A9994D.1050701@joelhalpern.com> References: <20150104175311.20228.59840.idtracker@ietfa.amsl.com> <54A98563.3090100@joelhalpern.com> <54A99261.4000306@cs.tcd.ie> <54A99429.9070209@joelhalpern.com> <54A995AA.8000909@cs.tcd.ie> <54A9994D.1050701@joelhalpern.com> Date: Mon, 5 Jan 2015 14:54:34 -0500 Message-ID: From: Alia Atlas To: "Joel M. Halpern" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary=001a11379da242aa7a050bed0f02 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/B3sxbTVJRLr4LQuZB2nbSt7tN_k Cc: draft-ietf-sfc-problem-statement@tools.ietf.org, "sfc-chairs@tools.ietf.org" , The IESG , Stephen Farrell Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 20:04:15 -0000 --001a11379da242aa7a050bed0f02 Content-Type: text/plain; charset=UTF-8 [Just adding the SFC WG, since they're not on the recipients list] Alia On Sun, Jan 4, 2015 at 2:49 PM, Joel M. Halpern wrote: > I am not understanding the question. SFC depends upon classification. But > it does not depend upon any specific classification. If all it has is > source and destiantion IP, then that is all it uses. If it has sources of > out of band information that it trusts to tell it that SPI X goes to > service chain Y, then it uses that. If it can magically read through > cryptography and know what application is actually running, then it can do > that. In some networks, this will result in something that is not useful. > In others, it will be very useful. That proportion may change over time, > based on many factors. If that is to be addressed anywhere, it would be in > an applicability or deployment document. But frankly, with so many > different uses envisioned, I don't expect it to be discussed anywhere. In > particular, I just can't see it in the problem statement document. Maybe > others see it differently and can suggest a sensible way to cover it. > > Yours, > Joel > > > On 1/4/15 2:34 PM, Stephen Farrell wrote: > >> >> >> On 04/01/15 19:27, Joel M. Halpern wrote: >> >>> I agree with regard to potential impact on the other parts of the >>> network from SFC infrastructure. >>> >> >> Grand. >> >> I do not know where the questions of which services can, should, or must >>> not be provided belongs. But since SFC is carefully agnostic of the >>> service specifics, I don't think it belongs here. If OPS wants to try >>> to write that document, I wish them luck. >>> >> >> I think we're talking at cross purposes. >> >> I would like to know how and when the SFC WG are going to address >> the tension to which I referred, in their design of SFC. >> >> If SFC inherently depends on classification and metadata (as this >> draft states) then that has to be a relevant question to ask. >> >> S. >> >> >> >>> Yours, >>> Joel >>> >>> On 1/4/15 2:20 PM, Stephen Farrell wrote: >>> >>>> >>>> Hi Joel, >>>> >>>> On 04/01/15 18:24, Joel M. Halpern wrote: >>>> >>>>> I will leave most of these for the authors or chairs to respond to. >>>>> There is one aspect where as shepherd I would like to ask for >>>>> clarification. >>>>> >>>>> You raise the question of the implications of RFC 7258. I am not sure >>>>> what aspect you expect SFC and the SFC problem statement to deal with. >>>>> Given both RFC 7258 and other factors, we expect to see more and more >>>>> of >>>>> the traffic encrypted. That will mean that some kinds of services, and >>>>> some kinds of classification, can not be used with such traffic. >>>>> >>>> >>>> Right. And/or that some folks might feel they're losing out by not >>>> blocking such traffic so they can do their whizzy classification >>>> etc. >>>> >>>> That >>>>> does not mean that the SFC problems don't apply. Nor that operators do >>>>> not envision offering services to / regarding such traffic. >>>>> >>>> >>>> Sure. But it does mean there's an obvious tension between some >>>> security and privacy requirements and some SFC requirements/goals. >>>> >>>> It is not the job of SFC or the SFC problem statement to discuss issues >>>>> like whether an operator can deploy firewalls or virus scanners that >>>>> work on encrypted traffic. This problem statement doesn't care about >>>>> that. >>>>> >>>>> So what is it you would like to see regarding your point 2 in the >>>>> problem statement? >>>>> >>>> >>>> What I'm trying to understand is where those issues will be addressed >>>> (esp. given discuss point #1) and why the problem statement doesn't >>>> consider the tension referred to above to be a relevant problem. >>>> >>>> The security and mangeability issues that I understand the charter to >>>>> talk about are the security and managability of the SFC infrastructure. >>>>> >>>> >>>> And presumably any notable impacts of that SFC infrastructure on the >>>> security or manageability of other parts of the network. >>>> >>>> Cheers, >>>> S. >>>> >>>> >>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 1/4/15 12:53 PM, Stephen Farrell wrote: >>>>> >>>>>> Stephen Farrell has entered the following ballot position for >>>>>> draft-ietf-sfc-problem-statement-10: Discuss >>>>>> >>>>>> When responding, please keep the subject line intact and reply to all >>>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>>> this >>>>>> introductory paragraph, however.) >>>>>> >>>>>> >>>>>> Please refer to >>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>> >>>>>> >>>>>> The document, along with other ballot positions, can be found here: >>>>>> http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------ >>>>>> ---------- >>>>>> DISCUSS: >>>>>> ------------------------------------------------------------ >>>>>> ---------- >>>>>> >>>>>> >>>>>> I have two points to discuss. Hopefully, they should >>>>>> be fairly easily resolved though there may be a bit >>>>>> of work needed. >>>>>> >>>>>> (1) The secdir review [1] I think does a good job of >>>>>> identifying some real security issues that will emerege >>>>>> and that are a consequence of the three bits of >>>>>> architecture described here. Inclusion of some >>>>>> variation of the 4 bullets from [1] would be at least a >>>>>> good start in improving what is clearly an deficient >>>>>> security considerations section (as Adrian correctly >>>>>> said). I think that plus some text about other fairly >>>>>> obvious issues (e.g. slow middlebox s/w update has >>>>>> prevented applying some patches or slowed down >>>>>> deployment of new security features, recognising the >>>>>> tension between SFC and privacy/confidentiality,...) >>>>>> should be fairly easily done with a little work from >>>>>> someone. >>>>>> >>>>>> [1] >>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05351.html >>>>>> >>>>>> (2) The IAB have encouraged us to encrypt everything >>>>>> and that, and RFC 7258, would seem to me to be very >>>>>> much in tension with some aspects of this work. And the >>>>>> WG charter says "The SFC WG will closely consider and >>>>>> address the management and security implications when >>>>>> documenting these deliverables." I see no real evidence >>>>>> that that has happened so far from this particular >>>>>> deliverable so my question is: when will you tackle the >>>>>> security and privacy considerations and the obvious >>>>>> tension between doing more inside the n/w vs. >>>>>> protecting users and applications? Also - don't you >>>>>> consider that DoS attacks are a problem that could be >>>>>> mitigated or made worse via SFC? And isn't it clear >>>>>> that privacy could easily be made worse if SFC is >>>>>> developed without real consideration of privacy >>>>>> trade-offs? Resolving this discuss point would ideally >>>>>> be done by someone pointing me at WG drafts that do >>>>>> substantively address these issues. (I've not looked, >>>>>> so it's quite possible that will be done, and if so, >>>>>> great.) If that is not currently possible, then we >>>>>> should probably talk some more about when and how that >>>>>> work is going to happen. (Translating that last bit: >>>>>> I'm not trying to insist that the security and privacy >>>>>> work needed for SFC be finished already, but I'd like >>>>>> to be confident that it will happen, so this DISCUSS is >>>>>> perhaps more for chatting with the AD and WG chairs >>>>>> rather than the authors of this deliverable.) >>>>>> >>>>>> >>>>>> ------------------------------------------------------------ >>>>>> ---------- >>>>>> COMMENT: >>>>>> ------------------------------------------------------------ >>>>>> ---------- >>>>>> >>>>>> >>>>>> >>>>>> - There are no IPR declarations on this directly >>>>>> visible from the agenda (I've seen and reported another >>>>>> bug near there today, not sure if this is related) but >>>>>> there is one on this and there are two on a document >>>>>> that this replaces, with one (#2285) being RAND with >>>>>> possible royalty/fee. And the other (#2304) gets me a >>>>>> 404 in the DB while the link is to #2307. I see the >>>>>> write-up says the WG chairs figure that's ok, but it >>>>>> only mentions 1 disclosure that it says caused some >>>>>> concern. So this is just to check all's well, given the >>>>>> confusing nature of the above. (Possibly the confusion >>>>>> is just caused by a short-lived tracker bug.) >>>>>> >>>>>> - 1.1, RFC6967 is referenced as if it were a spec for >>>>>> HOST_ID. But it is not. HOST_ID remains highly >>>>>> controversial and using it as an example here is not a >>>>>> good plan, as that might be used to claim that HOST_ID >>>>>> has more acceptance than is the case. Simplest thing is >>>>>> to just delete that. I'd also argue that HTTP header >>>>>> "enrichment" has been shown to cause many >>>>>> vulnerabilities so would also be better deleted. And >>>>>> it's noticeable that the examples given are all (or >>>>>> almost all) ones that will be made harder by more >>>>>> cryptography, which the IAB and RFC7258 tell us is >>>>>> good. Don't you have non-invasive examples that >>>>>> could be added? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > --001a11379da242aa7a050bed0f02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Just adding the SFC WG, since they're not on the reci= pients list]

Alia

On Sun, Jan 4, 2015 at 2:49 PM, Joel M. = Halpern <jmh@joelhalpern.com> wrote:
I am not understanding the question.=C2=A0 SFC depends upon c= lassification. But it does not depend upon any specific classification.=C2= =A0 If all it has is source and destiantion IP, then that is all it uses.= =C2=A0 If it has sources of out of band information that it trusts to tell = it that SPI X goes to service chain Y, then it uses that.=C2=A0 If it can m= agically read through cryptography and know what application is actually ru= nning, then it can do that.=C2=A0 In some networks, this will result in som= ething that is not useful.=C2=A0 In others, it will be very useful.=C2=A0 T= hat proportion may change over time, based on many factors.=C2=A0 If that i= s to be addressed anywhere, it would be in an applicability or deployment d= ocument.=C2=A0 But frankly, with so many different uses envisioned, I don&#= 39;t expect it to be discussed anywhere.=C2=A0 In particular, I just can= 9;t see it in the problem statement document.=C2=A0 Maybe others see it dif= ferently and can suggest a sensible way to cover it.

Yours,
Joel


On 1/4/15 2:34 PM, Stephen Farrell wrote:


On 04/01/15 19:27, Joel M. Halpern wrote:
I agree with regard to potential impact on the other parts of the
network from SFC infrastructure.

Grand.

I do not know where the questions of which services can, should, or must not be provided belongs.=C2=A0 But since SFC is carefully agnostic of the service specifics, I don't think it belongs here.=C2=A0 If OPS wants to= try
to write that document, I wish them luck.

I think we're talking at cross purposes.

I would like to know how and when the SFC WG are going to address
the tension to which I referred, in their design of SFC.

If SFC inherently depends on classification and metadata (as this
draft states) then that has to be a relevant question to ask.

S.



Yours,
Joel

On 1/4/15 2:20 PM, Stephen Farrell wrote:

Hi Joel,

On 04/01/15 18:24, Joel M. Halpern wrote:
I will leave most of these for the authors or chairs to respond to.
There is one aspect where as shepherd I would like to ask for
clarification.

You raise the question of the implications of RFC 7258.=C2=A0 I am not sure=
what aspect you expect SFC and the SFC problem statement to deal with.
Given both RFC 7258 and other factors, we expect to see more and more of the traffic encrypted.=C2=A0 That will mean that some kinds of services, an= d
some kinds of classification, can not be used with such traffic.

Right. And/or that some folks might feel they're losing out by not
blocking such traffic so they can do their whizzy classification
etc.

=C2=A0 =C2=A0That
does not mean that the SFC problems don't apply.=C2=A0 Nor that operato= rs do
not envision offering services to / regarding such traffic.

Sure. But it does mean there's an obvious tension between some
security and privacy requirements and some SFC requirements/goals.

It is not the job of SFC or the SFC problem statement to discuss issues
like whether an operator can deploy firewalls or virus scanners that
work on encrypted traffic.=C2=A0 This problem statement doesn't care ab= out
that.

So what is it you would like to see regarding your point 2 in the
problem statement?

What I'm trying to understand is where those issues will be addressed (esp. given discuss point #1) and why the problem statement doesn't
consider the tension referred to above to be a relevant problem.

The security and mangeability issues that I understand the charter to
talk about are the security and managability of the SFC infrastructure.

And presumably any notable impacts of that SFC infrastructure on the
security or manageability of other parts of the network.

Cheers,
S.



Yours,
Joel

On 1/4/15 12:53 PM, Stephen Farrell wrote:
Stephen Farrell has entered the following ballot position for
draft-ietf-sfc-problem-statement-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to
http://www.ietf.org/iesg/statement/discuss-criteria.<= /u>html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-sfc-= problem-statement/



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


I have two points to discuss. Hopefully, they should
be fairly easily resolved though there may be a bit
of work needed.

(1) The secdir review [1] I think does a good job of
identifying some real security issues that will emerege
and that are a consequence of the three bits of
architecture described here. Inclusion of some
variation of the 4 bullets from [1] would be at least a
good start in improving what is clearly an deficient
security considerations section (as Adrian correctly
said). I think that plus some text about other fairly
obvious issues (e.g. slow middlebox s/w update has
prevented applying some patches or slowed down
deployment of new security features, recognising the
tension between SFC and privacy/confidentiality,...)
should be fairly easily done with a little work from
someone.

=C2=A0 =C2=A0 =C2=A0 [1]
https://www.ietf.org/mail-archive/web/secdir/c= urrent/msg05351.html

(2) The IAB have encouraged us to encrypt everything
and that, and RFC 7258, would seem to me to be very
much in tension with some aspects of this work. And the
WG charter says "The SFC WG will closely consider and
address the management and security implications when
documenting these deliverables." I see no real evidence
that that has happened so far from this particular
deliverable so my question is: when will you tackle the
security and privacy considerations and the obvious
tension between doing more inside the n/w vs.
protecting users and applications? Also - don't you
consider that DoS attacks are a problem that could be
mitigated or made worse via SFC?=C2=A0 And isn't it clear
that privacy could easily be made worse if SFC is
developed without real consideration of privacy
trade-offs? Resolving this discuss point would ideally
be done by someone pointing me at WG drafts that do
substantively address these issues. (I've not looked,
so it's quite possible that will be done, and if so,
great.) If that is not currently possible, then we
should probably talk some more about when and how that
work is going to happen.=C2=A0 (Translating that last bit:
I'm not trying to insist that the security and privacy
work needed for SFC be finished already, but I'd like
to be confident that it will happen, so this DISCUSS is
perhaps more for chatting with the AD and WG chairs
rather than the authors of this deliverable.)


-------------------------------------------------------------= ---------
COMMENT:
-------------------------------------------------------------= ---------



- There are no IPR declarations on this directly
visible from the agenda (I've seen and reported another
bug near there today, not sure if this is related) but
there is one on this and there are two on a document
that this replaces, with one (#2285) being RAND with
possible royalty/fee. And the other (#2304) gets me a
404 in the DB while the link is to #2307. I see the
write-up says the WG chairs figure that's ok, but it
only mentions 1 disclosure that it says caused some
concern. So this is just to check all's well, given the
confusing nature of the above. (Possibly the confusion
is just caused by a short-lived tracker bug.)

- 1.1, RFC6967 is referenced as if it were a spec for
HOST_ID. But it is not. HOST_ID remains highly
controversial and using it as an example here is not a
good plan, as that might be used to claim that HOST_ID
has more acceptance than is the case. Simplest thing is
to just delete that. I'd also argue that HTTP header
"enrichment" has been shown to cause many
vulnerabilities so would also be better deleted.=C2=A0 And
it's noticeable that the examples given are all (or
almost all) ones that will be made harder by more
cryptography, which the IAB and RFC7258 tell us is
good. Don't you have non-invasive examples that
could be added?









--001a11379da242aa7a050bed0f02-- From nobody Mon Jan 5 14:13:05 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAA81A900A; Mon, 5 Jan 2015 14:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV3-XpdkWQKE; Mon, 5 Jan 2015 14:13:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD6E1A0126; Mon, 5 Jan 2015 14:13:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105221301.27337.54915.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 14:13:01 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4IZnp8R20ZlmSEwz8XT5DwIc4dA Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-architecture-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 22:13:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining (SFC) Architecture Authors : Joel Halpern Carlos Pignataro Filename : draft-ietf-sfc-architecture-03.txt Pages : 27 Date : 2015-01-05 Abstract: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-architecture-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 5 14:18:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8D61A9009 for ; Mon, 5 Jan 2015 14:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVYI-Ay-cYEc for ; Mon, 5 Jan 2015 14:18:37 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94481A8AE1 for ; Mon, 5 Jan 2015 14:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2042; q=dns/txt; s=iport; t=1420496317; x=1421705917; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NRdhnWyTONHzNyC1EWXPh0KNr4u253CggERJZOJH7dA=; b=XXjrE8QNILYaYXAchO7+yB4ySG8ESr29CgWjqZGuYZlVTJo2/o97LhPX 4SljECe5jPDFFanwUPWu+Qiv1h8B5sJDd5Om9BDa7kQnxjhc1sGatZWp4 PHjGcibJ8417gtcJzqNIRhL3mPpGtTE+pevqAnmBfFaS1xpnRIfB4E4Rf s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgFACkNq1StJV2S/2dsb2JhbABcgmQiUlMFBMN9ghsKhXMCgQkWAQEBAQF9hAwBAQEDAQEBATc0EAsCAQgSBh4QJwsXDgIEEwkSiAkIAQcFvXIBAQEBAQEBAQIBAQEBAQEBAQEBARePRDqDFoETBYw+gVeDP4U0gQ0wgjWNXiKDbm+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,702,1413244800"; d="scan'208";a="110543627" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 05 Jan 2015 22:18:37 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t05MIak1028754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 5 Jan 2015 22:18:37 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 16:18:36 -0600 From: "Carlos Pignataro (cpignata)" To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-architecture-03.txt Thread-Index: AQHQKTTc6S2Q4AzP0ka6l2cWQm6+oZyyfUQA Date: Mon, 5 Jan 2015 22:18:35 +0000 Message-ID: <1DC8E952-F767-4EB4-B4CF-BFB2D155C194@cisco.com> References: <20150105221301.27337.54915.idtracker@ietfa.amsl.com> In-Reply-To: <20150105221301.27337.54915.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.242.140] Content-Type: text/plain; charset="us-ascii" Content-ID: <1A117CCADAC13242A35E2516ED8E8D32@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9g2qCst6YXCvJ-BYT-NVBsx-D6I Subject: Re: [sfc] I-D Action: draft-ietf-sfc-architecture-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 22:18:40 -0000 Hi, SFC, This new revision attempts to address all the WGLC and outstanding comments= received thus far on the SFC Architecture document. Please review, and let us know if there is something that we missed. Thanks! Carlos. > On Jan 5, 2015, at 5:13 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Service Function Chaining Working Group = of the IETF. >=20 > Title : Service Function Chaining (SFC) Architecture > Authors : Joel Halpern > Carlos Pignataro > Filename : draft-ietf-sfc-architecture-03.txt > Pages : 27 > Date : 2015-01-05 >=20 > Abstract: > This document describes an architecture for the specification, > creation, and ongoing maintenance of Service Function Chains (SFC) in > a network. It includes architectural concepts, principles, and > components used in the construction of composite services through > deployment of SFCs, with a focus on those to be standardized in the > IETF. This document does not propose solutions, protocols, or > extensions to existing protocols. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sfc-architecture-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-architecture-03 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jan 6 07:32:16 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7701A8827 for ; Tue, 6 Jan 2015 07:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.461 X-Spam-Level: X-Spam-Status: No, score=-4.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9EM8-GHCQbu for ; Tue, 6 Jan 2015 07:32:06 -0800 (PST) Received: from mxe01.gs.com (mxe01.gs.com [204.4.178.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABBE1A00DB for ; Tue, 6 Jan 2015 07:31:36 -0800 (PST) Received: from pps.filterd (gsppacdp02sd.idz.gs.com [127.0.0.1]) by gsppacdp02sd.idz.gs.com (8.14.5/8.14.5) with SMTP id t06FPsJX030685; Tue, 6 Jan 2015 10:31:24 -0500 Received: from gsppabdp04nd.inz.gs.com ([10.204.43.243]) by gsppacdp02sd.idz.gs.com with ESMTP id 1rrf9g399m-1; Tue, 06 Jan 2015 10:31:24 -0500 Received: from pps.filterd (gsppabdp04nd.inz.gs.com [127.0.0.1]) by gsppabdp04nd.inz.gs.com (8.14.5/8.14.5) with SMTP id t06FTAjL000556; Tue, 6 Jan 2015 10:31:23 -0500 Received: from gshcbdp15ex.firmwide.corp.gs.com (gshcbdp15ex.firmwide.corp.gs.com [10.135.172.24]) by gsppabdp04nd.inz.gs.com with ESMTP id 1rrhqh0dc3-1; Tue, 06 Jan 2015 10:31:23 -0500 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp15ex.firmwide.corp.gs.com ([10.135.172.24]) with mapi; Tue, 6 Jan 2015 10:31:23 -0500 From: "Zarny, Myo" To: "'Ramki Krishnan'" , "'Lizhong Jin'" Date: Tue, 6 Jan 2015 10:31:22 -0500 Thread-Topic: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AdAoy6bOS6ROISegTU+mGS2rLqpB1wAA3cPQADylPZA= Message-ID: References: <00ce01d028cc$75733bb0$6059b310$@gmail.com> <0b46db1f32cf4b16aa33be576642f027@HQ1WP-EXMB11.corp.brocade.com> In-Reply-To: <0b46db1f32cf4b16aa33be576642f027@HQ1WP-EXMB11.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230716FD982AGSCMAMP19EXfi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-06_06:2015-01-06,2015-01-06,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-06_06:2015-01-06,2015-01-06,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/eP5oxxJLTWjBy1OXiVl2TaNDe_k Cc: "'jguichar@cisco.com'" , "'bill.wu@huawei.com'" , "'sfc@ietf.org'" Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:32:10 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230716FD982AGSCMAMP19EXfi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBnZXQgdGhlIHVzZSBjYXNlcyAxIGFuZCAzLiBJIHNlZSB0aGUgcmF0aW9uYWxlIGZvciB0aGUg Q0ROIHVzZSBjYXNlIGFzIHdlbGwgYnV0IEkgd29uZGVyIGhvdyBpdKGvbGwgYmUgZG9uZaGqaWYg dGhlIHVzZSBjYXNlIGlzIHRvIGluc2VydCBhIGNhY2hlIGR5bmFtaWNhbGx5IG1pZHN0cmVhbSBk dXJpbmcgbG9uZy1saXZlZCBmbG93cywgYXMgb3Bwb3NlZCB0byBpbnNlcnRpbmcgdGhlIGNhY2hl IG9ubHkgZm9yIHRoZSBuZXcgY29ubmVjdGlvbnMuDQoNCk15IHF1ZXN0aW9ucyBhcmU6DQoNCqGk ICAgICAgICAgV2hlbiB5b3Whr3JlIGludHJvZHVjaW5nIHRoZSBjYWNoZSBkeW5hbWljYWxseSBt aWRzdHJlYW0sIGhvdyB3b3VsZCBsb25nLWxpdmVkIGZsb3dzIGJlIGhhbmRsZWQ/IEhvdyBkb2Vz IHRoZSAobmV3KSBjYWNoZSBwaWNrIHVwIHdoZXJlIHRoZSBvcmlnaW5hbCBjb250ZW50IHNlcnZl ciBoYXMganVzdCBsZWZ0IG9mZj8NCg0KoaQgICAgICAgICBBbmQgYXJlIHlvdSBhc3N1bWluZyB0 aGF0IHRoZSBjYWNoZSB3b3VsZCBoYXZlIGEgVklQIHRoYXQgcmVwcmVzZW50cyB0aGUgZGVzdGlu YXRpb24gSVAgb2YgdGhlIGZsb3dzPyBJIHRoaW5rIGl0oa9sbCBoYXZlIHRvIHNpbmNlIFNGQyBj YW6hr3QgY2hhbmdlIHRoZSBETlMgY2FjaGUgb2YgdGhlIGNsaWVudC4NCg0KTXlvDQoNCkZyb206 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFta2kgS3Jp c2huYW4NClNlbnQ6IDUgSmFudWFyeSAyMDE1IDU6MTUgQU0NClRvOiBMaXpob25nIEppbg0KQ2M6 IGpndWljaGFyQGNpc2NvLmNvbTsgYmlsbC53dUBodWF3ZWkuY29tOyBzZmNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbc2ZjXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1zZmMtbG9uZy1saXZlZC1mbG93 LXVzZS1jYXNlcy0wMQ0KDQpFdmVuIGluIHRoZSBzZWNvbmQgY2FzZSwgdGhlIFNGQyBjb250cm9s IHBsYW5lIGFwcGxpY2F0aW9uICpkb2VzIG5lZWQqIHRvIGluZm9ybSB0aGUgU0ZDIGVkZ2Ugc3dp dGNoL3JvdXRlciBhYm91dCB0aGUgY2hhbmdlIHRvIHRoZSBzZXJ2aWNlIGNoYWluLiBQZXJoYXBz IHRoZSBleGlzdGluZyB0ZXh0IGRvZXMgbm90IGV4cHJlc3MgdGhpcyBhc3BlY3QgY2xlYXJseS4g V2Ugd2lsbCBjbGFyaWZ5IHRoaXMgaW4gdGhlIG5leHQgcmV2aXNpb24gb2YgdGhlIGRvY3VtZW50 IHVzaW5nIHRleHQgYWxvbmcgdGhlIGxpbmVzIGRlc2NyaWJlZCBiZWxvdy4NCg0KRXZlbnQgU2Vx dWVuY2UgZm9yIENETiAobW9kaWZpZWQgdmVyc2lvbikNCg0KMS4gVGhlIENETiBNb25pdG9yaW5n IFN5c3RlbSBtb25pdG9ycyB0aGUgbnVtYmVycyBvZiB1c2VycyBhbmQgdHlwZSBvZiBjb250ZW50 IGJlaW5nIGFjY2Vzc2VkLiBCeSBkZWZhdWx0LCB3ZSBhc3N1bWUgdGhlIENETiBDYWNoZSBpcyBi eXBhc3NlZC4NCjIuICAgICAgSWYgdGhlIG51bWJlciBvZiB1c2VycyB2aWV3aW5nIHRoZSBzYW1l IGNvbnRlbnQgZXhjZWVkcyBhIHByZS1wcm9ncmFtbWVkIHVwLXRocmVzaG9sZCBhbmQgdGhlIGNv bnRlbnQgaXMgbG9uZy1saXZlZCwgdGhlIENETiBNb25pdG9yaW5nIFN5c3RlbSBpbnN0cnVjdHMg dGhlIFNGQyBDb250cm9sIFBsYW5lIEFwcGxpY2F0aW9uIHRvICBkeW5hbWljYWxseSBzd2l0Y2gg ZnJvbSB0aGUgZXhpc3Rpbmcgc2VydmljZSBjaGFpbiBBIHRvIGFub3RoZXIgc2VydmljZSBjaGFp biBCIHdoaWNoIGluY2x1ZGVzIGEgQ0ROIGNhY2hlIGZvciBjYWNoaW5nIHRoZSAgY29udGVudCBp biBhZGRpdGlvbiB0byBhbGwgb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIGluIHNlcnZpY2UgY2hh aW4gQSBpbiB0aGUgc2FtZSBvcmRlci4gVGhpcyBpcyBkb25lIGJ5IGluc3RhbGxpbmcgYSBydWxl IGZvciB0aGUgZmxvdyBjb3JyZXNwb25kaW5nIHRvIHRoZSBjb250ZW50IGluIHRoZSBTRkMgZWRn ZSBzd2l0Y2gvcm91dGVyLg0KMy4gICAgICBJZiB0aGUgbnVtYmVyIG9mIHVzZXJzIHZpZXdpbmcg dGhlIHNhbWUgY29udGVudCBmYWxscyBiZWxvdyBhbm90aGVyIHByZS1wcm9ncmFtbWVkIGRvd24t dGhyZXNob2xkIGFuZCB0aGUgY29udGVudCBpcyBsb25nLWxpdmVkLCB0aGUgbW9uaXRvcmluZyBz ZXJ2ZXIgaW5zdHJ1Y3RzIHRoZSBTRkMgQ29udHJvbCBQbGFuZSBBcHBsaWNhdGlvbiB0byBkeW5h bWljYWxseSBzd2l0Y2ggdGhlIGZsb3cgZnJvbSB0aGUgZXhpc3Rpbmcgc2VydmljZSBjaGFpbiBC ICh0aGUgb25lIHRoYXQgd2FzIHVzZWQgaW4gdGhlIHByZXZpb3VzIGV2ZW50KSB0byBzZXJ2aWNl IGNoYWluIEEgKGFnYWluLCB3aGljaCBpbmNsdWRlcyBhbGwgb2YgdGhlIHNlcnZpY2UgZnVuY3Rp b25zIGluIHNlcnZpY2UgY2hhaW4gQiBvdGhlciB0aGFuIHRoZSBDRE4gY2FjaGUpLiBUaGlzIGlz IGRvbmUgYnkgcmVtb3ZpbmcgdGhlIHByZXZpb3VzbHkgaW5zdGFsbGVkIHJ1bGUgZm9yIHRoZSBm bG93IGNvcnJlc3BvbmRpbmcgdG8gdGhlIGNvbnRlbnQgZnJvbSB0aGUgU0ZDIGVkZ2Ugc3dpdGNo L3JvdXRlci4NClRoYW5rcywNClJhbWtpDQoNCkZyb206IExpemhvbmcgSmluIFttYWlsdG86bGl6 aG8uamluQGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAwNSwgMjAxNSAzOjE2IFBN DQpUbzogUmFta2kgS3Jpc2huYW4NCkNjOiBiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRvOmJpbGwu d3VAaHVhd2VpLmNvbT47IGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28u Y29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Nm Y10gV0cgTEMgZm9yIGRyYWZ0LWlldGYtc2ZjLWxvbmctbGl2ZWQtZmxvdy11c2UtY2FzZXMtMDEN Cg0KVW5saWtlIHRoZSBmaXJzdCBjYXNlIGFuZCB0aGUgdGhpcmQgY2FzZSwgaW4gdGhlIHNlY29u ZCBjYXNlLCBjb250cm9sIHBsYW5lIGFwcGxpY2F0aW9uIGRvZXNuoa90IG5lZWQgdG8gaW5mb3Jt IFNGQyBlZGdlIHN3aXRjaC9yb3V0ZXIgYWJvdXQgdGhlIGNoYW5nZSB0byB0aGUgZXhpc3Rpbmcg c2VydmljZSBjaGFpbiBzaW5jZSBpdCBpcyBzdGlsbA0KYSBzYW1lIHNlcnZpY2UgZnVuY3Rpb24g Y2hhaW4uIEJ1dCBjb250cm9sIHBsYW5lIGFwcGxpY2F0aW9uIG5lZWRzIHRvIGNvbW11bmljYXRl IHdpdGggdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgaXMgcHJlY2VkaW5nIHRoZSBDRE4gY2Fj aGUgYW5kIG9uZSB0aGF0IGlzIGZvbGxvd2luZyB0aGUgQ0ROIGNhY2hlIGFib3V0IGZvcndhcmRp bmcgY2hhbmdlLiBMZXQgbWUga25vdyBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QuDQpS YW1raTogWW91ciBzdGF0ZW1lbnQgaXMgY29uZnVzaW5nLiBUaGUgY2hhaW4gbmVlZHMgdG8gYmUg bWFuaXB1bGF0ZWQgZm9yIGFsbCB0aGUgdXNlIGNhc2VzLg0KW1Fpbl06IEluIHRoZSBDRE4gY2Fz ZSwgdGhlIFNGQyBlZGdlIHN3aXRjaC9yb3V0ZXIgYXMgQ2xhc3NpZmllciBkb2VzbqGvdCBuZWVk IHRvIGtub3cgd2hldGhlciBvciBub3QgeW91IGFkZCBhIG5ldyBzZXJ2aWNlIGZ1bmN0aW9uIGlu dG8gdGhlIGV4aXN0aW5nIHNlcnZpY2UgY2hhaW4gc2luY2UgdHJhZmZpYyBmbG93IHN0aWxsIGNv cnJlc3BvbmRzIHRvIHRoZSBzYW1lIGNoYWluLiBCdXQgaW4gdGhlIHRyYW5zcGFyZW50IGZpcmV3 YWxsIGNhc2UgYW5kIElQU0VDIEdhdGV3YXkgY2FzZSwgdGhlIGZsb3cgc2hvdWxkIGJlIHN3aXRj aGVkIGZyb20gb25lIHNlcnZpY2UgY2hhaW4gdG8gYW5vdGhlciBuZXcgY2hhaW4sIHRoZSBTRkMg ZWRnZSBzd2l0Y2gvcm91dGVyIE1VU1Qga25vdyBiaW5kaW5nIGNoYW5nZSBiZXR3ZWVuIHRoZSB0 cmFmZmljIGZsb3cgYW5kIHRoZSBzZXJ2aWNlIGNoYWluLiBEb2VzIHRoaXMgY2xhcmlmeT8NClJh bWtpMTogWW91IGFyZSBtaXN0YWtlbiBpbiB0aGUgQ0ROIGNhc2UuIFBsZWFzZSBsb29rIGF0IG15 IHByZXZpb3VzIGFuc3dlcnMgYW5kIEkgd291bGQgc3VnZ2VzdCB5b3UgdG8gY2FyZWZ1bGx5IHJl YWQgc2VjdGlvbiAzLjEsIHRoZSBMb25nLXRhaWwgY29udGVudCBDRE4gZXZlbnQgc2VxdWVuY2Uu DQpbTGl6aG9uZ10gYWN0dWFsbHkgSSBoYXZlIHNpbWlsYXIgdW5kZXJzdGFuZGluZyBhcyBRaW4g d2hlbiByZWFkaW5nIHNlY3Rpb24gMy4xLiBUaGUgobBzZXJ2aWNlIGNoYWluobEgaW4gcG9pbnQg MiBjb3VsZCBiZSBleHBsYWluZWQgYXMgdGhlIHNhbWUgobBzZXJ2aWNlIGNoYWluobEgaW1wbGlj aXRseSBzYWlkIGluIHBvaW50IDEuIFdlIG1heSBjaGFuZ2UgdGhlIGRlc2NyaXB0aW9uIG9mIHBv aW50IDIgYXMgYmVsb3c6DQqhsHRoZSBDRE4gTW9uaXRvcmluZyBTeXN0ZW0gaW5zdHJ1Y3RzIHRo ZSBTRkMgQ29udHJvbCBQbGFuZSBBcHBsaWNhdGlvbiB0byBkeW5hbWljYWxseSBlc3RhYmxpc2gg dGhlIHNlcnZpY2UgY2hhaW4gd2l0aCBDRE4gY2FjaGUgZm9yIHRoYXQgY29udGVudKGxDQoNClJl Z2FyZHMNCkxpemhvbmcNCg0KUmVnYXJkcyENCi1RaW4NCreivP7Iyzogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXMgYXQgaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzJTIwYXQlMjBpZXRmLm9yZz5d ILT6se0gSmltIEd1aWNoYXJkIChqZ3VpY2hhcikNCreiy83KsbzkOiAyMDE0xOoxMtTCMTXI1SAy MzoxNQ0KytW8/sjLOiBzZmMgYXQgaWV0Zi5vcmc8bWFpbHRvOnNmYyUyMGF0JTIwaWV0Zi5vcmc+ DQrW98ziOiBbc2ZjXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1zZmMtbG9uZy1saXZlZC1mbG93LXVz ZS1jYXNlcy0wMQ0KDQpEZWFyIFdHOg0KDQpUaGlzIG5vdGUgYmVnaW5zIGEgMi13ZWVrIFdHIExD IG9uIGRyYWZ0LWlldGYtc2ZjLWxvbmctbGl2ZWQtZmxvdy11c2UtY2FzZXMuMDEudHh0Lg0KDQpU aGUgZG9jdW1lbnQgYXV0aG9ycyBoYXZlIGluZGljYXRlZCB0aGF0IHRoZXkgaGF2ZSBhZGRyZXNz ZWQgYWxsIGtub3duIGNvbW1lbnRzIGFuZCB0aGF0IHRoZXJlIGFyZSBubyBvcGVuIGlzc3VlcyB3 aXRoIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50Lg0KDQpTdWJzdGFudGl2ZSBj b21tZW50cyB0byB0aGUgbGlzdCBwbGVhc2UsIGVkaXRvcmlhbCBjb21tZW50cyBjYW4gZ28gZGly ZWN0bHkgdG8gdGhlIGRvY3VtZW50IGVkaXRvcnMuDQoNCkppbSAmIFRob21hcw0KDQoNCg0K --_000_A3233753A4B65F43BCA1B64DA99A9C230716FD982AGSCMAMP19EXfi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I get the use cases 1 and 3. I see the rationale for the CDN = use case as well but I wonder how it=A1=AFll be done=A1=AAif the use case i= s to insert a cache dynamically midstream during long-lived flows, as oppos= ed to inserting the cache only for the new connections.

 

My questions are:<= o:p>

=A1=A4       &nb= sp; When you= =A1=AFre introducing the cache dynamically midstream, how would long-lived = flows be handled? How does the (new) cache pick up where the original conte= nt server has just left off?

=A1=A4  &nbs= p;      And are you assuming that the cache would have a VIP tha= t represents the destination IP of the flows? I think it=A1=AFll have to si= nce SFC can=A1=AFt change the DNS cache of the client.

 

Myo

 <= /span>

= From:= sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ramki Krishnan
Sent: 5 January 2015 5:15 AM
To: Lizhong Jin
Cc: j= guichar@cisco.com; bill.wu@huawei.com; sfc@ietf.org
Subject: Re: = [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

&nbs= p;

Even in the second case, the SFC control plane application *does need* to i= nform the SFC edge switch/router about the change to the service chain. Per= haps the existing text does not express this aspect clearly. We will clarif= y this in the next revision of the document using text along the lines desc= ribed below.

 

E= vent Sequence for CDN (modified version)

&n= bsp;

1. The CDN Monitoring System monitors the numbers of u= sers and type of content being accessed. By default, we assume the CDN Cach= e is bypassed.

&= nbsp;     If the number of users viewing the sam= e content exceeds a pre-programmed up-threshold and the content is long-liv= ed, the CDN Monitoring System instructs the SFC Control Plane Application t= o  dynamically switch from the existing service chain A to another ser= vice chain B which includes a CDN cache for caching the  content in ad= dition to all of the service functions in service chain A in the same order= . This is done by installing a rule for the flow corresponding to the conte= nt in the SFC edge switch/router.

&= nbsp;     If the number of users viewing the sam= e content falls below another pre-programmed down-threshold and the content= is long-lived, the monitoring server instructs the SFC Control Plane Appli= cation to dynamically switch the flow from the existing service chain B (th= e one that was used in the previous event) to service chain A (again, which= includes all of the service functions in service chain B other than the CD= N cache). This is done by removing the previously installed rule for the fl= ow corresponding to the content from the SFC edge switch/router.

Thanks,

Ramki

 

From:= Lizhong Jin [mailto:lizho.jin@gmail= .com]
Sent: Monday, January 05, 2015 3:16 PM
To: R= amki Krishnan
Cc: bill.wu@h= uawei.com; jguichar@cisco.com= ; sfc@ietf.org
Subject: Re: [= sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

 =

= Unlike the first case and the third case, in the second case, control plane= application doesn=A1=AFt need to inform SFC edge switch/router about the c= hange to the existing service chain since it is still

a same service function chain. But control plane application needs= to communicate with the service functions that is preceding the CDN cache = and one that is following the CDN cache about forwarding change. Let me kno= w if my understanding is correct.

= Ramki: Your statement is confusing. The chain= needs to be manipulated for all the use cases.

[Qin]: In th= e CDN case, the SFC edge switch/router as Classifier doesn=A1=AFt need to k= now whether or not you add a new service function into the existing service= chain since traffic flow still corresponds to the same chain. But in the t= ransparent firewall case and IPSEC Gateway case, the flow should be switche= d from one service chain to another new chain, the SFC edge switch/router M= UST know binding change between the traffic flow and the service chain. Doe= s this clarify?

Ramki1: You are mistaken in the CDN case. Please look at my pre= vious answers and I would suggest you to carefully read section 3.1, the Lo= ng-tail content CDN event sequence.

[Lizhong] actually I have similar under= standing as Qin when reading section 3.1. The =A1=B0service chain=A1=B1 in = point 2 could be explained as the same =A1=B0service chain=A1=B1 implicitly= said in point 1. We may change the description of point 2 as below:

=A1=B0= the CDN Monitoring System instructs the SFC Control Plane Application to dy= namically establish the service chain with CDN cache for that content=A1=B1=

 

Regards

Lizhong

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc= -bounces at ietf.org] <= b>=B4=FA=B1=ED Jim Guichard (jguichar)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA12=D4=C21= 5=C8=D5 = 23:15
=CA=D5=BC=FE=C8=CB: sfc at ietf.org
=D6=F7=CC=E2:=  [sfc] WG LC for draft-ietf= -sfc-long-lived-flow-use-cases-01

 

Dear WG:

 

This = note begins a 2-week WG LC on draft-ietf-sfc-long-lived-flow-use-cases.01.t= xt.

 

The document authors have indicated tha= t they have addressed all known comments and that there are no open issues = with the current version of the document. 

 =

Substantive comments to the list please, editorial comments can go dir= ectly to the document editors.

 

Jim & Th= omas

 

 

 

= --_000_A3233753A4B65F43BCA1B64DA99A9C230716FD982AGSCMAMP19EXfi_-- From nobody Tue Jan 6 17:14:50 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6701A1B65 for ; Tue, 6 Jan 2015 17:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHFpMs3SfUni for ; Tue, 6 Jan 2015 17:14:46 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEA41A1B40 for ; Tue, 6 Jan 2015 17:14:45 -0800 (PST) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t071EjCx023805 for ; Wed, 7 Jan 2015 10:14:45 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id F3BFF5F593 for ; Wed, 7 Jan 2015 10:14:44 +0900 (JST) Received: from imail1.m.ecl.ntt.co.jp (imail1.m.ecl.ntt.co.jp [129.60.5.246]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id E6F355F591 for ; Wed, 7 Jan 2015 10:14:44 +0900 (JST) Received: from [129.60.21.195] (neba-hp-shiomoto.silab.ecl.ntt.co.jp [129.60.21.195]) by imail1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t071Eihn012124 for ; Wed, 7 Jan 2015 10:14:44 +0900 Message-ID: <54AC893C.7070209@lab.ntt.co.jp> Date: Wed, 07 Jan 2015 10:17:48 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sfc@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/3DRmslM3SOEI4KA31KJs7WE5nRQ Subject: [sfc] Call for Presentation: iPOP 2015 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 01:14:49 -0000 [Apologies, if you receive multiple copies of this CFP] --------------------------------------- Call for Presentation 11th International Conference on IP + Optical Network (iPOP 2015) April 20-22, 2015 Okinawa Jichikaikan, Naha Okinawa Japan http://www.pilab.jp/ipop2015/ Important Dates: Submission deadline of one-page abstract: January 16, 2015 Notification of acceptance: February 23, 2015 Submission deadline of final presentation slides: March 13, 2015 Following the successful events of iPOP, the 11th Conference on IP+Optical Network (iPOP 2015) will be held at Okinawa Jichikaikan, Naha Okinawa Japan, April 20-22, 2015. The conference has been provided opportunities for both of the industry and the academia to share their knowledge, new findings, and experiences on the state-of-the-art IP and optical networking technologies for these ten years. The Technical Program Committee for iPOP 2015 is soliciting presentation proposals for this conference. Architecture and protocol designs, experiments/PoCs/field trials, theories/algorithms, implementations, and operational experiences are solicited. The topics of the conference will include but not be limited to the following: * Control plane (MPLS/GMPLS, OpenFlow, etc) * SDN for packet and optical transport networks * MLN (Multi-Layer Network), MRN (Multi-Region Network) * TE (Traffic Engineering), PCE (Path Computation Element) * Network abstraction/virtualization * Flex-grid, elastic optical networks * Optical networking/switching for cloud services * Data center and WAN orchestration * Carrier Ethernet and MPLS-TP for backhauling * Service function chaining for mobile networks * Security * QoS (Quality of Service)/QoE (Quality of Experience) * Network operation and management * Standardization/interoperability * Open Source Software (OSS) for SDN/NFV * DevOps Submit an extended abstract (400 words, 1 page), including figures and diagrams, speaker’s name, affiliation, and contact information, to the Technical Program Committee: ipop2015-cfp@pilab.jp. Please see http://www.pilab.jp/ipop2015/ for more details. ------------------------------------------------------------------------ -- Kohei Shiomoto, Ph.D Senior Manager, Communication Traffic & Service Quality Project NTT Network Technology Laboratories NIPPON TELEGRAPH AND TELEPHONE CORPORATION TEL +81-422-59-4402 FAX +81-422-59-6364 From nobody Wed Jan 7 06:40:27 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0FC1A9086; Wed, 7 Jan 2015 06:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZDREQj8L6Mx; Wed, 7 Jan 2015 06:40:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 528221A9081; Wed, 7 Jan 2015 06:40:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150107144022.28675.1352.idtracker@ietfa.amsl.com> Date: Wed, 07 Jan 2015 06:40:22 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mA0HGyxbX9wJ5L-kJ3MrH3BeSNI Cc: jmh@joelhalpern.com, draft-ietf-sfc-problem-statement@tools.ietf.org, sfc@ietf.org, sfc-chairs@tools.ietf.org Subject: [sfc] Alia Atlas' Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 14:40:24 -0000 Alia Atlas has entered the following ballot position for draft-ietf-sfc-problem-statement-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- It was pointed out to me that the definitions in the problem-statement and the architecture differ. These seem to be minor and accidental differences. It is better to have the definitions in only one place or at least have a single authoritative reference. Could you decide upon the correct and final definitions and please do one of the following: a) For overlapping definitions, define them only in the problem-statement and have the architecture refer to the problem-statement for the authoritative definitions (quoting if desirable). b) For overlapping definitions, define them only in the architecture and have the problem-statemen refer to the architecture for the authoritative definitions (quoting if desirable) From nobody Wed Jan 7 08:41:01 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395251A006D; Wed, 7 Jan 2015 08:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Oq0DqfxFgdJ; Wed, 7 Jan 2015 08:35:45 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F761A006E; Wed, 7 Jan 2015 08:35:31 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id p9so1393642lbv.7; Wed, 07 Jan 2015 08:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tW5oMFrfP/THgUnMKtGGH2U43PvIw0309gWRk/b46UI=; b=eo8eI4VwrJAHlzmzzPfqkNnlGoJdXb1+IEuwdrYGHPzuYpVcrSVS1KKW4togR+3hAe pTdHDIRJXAcmYFBlTYViS88zSUEJcEkEfsLZVJR+RJPIir0W4RS/eP/QZ8b+ub4845Gz GU8IB4bnGzAFZQgZMFrghJIoPAh2Waei0WYybH+00COvKk/YZuWB3PJC3RSk3xXU+BH5 VgXmdzMuzAGEH3HqIF8n1nxVP4f+z/G2omiYLHCWOqjw870XQQlHYFFeOb8pRBjnkAyV 4yB94qFmUn0Jfka2ri9rwR+Zjbfn6z8JzVZ1RYYwoSdRAdb0JqaCkJGt9e/YOtCTwEDM m42A== MIME-Version: 1.0 X-Received: by 10.152.2.8 with SMTP id 8mr5926749laq.97.1420648529563; Wed, 07 Jan 2015 08:35:29 -0800 (PST) Received: by 10.112.49.52 with HTTP; Wed, 7 Jan 2015 08:35:29 -0800 (PST) In-Reply-To: References: <20150104175311.20228.59840.idtracker@ietfa.amsl.com> <54A98563.3090100@joelhalpern.com> <54A99261.4000306@cs.tcd.ie> <54A99429.9070209@joelhalpern.com> <54A995AA.8000909@cs.tcd.ie> <54A9994D.1050701@joelhalpern.com> Date: Wed, 7 Jan 2015 11:35:29 -0500 Message-ID: From: Kathleen Moriarty To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/B0uozOZ58jZG6-DpAgYzd6xLlsQ X-Mailman-Approved-At: Wed, 07 Jan 2015 08:40:59 -0800 Cc: draft-ietf-sfc-problem-statement@tools.ietf.org, "sfc@ietf.org" , The IESG , "sfc-chairs@tools.ietf.org" , "Joel M. Halpern" , Stephen Farrell Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:35:49 -0000 On Mon, Jan 5, 2015 at 2:54 PM, Alia Atlas wrote: > [Just adding the SFC WG, since they're not on the recipients list] > > Alia > > On Sun, Jan 4, 2015 at 2:49 PM, Joel M. Halpern wrote: >> >> I am not understanding the question. SFC depends upon classification. But >> it does not depend upon any specific classification. If all it has is >> source and destiantion IP, then that is all it uses. If it has sources of >> out of band information that it trusts to tell it that SPI X goes to service >> chain Y, then it uses that. If it can magically read through cryptography >> and know what application is actually running, then it can do that. In some >> networks, this will result in something that is not useful. In others, it >> will be very useful. That proportion may change over time, based on many >> factors. If that is to be addressed anywhere, it would be in an >> applicability or deployment document. But frankly, with so many different >> uses envisioned, I don't expect it to be discussed anywhere. In particular, >> I just can't see it in the problem statement document. Maybe others see it >> differently and can suggest a sensible way to cover it. Since SFC is limited to a single administrative domain, I think that impacts this discussion and limits the usefulness of having it in this document. Encryption and the challenges that will come should be mentioned, but I think just at a high-level as the rest of this draft is very high-level. For service functions, many can deal with encrypted traffic (load balancers, filters, etc.) and may be the appropriate termination point for encryption when accessing services (load balancers, front end web servers to databases or other functions in a tiered architecture). I do agree that this problem will change over time and the draft seems to be dealing with the current situation. As the security of encrypted transport improves (harder to break, end-to-end encryption required, etc.), the type and order of service functions will adapt. DPI, firewall proxy functions, and email analysis may not be performed as they are today. This draft doesn't go into the functions in depth, so maybe this isn't the right place and as Stephen requested, understanding the plans of the WG to describe this in a later draft would be helpful. Thanks, Kathleen >> >> Yours, >> Joel >> >> >> On 1/4/15 2:34 PM, Stephen Farrell wrote: >>> >>> >>> >>> On 04/01/15 19:27, Joel M. Halpern wrote: >>>> >>>> I agree with regard to potential impact on the other parts of the >>>> network from SFC infrastructure. >>> >>> >>> Grand. >>> >>>> I do not know where the questions of which services can, should, or must >>>> not be provided belongs. But since SFC is carefully agnostic of the >>>> service specifics, I don't think it belongs here. If OPS wants to try >>>> to write that document, I wish them luck. >>> >>> >>> I think we're talking at cross purposes. >>> >>> I would like to know how and when the SFC WG are going to address >>> the tension to which I referred, in their design of SFC. >>> >>> If SFC inherently depends on classification and metadata (as this >>> draft states) then that has to be a relevant question to ask. >>> >>> S. >>> >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 1/4/15 2:20 PM, Stephen Farrell wrote: >>>>> >>>>> >>>>> Hi Joel, >>>>> >>>>> On 04/01/15 18:24, Joel M. Halpern wrote: >>>>>> >>>>>> I will leave most of these for the authors or chairs to respond to. >>>>>> There is one aspect where as shepherd I would like to ask for >>>>>> clarification. >>>>>> >>>>>> You raise the question of the implications of RFC 7258. I am not sure >>>>>> what aspect you expect SFC and the SFC problem statement to deal with. >>>>>> Given both RFC 7258 and other factors, we expect to see more and more >>>>>> of >>>>>> the traffic encrypted. That will mean that some kinds of services, >>>>>> and >>>>>> some kinds of classification, can not be used with such traffic. >>>>> >>>>> >>>>> Right. And/or that some folks might feel they're losing out by not >>>>> blocking such traffic so they can do their whizzy classification >>>>> etc. >>>>> >>>>>> That >>>>>> does not mean that the SFC problems don't apply. Nor that operators >>>>>> do >>>>>> not envision offering services to / regarding such traffic. >>>>> >>>>> >>>>> Sure. But it does mean there's an obvious tension between some >>>>> security and privacy requirements and some SFC requirements/goals. >>>>> >>>>>> It is not the job of SFC or the SFC problem statement to discuss >>>>>> issues >>>>>> like whether an operator can deploy firewalls or virus scanners that >>>>>> work on encrypted traffic. This problem statement doesn't care about >>>>>> that. >>>>>> >>>>>> So what is it you would like to see regarding your point 2 in the >>>>>> problem statement? >>>>> >>>>> >>>>> What I'm trying to understand is where those issues will be addressed >>>>> (esp. given discuss point #1) and why the problem statement doesn't >>>>> consider the tension referred to above to be a relevant problem. >>>>> >>>>>> The security and mangeability issues that I understand the charter to >>>>>> talk about are the security and managability of the SFC >>>>>> infrastructure. >>>>> >>>>> >>>>> And presumably any notable impacts of that SFC infrastructure on the >>>>> security or manageability of other parts of the network. >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 1/4/15 12:53 PM, Stephen Farrell wrote: >>>>>>> >>>>>>> Stephen Farrell has entered the following ballot position for >>>>>>> draft-ietf-sfc-problem-statement-10: Discuss >>>>>>> >>>>>>> When responding, please keep the subject line intact and reply to all >>>>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>>>> this >>>>>>> introductory paragraph, however.) >>>>>>> >>>>>>> >>>>>>> Please refer to >>>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>> >>>>>>> >>>>>>> The document, along with other ballot positions, can be found here: >>>>>>> http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> DISCUSS: >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> I have two points to discuss. Hopefully, they should >>>>>>> be fairly easily resolved though there may be a bit >>>>>>> of work needed. >>>>>>> >>>>>>> (1) The secdir review [1] I think does a good job of >>>>>>> identifying some real security issues that will emerege >>>>>>> and that are a consequence of the three bits of >>>>>>> architecture described here. Inclusion of some >>>>>>> variation of the 4 bullets from [1] would be at least a >>>>>>> good start in improving what is clearly an deficient >>>>>>> security considerations section (as Adrian correctly >>>>>>> said). I think that plus some text about other fairly >>>>>>> obvious issues (e.g. slow middlebox s/w update has >>>>>>> prevented applying some patches or slowed down >>>>>>> deployment of new security features, recognising the >>>>>>> tension between SFC and privacy/confidentiality,...) >>>>>>> should be fairly easily done with a little work from >>>>>>> someone. >>>>>>> >>>>>>> [1] >>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05351.html >>>>>>> >>>>>>> (2) The IAB have encouraged us to encrypt everything >>>>>>> and that, and RFC 7258, would seem to me to be very >>>>>>> much in tension with some aspects of this work. And the >>>>>>> WG charter says "The SFC WG will closely consider and >>>>>>> address the management and security implications when >>>>>>> documenting these deliverables." I see no real evidence >>>>>>> that that has happened so far from this particular >>>>>>> deliverable so my question is: when will you tackle the >>>>>>> security and privacy considerations and the obvious >>>>>>> tension between doing more inside the n/w vs. >>>>>>> protecting users and applications? Also - don't you >>>>>>> consider that DoS attacks are a problem that could be >>>>>>> mitigated or made worse via SFC? And isn't it clear >>>>>>> that privacy could easily be made worse if SFC is >>>>>>> developed without real consideration of privacy >>>>>>> trade-offs? Resolving this discuss point would ideally >>>>>>> be done by someone pointing me at WG drafts that do >>>>>>> substantively address these issues. (I've not looked, >>>>>>> so it's quite possible that will be done, and if so, >>>>>>> great.) If that is not currently possible, then we >>>>>>> should probably talk some more about when and how that >>>>>>> work is going to happen. (Translating that last bit: >>>>>>> I'm not trying to insist that the security and privacy >>>>>>> work needed for SFC be finished already, but I'd like >>>>>>> to be confident that it will happen, so this DISCUSS is >>>>>>> perhaps more for chatting with the AD and WG chairs >>>>>>> rather than the authors of this deliverable.) >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> COMMENT: >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> >>>>>>> - There are no IPR declarations on this directly >>>>>>> visible from the agenda (I've seen and reported another >>>>>>> bug near there today, not sure if this is related) but >>>>>>> there is one on this and there are two on a document >>>>>>> that this replaces, with one (#2285) being RAND with >>>>>>> possible royalty/fee. And the other (#2304) gets me a >>>>>>> 404 in the DB while the link is to #2307. I see the >>>>>>> write-up says the WG chairs figure that's ok, but it >>>>>>> only mentions 1 disclosure that it says caused some >>>>>>> concern. So this is just to check all's well, given the >>>>>>> confusing nature of the above. (Possibly the confusion >>>>>>> is just caused by a short-lived tracker bug.) >>>>>>> >>>>>>> - 1.1, RFC6967 is referenced as if it were a spec for >>>>>>> HOST_ID. But it is not. HOST_ID remains highly >>>>>>> controversial and using it as an example here is not a >>>>>>> good plan, as that might be used to claim that HOST_ID >>>>>>> has more acceptance than is the case. Simplest thing is >>>>>>> to just delete that. I'd also argue that HTTP header >>>>>>> "enrichment" has been shown to cause many >>>>>>> vulnerabilities so would also be better deleted. And >>>>>>> it's noticeable that the examples given are all (or >>>>>>> almost all) ones that will be made harder by more >>>>>>> cryptography, which the IAB and RFC7258 tell us is >>>>>>> good. Don't you have non-invasive examples that >>>>>>> could be added? >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Best regards, Kathleen From nobody Wed Jan 7 12:20:53 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EBD1A1AE0; Wed, 7 Jan 2015 12:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSUDCMrn6WWb; Wed, 7 Jan 2015 12:05:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A06271A1AC7; Wed, 7 Jan 2015 12:05:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150107200522.15498.5645.idtracker@ietfa.amsl.com> Date: Wed, 07 Jan 2015 12:05:22 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/gm8ZJ0iicqJ9gw2TJR8Rpbm2bXk X-Mailman-Approved-At: Wed, 07 Jan 2015 12:20:49 -0800 Cc: jmh@joelhalpern.com, draft-ietf-sfc-problem-statement@tools.ietf.org, sfc@ietf.org, sfc-chairs@tools.ietf.org Subject: [sfc] Alissa Cooper's Abstain on draft-ietf-sfc-problem-statement-10: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 20:05:32 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sfc-problem-statement-10: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The WG wiki seems like a more logical place to publish the content of this document. It doesn't seem to really refine the scope of the WG much beyond what is in the charter; is sufficiently high-level to be describing a generic technology problem; and lists a number of existing problems without indicating whether or how the work of the WG is expected to address them. I will not stand in the way of publication, but we need not spin up the IETF machinery for documents like this. From nobody Wed Jan 7 14:33:38 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B851A1B49; Wed, 7 Jan 2015 13:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga1q0A0G_rdF; Wed, 7 Jan 2015 13:11:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6261A1BA4; Wed, 7 Jan 2015 13:11:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: iesg-secretary@ietf.org, iesg@ietf.org, sfc@ietf.org, sfc-chairs@tools.ietf.org, jmh@joelhalpern.com, draft-ietf-sfc-problem-statement@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150107211148.26716.39074.idtracker@ietfa.amsl.com> Date: Wed, 07 Jan 2015 13:11:48 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/00eCBGQ04y-08SZPcqtsce4b6FA X-Mailman-Approved-At: Wed, 07 Jan 2015 14:33:37 -0800 Subject: [sfc] Telechat update notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 21:11:50 -0000 Telechat date has been changed to 2015-01-22 from 2015-01-08 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Wed Jan 7 14:33:40 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6BD1A6FE7 for ; Wed, 7 Jan 2015 13:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhZ6_vqvcZxp; Wed, 7 Jan 2015 13:45:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76ED91A6FDB; Wed, 7 Jan 2015 13:45:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: sfc-chairs@tools.ietf.org, draft-ietf-sfc-problem-statement@tools.ietf.org, jmh@joelhalpern.com, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150107214515.2831.55765.idtracker@ietfa.amsl.com> Date: Wed, 07 Jan 2015 13:45:15 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/WBgm1UsUaaR3-pvEnxNDaRYm1HY X-Mailman-Approved-At: Wed, 07 Jan 2015 14:33:38 -0800 Subject: [sfc] ID Tracker State Update Notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 21:45:17 -0000 IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Wed Jan 7 14:33:53 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33761A1B8F; Wed, 7 Jan 2015 12:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVPKuMtMR1t8; Wed, 7 Jan 2015 12:58:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7F1A1B7F; Wed, 7 Jan 2015 12:58:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> Date: Wed, 07 Jan 2015 12:58:41 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2j4gaogcppb3lF_xqDIQG2BsLdQ X-Mailman-Approved-At: Wed, 07 Jan 2015 14:33:51 -0800 Cc: jmh@joelhalpern.com, draft-ietf-sfc-problem-statement@tools.ietf.org, sfc@ietf.org, sfc-chairs@tools.ietf.org Subject: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 20:58:44 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-sfc-problem-statement-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I didn't see any mention of risks with multiple tenants and shared infrastructure for service functions, is that a concern? This consideration may fall into the same description as the second point from Ben's SecDir review (linked in Stephen's review). Although the SecDir review point could be within a single tenant environment where there may or may not be various levels of trust depending on access constraints (to the same or different set of applications for a single tenant). I'd like to make sure both points get addressed or if someone can tell me why it doesn't matter, that would be fine too. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Barry, Alissa, and maybe others that a wiki may be a better option, but I won't stand in the way of publication. I do think the problem SFC is working on is important and the work will be worthwhile, but this draft isn't ready ready or may not need to be published. There are still numerous security considerations to be included as pointed out in the SecDir review and in Stephen's DISCUSS points that I support. The draft mentions ordering for service functions, and it would be good to see some concrete examples of how security may be an issue with different options for ordering. Since SFC's scope is a single administrative domain, the service chaining could result in session decryption at various points in the chain that could result in security and privacy exposures within that domain (typically considered a manageable risk). Functionality may be limited for some of the service functions if the decryption does not happen prior to that point and risk prioritization will be necessary (exposure of data, session interception, corruption of data, etc. could result from this exposure) since this is likely to be used in hosted environments with multiple tenants. The SecDir review did mention crossover between management/control and data planes, but tenant isolation may also need to be mentioned. Some nits (I don't think others mentioned these, but sorry if they were already addressed): Section 2.1: 3rd paragraph: Is this intended to mean after a new service function is added? I can't imagine that this our happen on the fly, so I think that's the case and adding a word or two may help: from: As more service functions are required - often with strict ordering - topology changes are needed before and after each service function is added resulting in complex network changes and device configuration. 4th paragraph: I'm have trouble reading this paragraph as I think it contradicts itself, but the example in the following paragraph is helpful. If topology dictates placement, how could using topology not be viable? Maybe rewording it would help: The topological coupling limits placement and selection of service functions: service functions are "fixed" in place by topology and therefore placement and service function selection taking into account network topology information is not viable. Furthermore, altering the services traversed, or their order, based on flow direction is not possible. Thanks, Kathleen From nobody Thu Jan 8 08:24:07 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EA51A87E3; Thu, 8 Jan 2015 08:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2qrgLDTQptJ; Thu, 8 Jan 2015 08:24:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D021A8756; Thu, 8 Jan 2015 08:24:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNT31926; Thu, 08 Jan 2015 16:24:01 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 8 Jan 2015 16:24:00 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Thu, 8 Jan 2015 08:23:58 -0800 From: Linda Dunbar To: Kathleen Moriarty , The IESG Thread-Topic: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) Thread-Index: AQHQKsoKgyMGyyVb60KrrQQh2ZqAlZy2Zvqw Date: Thu, 8 Jan 2015 16:23:57 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645E8D8C4@dfweml701-chm> References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> In-Reply-To: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "jmh@joelhalpern.com" , "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , "sfc-chairs@tools.ietf.org" Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:24:05 -0000 Kathleen,=20 -----Original Message----- DISCUSS: ---------------------------------------------------------------------- I didn't see any mention of risks with multiple tenants and shared infrastr= ucture for service functions, is that a concern? =20 [Linda]Same as VPN service where VPN ID is used to differentiate traffic fr= om different tenants, when one Service Function applies treatment to traff= ic from different tenants, some identifiers in packet header fields, e.g. S= FC ID, VLAN/MPLS/etc in the header field, can be used to differentiate the = tenants.=20 If tenants need more stringent separation, different instances of the Servi= ce Function have to be used (or instantiated for those tenants).=20 Linda This consideration may fall into the same description as the second point f= rom Ben's SecDir review (linked in Stephen's review). Although the SecDir r= eview point could be within a single tenant environment where there may or = may not be various levels of trust depending on access constraints (to the = same or different set of applications for a single tenant). I'd like to ma= ke sure both points get addressed or if someone can tell me why it doesn't = matter, that would be fine too. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Barry, Alissa, and maybe others that a wiki may be a better op= tion, but I won't stand in the way of publication. I do think the problem = SFC is working on is important and the work will be worthwhile, but this draft isn't ready ready or may not need to be published. =20 There are still numerous security considerations to be included as pointed = out in the SecDir review and in Stephen's DISCUSS points that I support. The draft mentions ordering for service functions, and it would be good to = see some concrete examples of how security may be an issue with different o= ptions for ordering. Since SFC's scope is a single administrative domain, = the service chaining could result in session decryption at various points i= n the chain that could result in security and privacy exposures within that= domain (typically considered a manageable risk). Functionality may be limited for some of the service functions if the decryption does not happen prior to that point and risk pr= ioritization will be necessary (exposure of data, session interception, cor= ruption of data, etc. could result from this exposure) since this is likely= to be used in hosted environments with multiple tenants. The SecDir revie= w did mention crossover between management/control and data planes, but ten= ant isolation may also need to be mentioned. Some nits (I don't think others mentioned these, but sorry if they were alr= eady addressed): Section 2.1: 3rd paragraph: Is this intended to mean after a new service function is added? I can't im= agine that this our happen on the fly, so I think that's the case and addin= g a word or two may help: from: As more service functions are required - often with strict ordering - topology changes are needed before and after each service function is ad= ded resulting in complex network changes and device configuration. =20 4th paragraph: I'm have trouble reading this paragraph as I think it contr= adicts itself, but the example in the following paragraph is helpful. If t= opology dictates placement, how could using topology not be viable? Maybe = rewording it would help: The topological coupling limits placement and selection of service functions: service functions are "fixed" in place by topology and therefore placement and service function selection taking into account network topology information is not viable. Furthermore, altering the services traversed, or their order, based on flow direction is not possible. Thanks, Kathleen _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jan 9 13:46:44 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375631A1A88; Fri, 9 Jan 2015 13:46:41 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0VHscqQ7CXW; Fri, 9 Jan 2015 13:46:36 -0800 (PST) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C961A0381; Fri, 9 Jan 2015 13:46:35 -0800 (PST) Received: by mail-yh0-f47.google.com with SMTP id f73so5295438yha.6; Fri, 09 Jan 2015 13:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IZMlEvyjf4gsNN+OiZ526DPaYRlk+z+Nx0BanjjMVCw=; b=rC1Ae6brZ1ZYHgicvZKGJbyTNWwkgBC9Rvs4a7Jdl/RH68kqkv3fzbJzJ/dWC5t85T pKctD+j5tA4Fm0sdnkLXqqm8+wOj8yeWO2ZvHZcC73Kl+muM6TloamRcdSv0z/+HxOOP vI/HACjW8i8QfG69FqDVwnQOAN1iqOEuwqj7YIVuoxCFSzl1+rSn5GRClOVSDI+5Bwwx H0yNyYNxtNhdrvaUXEE8jTW0vH+aZpi7hIF0Koc1mpO99i8s5W8irYjCmCwPi+Q8XGrZ rItazIZCFJXspiEVgp5/sKnhiO/INmhYv0G8E8bFy5/yJ2o1cuc5CBSK4oldtnvcAnh4 XMRw== MIME-Version: 1.0 X-Received: by 10.170.83.4 with SMTP id z4mr14746716ykz.103.1420839995181; Fri, 09 Jan 2015 13:46:35 -0800 (PST) Received: by 10.170.133.18 with HTTP; Fri, 9 Jan 2015 13:46:35 -0800 (PST) In-Reply-To: <20141228105814.27249.17491.idtracker@ietfa.amsl.com> References: <20141228105814.27249.17491.idtracker@ietfa.amsl.com> Date: Fri, 9 Jan 2015 16:46:35 -0500 Message-ID: From: Alia Atlas To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a113a5f0a321263050c3f1715 Archived-At: Cc: "Joel M. Halpern" , "sfc-chairs@tools.ietf.org" , The IESG , "sfc@ietf.org" , draft-ietf-sfc-problem-statement@tools.ietf.org Subject: Re: [sfc] Adrian Farrel's No Objection on draft-ietf-sfc-problem-statement-10: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 21:46:41 -0000 --001a113a5f0a321263050c3f1715 Content-Type: text/plain; charset=UTF-8 Hi Adrian, Thanks for your detailed review. I'm certain that the authors will also chime in, but here are my thoughts. On Sun, Dec 28, 2014 at 5:58 AM, Adrian Farrel wrote: > Adrian Farrel has entered the following ballot position for > draft-ietf-sfc-problem-statement-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm balloting No Objection on this document although I did not find it a > satisfying or detailed read. I think it contains text that could be left > out and would improve the document. I think it omits material > (describing the deployment and operation of service function chains > today, and discussing security) that should be included. None of these > issues quite makes it to the level of a Discuss for me, but it was a > close thing. > > Perhaps the authors and working group would like to look at the > document more closely. > I completely agree about the security section. I don't think that describing more of what's bad about the deployment and operation today will help noticeably and can distract the WG from constructively working on their solutions. > --- > > Section 1 > > Furthermore > there is a cascading effect: service changes affect other services. > > This is not clear (to me). > Perhaps you intend s/affect/may affect/ > Perhaps you intend s/service changes/service function changes/ > And maybe you meant that the introduction of a new service function onto > a path in order to change one service, causes that same service function > to be applied to all traffic on that path thereby changing other > services. > I think they mean the last - but agree it needs to be clarified. Section 1.1 > Thank you for the reference to OSI layers. It's been a long time and > they have been sorely missed. > In a document where you are hot on overlays (which imply layer > inversions) the mention of OSI layers is certainly "interesting". > > --- > > Notwithstanding your definition in section 1.1, the term "Service > Function" remains ambiguous. Under your definition, a packet forwarder > is a service function. What about a packet classifier? > I think so. I'd welcome a clearer definition but do think this one is understandable. If I were to extend it, it would be that the Service Function takes in a series of packets on one (or more?) interface and outputs a modified series of packets on one or more interfaces. The modifications may include adding information to the metadata associated with the packet. --- > > Section 1.1 Service Function Chain > I stumbled over "The implied order may not be a linear progression". > I think you need s/implied order/ordering constraints/ > Agree I suspect 2.2 needs to say "physical topology" since the point of this > work is to introduce overlays that make changes to the service topology > possible with simple configuration. > Agree > Section 2.3 > > Flip the order of the paragraphs so that the current first paragraph > has context for its statements. > Agreed > However, I think I contest the scope of your statements. They are > true when the failure is the failure of a service function but there is > continued ability to forward traffic. They are not true when the failure > is of connectivity (such as a link) or of forwarding (such as a service > function node). In those cases "in the same topology" might be better > phrased as "in parallel paths through the same topology." > Topology isn't implying a single path; I do agree that your phrasing is clearer. Section 2.4 is something of a marketing statement which is a shame. > Anyway, it conflicts with two things when it says: > Service function chains today are most typically built through manual > configuration processes. These are slow and error prone. With the > advent of newer service deployment models > Firstly, the prior text gives the impression that the service function > chain is most typically built through physical deployment of service > function nodes along traffic paths and their subsequent configuration. > Secondly, there is little (if any) difference between a manual > configuration process and a "newer service deployment model". That is, > automation of configuration is identical in effect to manual > configuration. > Surely the distinction you want to draw out is the change from physical > placement of service function nodes and the consequent constraints on > ordering with the proposed virtualisation of topology through the > overlay that allows service function nodes to be located anywhere and > chained in arbitrary orders. > Perhaps what is meant is that because service function chains today are built based upon physical topology, the associated configuration is done via manual processes which can be error prone? At any rate, I agree that some rephrasing would be useful here. > I think the concept of "transport" in section 2.6 will (or should) run > into the classic problem of the two meanings of "transport". Can you > make the text clearer that you are not discussing whether UDP, RTP, SCTP > etc. are in use. Agreed. Perhaps even encapsulation dependencies? I know that SFC is intended to run at different layers - but clarifying the issues here would be much better. > Does 2.7 mean "flexible" instead of "elastic"? Would it be good to have explained the current state of the are > described here for the first time? Maybe an early section of the > document could spend some (more) time describing how SFC is done today. > I do think flexible is clearer while elastic is also very common in the cloud space. A bit of description earlier around VLANs and current state would be nice. > Shouldn't 2.8 say "...unless packets are reclassified and classification > behaviors are configured at each service function node" ? > Agreed > The point being that a more flexible and granular SFC mechanism (such > as the WG is producing) effectively performs fine-grained classification > at the head of the chain and then "marks" each packet with the result of > that classification through a chain identifier, through a composite > chain, or in metadata. Where an overlay topology is used, you are not > actually changing the behavior you describe in this section (the mapping > of traffic on a segment into a service function is still coarse), but > you are changing the granularity of the topology. Agreed > Section 2.10 > > Is "may not" "might not", "must not", or "cannot"? > I agree clarification is desired. I believe that the classification may mark the traffic in some way (e.g. a particularly VLAN) so that it can sometimes be used in a similar way to how metadata might be used. > --- > > Why doesn't section 3 mention encapsulation? Isn't this a large part > of the work and solution? > Implied I think by the overlay - but I agree that it should be called out. > --- > > I should really be happier were Section 4 to be removed. I don't believe > it adds anything, it is (by its own admission) incomplete and leaves one > to wonder about the significance of omissions, and it is out of date > even before it is published. > > Actually, I have this particular Comment almost at the level of a > Discuss: this section is harmful to the work of the IETF and detracts > from the value of this document. > Agree - at the least it should be updated and made useful. Probably, the simplest path is removal. > --- > > Section 5 (rightly) notes the content present in Section 3. > Why doesn't the Abstract also mention what will be in Section 3? > Why doesn't the Introduction mention the content of Section 3? > What value does Section 5 add to the document? > Agreed that Sec 5 as it is seems to add nothing. > --- > > Section 7 is deficient, IMHO. The problem statement should describe the > problem of security of configuration and construction of service chains > today. It should also observe that some service functions are > specifically security functions: placing such functions on the physical > path ensures that they are executed, while allowing them to be by-passed > in the overlay network or left out of a chain is a considerable risk. > > However, I will leave it for the Security ADs to decide whether this > point needs to be Discussed. > If you have suggestions on text, that'd be useful. I'm pulling thoughts together based on Kathleen's and Stephen's comments. Thanks, Alia > --- > > Dave Mcdysan needs a capital D > > > --001a113a5f0a321263050c3f1715 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

Thanks for your detailed rev= iew.=C2=A0 I'm certain that the authors will also chime in, but here
are my thoughts.

On Sun, Dec 28, 2014 at 5:58 AM, Adrian Farrel <adrian@olddog= .co.uk> wrote:
Adrian Farre= l has entered the following ballot position for
draft-ietf-sfc-problem-statement-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-sfc-problem= -statement/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting No Objection on this document although I did not find it = a
satisfying or detailed read. I think it contains text that could be left out and would improve the document. I think it omits material
(describing the deployment and operation of service function chains
today, and discussing security) that should be included. None of these
issues quite makes it to the level of a Discuss for me, but it was a
close thing.

Perhaps the authors and working group would like to look at the
document more closely.

I completely agr= ee about the security section.=C2=A0 I don't think that describing more= of
what's bad about the deployment and operation today will = help noticeably
and can distract the WG from constructively worki= ng on their solutions.
=C2=A0
---

Section 1

=C2=A0 =C2=A0Furthermore
=C2=A0 =C2=A0there is a cascading effect: service changes affect other serv= ices.

This is not clear (to me).
Perhaps you intend s/affect/may affect/
Perhaps you intend s/service changes/service function changes/
And maybe you meant that the introduction of a new service function onto a path in order to change one service, causes that same service function to be applied to all traffic on that path thereby changing other
services.

I think they mean the last - = but agree it needs to be clarified.=C2=A0

Section 1.1
Thank you for the reference to OSI layers. It's been a long time and they have been sorely missed.
In a document where you are hot on overlays (which imply layer
inversions) the mention of OSI layers is certainly "interesting".=

---

Notwithstanding your definition in section 1.1, the term "Service
Function" remains ambiguous. Under your definition, a packet forwarder=
is a service function. What about a packet classifier?

I think so.=C2=A0 I'd welcome a clearer definition but = do think this one is understandable.
If I were to extend it, it w= ould be that the Service Function takes in a series of
packets on= one (or more?) interface and outputs a modified series of packets on=C2=A0=
one or more interfaces.=C2=A0 The modifications may include addi= ng information to the
metadata associated with the packet. =C2=A0=

---

Section 1.1 Service Function Chain
I stumbled over "The implied order may not be a linear progression&quo= t;.
I think you need s/implied order/ordering constraints/

=C2=A0Agree

I suspect 2.2 needs to say "physical topology" since the poin= t of this
work is to introduce overlays that make changes to the service topology
possible with simple configuration.

Agr= ee=C2=A0
=C2=A0
Section 2.3

Flip the order of the paragraphs so that the current first paragraph
has context for its statements.

Agreed= =C2=A0
=C2=A0
However, I think I contest the scope of your statements. They are
true when the failure is the failure of a service function but there is
continued ability to forward traffic. They are not true when the failure is of connectivity (such as a link) or of forwarding (such as a service
function node). In those cases "in the same topology" might be be= tter
phrased as "in parallel paths through the same topology."

Topology isn't implying a single path; I d= o agree that your phrasing is clearer.=C2=A0

Section 2.4 is something of a marketing statement which is a shame.
Anyway, it conflicts with two things when it says:
=C2=A0 =C2=A0Service function chains today are most typically built through= manual
=C2=A0 =C2=A0configuration processes. These are slow and error prone.=C2=A0= With the
=C2=A0 =C2=A0advent of newer service deployment models
Firstly, the prior text gives the impression that the service function
chain is most typically built through physical deployment of service
function nodes along traffic paths and their subsequent configuration.
Secondly, there is little (if any) difference between a manual
configuration process and a "newer service deployment model". Tha= t is,
automation of configuration is identical in effect to manual
configuration.
Surely the distinction you want to draw out is the change from physical
placement of service function nodes and the consequent constraints on
ordering with the proposed virtualisation of topology through the
overlay that allows service function nodes to be located anywhere and
chained in arbitrary orders.

Perhaps wh= at is meant is that because service function chains today are built
based upon physical topology, the associated configuration is done via m= anual
processes which can be error prone? =C2=A0 At any rate, I a= gree that some rephrasing
would be useful here.
=C2=A0<= /div>
I think the concept of "transport&= quot; in section 2.6 will (or should) run
into the classic problem of the two meanings of "transport". Can = you
make the text clearer that you are not discussing whether UDP, RTP, SCTP etc. are in use.

Agreed.=C2=A0 Perhaps even= encapsulation dependencies? =C2=A0 I know that SFC is intended
t= o run at different layers - but clarifying the issues here would be much be= tter.
=C2=A0
=C2=A0Does 2.7 m= ean "flexible" instead of "elastic"?
Would it be good to have explained the current state of the are
described here for the first time? Maybe an early section of the
document could spend some (more) time describing how SFC is done today.
=

I do think flexible is clearer while elast= ic is also very common in the cloud space.=C2=A0
A bit of descrip= tion earlier around VLANs and current state would be nice.
=C2=A0= =C2=A0
Shouldn't 2.8 say "...u= nless packets are reclassified and classification
behaviors are configured at each service function node" ?
Agreed
=C2=A0
The point being that a more flexible and granular SFC mechanism (such
as the WG is producing) effectively performs fine-grained classification at the head of the chain and then "marks" each packet with the re= sult of
that classification through a chain identifier, through a composite
chain, or in metadata. Where an overlay topology is used, you are not
actually changing the behavior you describe in this section (the mapping of traffic on a segment into a service function is still coarse), but
you are changing the granularity of the topology.

Agreed
=C2=A0
Section 2.10

Is "may not" "might not", "must not", or &quo= t;cannot"?

I agree clarification i= s desired.=C2=A0 I believe that the classification may mark
the t= raffic in some way (e.g. a particularly VLAN) so that it can sometimes
be used in a similar way to how metadata might be used.
=C2= =A0
---

Why doesn't section 3 mention encapsulation? Isn't this a large par= t
of the work and solution?

Implied I thi= nk by the overlay - but I agree that it should be called out.=C2=A0
=C2=A0
---

I should really be happier were Section 4 to be removed. I don't believ= e
it adds anything, it is (by its own admission) incomplete and leaves one to wonder about the significance of omissions, and it is out of date
even before it is published.

Actually, I have this particular Comment almost at the level of a
Discuss: this section is harmful to the work of the IETF and detracts
from the value of this document.

Agree = - at the least it should be updated and made useful.=C2=A0 Probably, the si= mplest
path is removal.
=C2=A0
---

Section 5 (rightly) notes the content present in Section 3.
Why doesn't the Abstract also mention what will be in Section 3?
Why doesn't the Introduction mention the content of Section 3?
What value does Section 5 add to the document?

Agreed that Sec 5 as it is seems to add nothing.=C2=A0
= =C2=A0
---

Section 7 is deficient, IMHO. The problem statement should describe the
problem of security of configuration and construction of service chains
today. It should also observe that some service functions are
specifically security functions: placing such functions on the physical
path ensures that they are executed, while allowing them to be by-passed in the overlay network or left out of a chain is a considerable risk.

However, I will leave it for the Security ADs to decide whether this
point needs to be Discussed.

If you hav= e suggestions on text, that'd be useful.=C2=A0 I'm pulling thoughts= together
based on Kathleen's and Stephen's comments.

Thanks,
Alia

=C2= =A0
---

Dave Mcdysan needs a capital D



--001a113a5f0a321263050c3f1715-- From nobody Fri Jan 9 22:06:29 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300A31A1B77 for ; Fri, 9 Jan 2015 22:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.184 X-Spam-Level: X-Spam-Status: No, score=0.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eFxcTKYSzhC for ; Fri, 9 Jan 2015 22:05:54 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A2F1A1B60 for ; Fri, 9 Jan 2015 22:05:53 -0800 (PST) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t0A5Kwik007648; Fri, 9 Jan 2015 22:05:41 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1rtd8ua3au-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 09 Jan 2015 22:05:40 -0800 Received: from HQ1WP-EXMB11.corp.brocade.com (10.70.20.185) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Jan 2015 22:05:38 -0800 Received: from HQ1WP-EXMB11.corp.brocade.com (10.70.20.185) by HQ1WP-EXMB11.corp.brocade.com (10.70.20.185) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 9 Jan 2015 22:05:37 -0800 Received: from HQ1WP-EXMB11.corp.brocade.com ([fe80::aa:5ef3:93e5:ed6d]) by HQ1WP-EXMB11.corp.brocade.com ([fe80::aa:5ef3:93e5:ed6d%18]) with mapi id 15.00.0995.031; Fri, 9 Jan 2015 22:05:37 -0800 From: Ramki Krishnan To: "Zarny, Myo" , "'Lizhong Jin'" Thread-Topic: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AdAoy6bOS6ROISegTU+mGS2rLqpB1wAA3cPQADylPZAAtjQD8A== Date: Sat, 10 Jan 2015 06:05:37 +0000 Message-ID: <801c08ae5af545299b52222ddcb4baca@HQ1WP-EXMB11.corp.brocade.com> References: <00ce01d028cc$75733bb0$6059b310$@gmail.com> <0b46db1f32cf4b16aa33be576642f027@HQ1WP-EXMB11.corp.brocade.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.72.16.63] Content-Type: multipart/alternative; boundary="_000_801c08ae5af545299b52222ddcb4bacaHQ1WPEXMB11corpbrocadec_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-10_02:2015-01-10,2015-01-09,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-1402240000 definitions=main-1501100053 Archived-At: Cc: "'jguichar@cisco.com'" , "'bill.wu@huawei.com'" , "'sfc@ietf.org'" Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 06:06:06 -0000 --_000_801c08ae5af545299b52222ddcb4bacaHQ1WPEXMB11corpbrocadec_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhlIENETiB1c2UgY2FzZSBhcHBsaWVzIG9ubHkgZm9yIG5ldyBmbG93czsgdGhlIGV4aXN0aW5n IGZsb3dzIGZvbGxvdyB0aGUgY3VycmVudCBzZXJ2aWNlIGNoYWluIHBhdGguIEFkZGl0aW9uYWxs eSwgdGhlIGNhY2hpbmcgaXMgdHJhbnNwYXJlbnQgd2hlcmUgdGhlIHN1YnNjcmliZXIgZG9lcyBu b3QgYWRkcmVzcyB0aGUgY2FjaGUgZXhwbGljaXRseTsgaXQgaXMgbm90IEROUyBiYXNlZCB3aGlj aCBpcyBhYm91dCB0ZWxsaW5nIHRoZSBzdWJzY3JpYmVyIHdoYXQgVklQIHRvIHVzZS4NCg0KVGhh bmtzLA0KUmFta2kNCg0KRnJvbTogWmFybnksIE15byBbbWFpbHRvOk15by5aYXJueUBncy5jb21d DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDA2LCAyMDE1IDc6MzEgQU0NClRvOiBSYW1raSBLcmlz aG5hbjsgJ0xpemhvbmcgSmluJw0KQ2M6ICdqZ3VpY2hhckBjaXNjby5jb20nOyAnYmlsbC53dUBo dWF3ZWkuY29tJzsgJ3NmY0BpZXRmLm9yZycNClN1YmplY3Q6IFJFOiBbc2ZjXSBXRyBMQyBmb3Ig ZHJhZnQtaWV0Zi1zZmMtbG9uZy1saXZlZC1mbG93LXVzZS1jYXNlcy0wMQ0KDQpJIGdldCB0aGUg dXNlIGNhc2VzIDEgYW5kIDMuIEkgc2VlIHRoZSByYXRpb25hbGUgZm9yIHRoZSBDRE4gdXNlIGNh c2UgYXMgd2VsbCBidXQgSSB3b25kZXIgaG93IGl0oa9sbCBiZSBkb25loappZiB0aGUgdXNlIGNh c2UgaXMgdG8gaW5zZXJ0IGEgY2FjaGUgZHluYW1pY2FsbHkgbWlkc3RyZWFtIGR1cmluZyBsb25n LWxpdmVkIGZsb3dzLCBhcyBvcHBvc2VkIHRvIGluc2VydGluZyB0aGUgY2FjaGUgb25seSBmb3Ig dGhlIG5ldyBjb25uZWN0aW9ucy4NCg0KTXkgcXVlc3Rpb25zIGFyZToNCg0KoaQgICAgICAgIFdo ZW4geW91oa9yZSBpbnRyb2R1Y2luZyB0aGUgY2FjaGUgZHluYW1pY2FsbHkgbWlkc3RyZWFtLCBo b3cgd291bGQgbG9uZy1saXZlZCBmbG93cyBiZSBoYW5kbGVkPyBIb3cgZG9lcyB0aGUgKG5ldykg Y2FjaGUgcGljayB1cCB3aGVyZSB0aGUgb3JpZ2luYWwgY29udGVudCBzZXJ2ZXIgaGFzIGp1c3Qg bGVmdCBvZmY/DQoNCqGkICAgICAgICBBbmQgYXJlIHlvdSBhc3N1bWluZyB0aGF0IHRoZSBjYWNo ZSB3b3VsZCBoYXZlIGEgVklQIHRoYXQgcmVwcmVzZW50cyB0aGUgZGVzdGluYXRpb24gSVAgb2Yg dGhlIGZsb3dzPyBJIHRoaW5rIGl0oa9sbCBoYXZlIHRvIHNpbmNlIFNGQyBjYW6hr3QgY2hhbmdl IHRoZSBETlMgY2FjaGUgb2YgdGhlIGNsaWVudC4NCg0KTXlvDQoNCkZyb206IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFta2kgS3Jpc2huYW4NClNlbnQ6 IDUgSmFudWFyeSAyMDE1IDU6MTUgQU0NClRvOiBMaXpob25nIEppbg0KQ2M6IGpndWljaGFyQGNp c2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPjsgYmlsbC53dUBodWF3ZWkuY29tPG1h aWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1zZmMtbG9uZy1saXZl ZC1mbG93LXVzZS1jYXNlcy0wMQ0KDQpFdmVuIGluIHRoZSBzZWNvbmQgY2FzZSwgdGhlIFNGQyBj b250cm9sIHBsYW5lIGFwcGxpY2F0aW9uICpkb2VzIG5lZWQqIHRvIGluZm9ybSB0aGUgU0ZDIGVk Z2Ugc3dpdGNoL3JvdXRlciBhYm91dCB0aGUgY2hhbmdlIHRvIHRoZSBzZXJ2aWNlIGNoYWluLiBQ ZXJoYXBzIHRoZSBleGlzdGluZyB0ZXh0IGRvZXMgbm90IGV4cHJlc3MgdGhpcyBhc3BlY3QgY2xl YXJseS4gV2Ugd2lsbCBjbGFyaWZ5IHRoaXMgaW4gdGhlIG5leHQgcmV2aXNpb24gb2YgdGhlIGRv Y3VtZW50IHVzaW5nIHRleHQgYWxvbmcgdGhlIGxpbmVzIGRlc2NyaWJlZCBiZWxvdy4NCg0KRXZl bnQgU2VxdWVuY2UgZm9yIENETiAobW9kaWZpZWQgdmVyc2lvbikNCg0KMS4gVGhlIENETiBNb25p dG9yaW5nIFN5c3RlbSBtb25pdG9ycyB0aGUgbnVtYmVycyBvZiB1c2VycyBhbmQgdHlwZSBvZiBj b250ZW50IGJlaW5nIGFjY2Vzc2VkLiBCeSBkZWZhdWx0LCB3ZSBhc3N1bWUgdGhlIENETiBDYWNo ZSBpcyBieXBhc3NlZC4NCjIuICAgICAgSWYgdGhlIG51bWJlciBvZiB1c2VycyB2aWV3aW5nIHRo ZSBzYW1lIGNvbnRlbnQgZXhjZWVkcyBhIHByZS1wcm9ncmFtbWVkIHVwLXRocmVzaG9sZCBhbmQg dGhlIGNvbnRlbnQgaXMgbG9uZy1saXZlZCwgdGhlIENETiBNb25pdG9yaW5nIFN5c3RlbSBpbnN0 cnVjdHMgdGhlIFNGQyBDb250cm9sIFBsYW5lIEFwcGxpY2F0aW9uIHRvICBkeW5hbWljYWxseSBz d2l0Y2ggZnJvbSB0aGUgZXhpc3Rpbmcgc2VydmljZSBjaGFpbiBBIHRvIGFub3RoZXIgc2Vydmlj ZSBjaGFpbiBCIHdoaWNoIGluY2x1ZGVzIGEgQ0ROIGNhY2hlIGZvciBjYWNoaW5nIHRoZSAgY29u dGVudCBpbiBhZGRpdGlvbiB0byBhbGwgb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIGluIHNlcnZp Y2UgY2hhaW4gQSBpbiB0aGUgc2FtZSBvcmRlci4gVGhpcyBpcyBkb25lIGJ5IGluc3RhbGxpbmcg YSBydWxlIGZvciB0aGUgZmxvdyBjb3JyZXNwb25kaW5nIHRvIHRoZSBjb250ZW50IGluIHRoZSBT RkMgZWRnZSBzd2l0Y2gvcm91dGVyLg0KMy4gICAgICBJZiB0aGUgbnVtYmVyIG9mIHVzZXJzIHZp ZXdpbmcgdGhlIHNhbWUgY29udGVudCBmYWxscyBiZWxvdyBhbm90aGVyIHByZS1wcm9ncmFtbWVk IGRvd24tdGhyZXNob2xkIGFuZCB0aGUgY29udGVudCBpcyBsb25nLWxpdmVkLCB0aGUgbW9uaXRv cmluZyBzZXJ2ZXIgaW5zdHJ1Y3RzIHRoZSBTRkMgQ29udHJvbCBQbGFuZSBBcHBsaWNhdGlvbiB0 byBkeW5hbWljYWxseSBzd2l0Y2ggdGhlIGZsb3cgZnJvbSB0aGUgZXhpc3Rpbmcgc2VydmljZSBj aGFpbiBCICh0aGUgb25lIHRoYXQgd2FzIHVzZWQgaW4gdGhlIHByZXZpb3VzIGV2ZW50KSB0byBz ZXJ2aWNlIGNoYWluIEEgKGFnYWluLCB3aGljaCBpbmNsdWRlcyBhbGwgb2YgdGhlIHNlcnZpY2Ug ZnVuY3Rpb25zIGluIHNlcnZpY2UgY2hhaW4gQiBvdGhlciB0aGFuIHRoZSBDRE4gY2FjaGUpLiBU aGlzIGlzIGRvbmUgYnkgcmVtb3ZpbmcgdGhlIHByZXZpb3VzbHkgaW5zdGFsbGVkIHJ1bGUgZm9y IHRoZSBmbG93IGNvcnJlc3BvbmRpbmcgdG8gdGhlIGNvbnRlbnQgZnJvbSB0aGUgU0ZDIGVkZ2Ug c3dpdGNoL3JvdXRlci4NClRoYW5rcywNClJhbWtpDQoNCkZyb206IExpemhvbmcgSmluIFttYWls dG86bGl6aG8uamluQGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAwNSwgMjAxNSAz OjE2IFBNDQpUbzogUmFta2kgS3Jpc2huYW4NCkNjOiBiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRv OmJpbGwud3VAaHVhd2VpLmNvbT47IGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJA Y2lzY28uY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW3NmY10gV0cgTEMgZm9yIGRyYWZ0LWlldGYtc2ZjLWxvbmctbGl2ZWQtZmxvdy11c2UtY2Fz ZXMtMDENCg0KVW5saWtlIHRoZSBmaXJzdCBjYXNlIGFuZCB0aGUgdGhpcmQgY2FzZSwgaW4gdGhl IHNlY29uZCBjYXNlLCBjb250cm9sIHBsYW5lIGFwcGxpY2F0aW9uIGRvZXNuoa90IG5lZWQgdG8g aW5mb3JtIFNGQyBlZGdlIHN3aXRjaC9yb3V0ZXIgYWJvdXQgdGhlIGNoYW5nZSB0byB0aGUgZXhp c3Rpbmcgc2VydmljZSBjaGFpbiBzaW5jZSBpdCBpcyBzdGlsbA0KYSBzYW1lIHNlcnZpY2UgZnVu Y3Rpb24gY2hhaW4uIEJ1dCBjb250cm9sIHBsYW5lIGFwcGxpY2F0aW9uIG5lZWRzIHRvIGNvbW11 bmljYXRlIHdpdGggdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgaXMgcHJlY2VkaW5nIHRoZSBD RE4gY2FjaGUgYW5kIG9uZSB0aGF0IGlzIGZvbGxvd2luZyB0aGUgQ0ROIGNhY2hlIGFib3V0IGZv cndhcmRpbmcgY2hhbmdlLiBMZXQgbWUga25vdyBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJl Y3QuDQpSYW1raTogWW91ciBzdGF0ZW1lbnQgaXMgY29uZnVzaW5nLiBUaGUgY2hhaW4gbmVlZHMg dG8gYmUgbWFuaXB1bGF0ZWQgZm9yIGFsbCB0aGUgdXNlIGNhc2VzLg0KW1Fpbl06IEluIHRoZSBD RE4gY2FzZSwgdGhlIFNGQyBlZGdlIHN3aXRjaC9yb3V0ZXIgYXMgQ2xhc3NpZmllciBkb2VzbqGv dCBuZWVkIHRvIGtub3cgd2hldGhlciBvciBub3QgeW91IGFkZCBhIG5ldyBzZXJ2aWNlIGZ1bmN0 aW9uIGludG8gdGhlIGV4aXN0aW5nIHNlcnZpY2UgY2hhaW4gc2luY2UgdHJhZmZpYyBmbG93IHN0 aWxsIGNvcnJlc3BvbmRzIHRvIHRoZSBzYW1lIGNoYWluLiBCdXQgaW4gdGhlIHRyYW5zcGFyZW50 IGZpcmV3YWxsIGNhc2UgYW5kIElQU0VDIEdhdGV3YXkgY2FzZSwgdGhlIGZsb3cgc2hvdWxkIGJl IHN3aXRjaGVkIGZyb20gb25lIHNlcnZpY2UgY2hhaW4gdG8gYW5vdGhlciBuZXcgY2hhaW4sIHRo ZSBTRkMgZWRnZSBzd2l0Y2gvcm91dGVyIE1VU1Qga25vdyBiaW5kaW5nIGNoYW5nZSBiZXR3ZWVu IHRoZSB0cmFmZmljIGZsb3cgYW5kIHRoZSBzZXJ2aWNlIGNoYWluLiBEb2VzIHRoaXMgY2xhcmlm eT8NClJhbWtpMTogWW91IGFyZSBtaXN0YWtlbiBpbiB0aGUgQ0ROIGNhc2UuIFBsZWFzZSBsb29r IGF0IG15IHByZXZpb3VzIGFuc3dlcnMgYW5kIEkgd291bGQgc3VnZ2VzdCB5b3UgdG8gY2FyZWZ1 bGx5IHJlYWQgc2VjdGlvbiAzLjEsIHRoZSBMb25nLXRhaWwgY29udGVudCBDRE4gZXZlbnQgc2Vx dWVuY2UuDQpbTGl6aG9uZ10gYWN0dWFsbHkgSSBoYXZlIHNpbWlsYXIgdW5kZXJzdGFuZGluZyBh cyBRaW4gd2hlbiByZWFkaW5nIHNlY3Rpb24gMy4xLiBUaGUgobBzZXJ2aWNlIGNoYWluobEgaW4g cG9pbnQgMiBjb3VsZCBiZSBleHBsYWluZWQgYXMgdGhlIHNhbWUgobBzZXJ2aWNlIGNoYWluobEg aW1wbGljaXRseSBzYWlkIGluIHBvaW50IDEuIFdlIG1heSBjaGFuZ2UgdGhlIGRlc2NyaXB0aW9u IG9mIHBvaW50IDIgYXMgYmVsb3c6DQqhsHRoZSBDRE4gTW9uaXRvcmluZyBTeXN0ZW0gaW5zdHJ1 Y3RzIHRoZSBTRkMgQ29udHJvbCBQbGFuZSBBcHBsaWNhdGlvbiB0byBkeW5hbWljYWxseSBlc3Rh Ymxpc2ggdGhlIHNlcnZpY2UgY2hhaW4gd2l0aCBDRE4gY2FjaGUgZm9yIHRoYXQgY29udGVudKGx DQoNClJlZ2FyZHMNCkxpemhvbmcNCg0KUmVnYXJkcyENCi1RaW4NCreivP7Iyzogc2ZjIFttYWls dG86c2ZjLWJvdW5jZXMgYXQgaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzJTIwYXQlMjBpZXRm Lm9yZz5dILT6se0gSmltIEd1aWNoYXJkIChqZ3VpY2hhcikNCreiy83KsbzkOiAyMDE0xOoxMtTC MTXI1SAyMzoxNQ0KytW8/sjLOiBzZmMgYXQgaWV0Zi5vcmc8bWFpbHRvOnNmYyUyMGF0JTIwaWV0 Zi5vcmc+DQrW98ziOiBbc2ZjXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1zZmMtbG9uZy1saXZlZC1m bG93LXVzZS1jYXNlcy0wMQ0KDQpEZWFyIFdHOg0KDQpUaGlzIG5vdGUgYmVnaW5zIGEgMi13ZWVr IFdHIExDIG9uIGRyYWZ0LWlldGYtc2ZjLWxvbmctbGl2ZWQtZmxvdy11c2UtY2FzZXMuMDEudHh0 Lg0KDQpUaGUgZG9jdW1lbnQgYXV0aG9ycyBoYXZlIGluZGljYXRlZCB0aGF0IHRoZXkgaGF2ZSBh ZGRyZXNzZWQgYWxsIGtub3duIGNvbW1lbnRzIGFuZCB0aGF0IHRoZXJlIGFyZSBubyBvcGVuIGlz c3VlcyB3aXRoIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50Lg0KDQpTdWJzdGFu dGl2ZSBjb21tZW50cyB0byB0aGUgbGlzdCBwbGVhc2UsIGVkaXRvcmlhbCBjb21tZW50cyBjYW4g Z28gZGlyZWN0bHkgdG8gdGhlIGRvY3VtZW50IGVkaXRvcnMuDQoNCkppbSAmIFRob21hcw0KDQoN Cg0K --_000_801c08ae5af545299b52222ddcb4bacaHQ1WPEXMB11corpbrocadec_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

The CDN use case applies only for new flows; the exi= sting flows follow the current service chain path. Additionally, the cachin= g is transparent where the subscriber does not address the cache explicitly= ; it is not DNS based which is about telling the subscriber what VIP to use.

 

Thanks,

Ramki

&nbs= p;

From: Zarny, Myo [mailto:Myo.Zarny@gs.com] Sent: Tuesday, January 06, 2015 7:31 AM
To: Ramki Krishnan; 'Lizhong Jin'
Cc: 'jguichar@cisco.com'; 'bill.wu@huawei.com'; 'sfc@ietf.org'
Subject: RE: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-case= s-01

 

I get the use cases 1 = and 3. I see the rationale for the CDN use case as well but I wonder how it= =A1=AFll be done=A1=AAif the use case is to insert a cache dynamically mids= tream during long-lived flows, as opposed to inserting the cache only for the new connections.

 

My questions are:=

=A1=A4        When you=A1=AF= re introducing the cache dynamically midstream, how would long-lived flows = be handled? How does the (new) cache pick up where the original content ser= ver has just left off?

=A1=A4        And are you as= suming that the cache would have a VIP that represents the destination IP o= f the flows? I think it=A1=AFll have to since SFC can=A1=AFt change the DNS= cache of the client.

 

Myo<= /p>

 

From: sfc [= mailto:sfc-bounces@ietf.org] On Behalf Of Ramki Krishnan
Sent: 5 January 2015 5:15 AM
To: Lizhong Jin
Cc: jguichar@cisco.com; bill.wu@huawei.com; sfc@ietf.org Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-case= s-01

 

Even in the second case, the SFC control plane application *does = need* to inform the SFC edge switch/router about the change to the serv= ice chain. Perhaps the existing text does not express this aspect clearly. = We will clarify this in the next revision of the document using text along the lines described below.

 

Event Sequence for CDN (modified version)

 

1. The CDN Monitoring System monitors the numbers of users and type of = content being accessed. By default, we assume the CDN Cache is bypassed.

2.      If the number of users viewing the same content exceeds a pre-programmed up= -threshold and the content is long-lived, the CDN Monitoring System instruc= ts the SFC Control Plane Application to  dynamically switch from the e= xisting service chain A to another service chain B which includes a CDN cache for caching the  content in additi= on to all of the service functions in service chain A in the same order. Th= is is done by installing a rule for the flow corresponding to the content i= n the SFC edge switch/router.

3.      If the number of users viewing the same content falls below another pre-pro= grammed down-threshold and the content is long-lived, the monitoring server= instructs the SFC Control Plane Application to dynamically switch the flow= from the existing service chain B (the one that was used in the previous event) to service chain A (again,= which includes all of the service functions in service chain B other than = the CDN cache). This is done by removing the previously installed rule for = the flow corresponding to the content from the SFC edge switch/router.

Thanks,

Ramki

 

From: Lizhong Jin = [mailto:lizho.jin@gmail.com]
Sent: Monday, January 05, 2015 3:16 PM
To: Ramki Krishnan
Cc: bill.wu@huawei.com; jguichar@cisco.com; sfc@ietf.org Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-case= s-01

 

Unlike the first case and th= e third case, in the second case, control plane application doesn=A1=AFt ne= ed to inform SFC edge switch/router about the change to the existing servic= e chain since it is still

a same service function chai= n. But control plane application needs to communicate with the service func= tions that is preceding the CDN cache and one that is following the CDN cac= he about forwarding change. Let me know if my understanding is correct.

Ramki: Your statement is confusing. The chain= needs to be manipulated for all the use cases.

[Qin]: In the CDN case, the = SFC edge switch/router as Classifier doesn=A1=AFt need to know whether or n= ot you add a new service function into the existing service chain since tra= ffic flow still corresponds to the same chain. But in the transparent firewall case and IPSEC Gateway case, the fl= ow should be switched from one service chain to another new chain, the SFC = edge switch/router MUST know binding change between the traffic flow and th= e service chain. Does this clarify?

Ramki1: You are mistaken in the CDN case. Ple= ase look at my previous answers and I would suggest you to carefully read s= ection 3.1, the Long-tail content CDN event sequence.

[Lizhong] actually I have similar understandi= ng as Qin when reading section 3.1. The =A1=B0service chain=A1=B1 in point = 2 could be explained as the same =A1=B0service chain=A1=B1 implicitly said = in point 1. We may change the description of point 2 as below:

=A1=B0the CDN Monitoring System instructs the= SFC Control Plane Application to dynamically establish the service chain w= ith CDN cache for that content=A1=B1

 

Regards

Lizhong

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces at ietf= .org] =B4=FA=B1=ED <= /span>Jim Guichard (jguichar)
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1= 2=D4=C215=C8=D5 23:15
=CA=D5=BC=FE=C8=CB: sfc at= ietf.org
=D6=F7=CC=E2: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-= cases-01

 =

Dear WG:

 

This note begins a 2-week WG L= C on draft-ietf-sfc-long-lived-flow-use-cases.01.txt.

 

The document authors have indi= cated that they have addressed all known comments and that there are no ope= n issues with the current version of the document. 

 

Substantive comments to the li= st please, editorial comments can go directly to the document editors.

 

Jim & Thomas

 

 

 

--_000_801c08ae5af545299b52222ddcb4bacaHQ1WPEXMB11corpbrocadec_-- From nobody Sat Jan 10 07:17:41 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB91A87E2; Sat, 10 Jan 2015 07:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dLvGwVLRQ9R; Sat, 10 Jan 2015 07:17:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5501A00F4; Sat, 10 Jan 2015 07:17:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150110151735.24428.85673.idtracker@ietfa.amsl.com> Date: Sat, 10 Jan 2015 07:17:35 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 15:17:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Use Cases in Mobile Networks Authors : Walter Haeffner Jeffrey Napper Martin Stiemerling Diego R. Lopez Jim Uttaro Filename : draft-ietf-sfc-use-case-mobility-02.txt Pages : 20 Date : 2015-01-10 Abstract: This document provides some exemplary use cases for service function chaining in mobile service provider networks. The objective of this draft is not to cover all conceivable service chains in detail. Rather, the intention is to localize and explain the application domain of service chaining within mobile networks as far as it is required to complement the problem statement [ietf-sfc-problem-statement] and architecture framework [ietf-sfc-arch] of the working group. Service function chains typically reside in a LAN segment which links the mobile access network to the actual application platforms located in the carrier's datacenters or somewhere else in the Internet. Service function chains (SFC) ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery or take care of security and privacy. SFCs may also include Value Added Services (VAS). Commonly, SFCs are typical middlebox services. General considerations and specific use cases are presented in this document to demonstrate the different technical requirements of these goals for service function chaining in mobile service provider networks. The specification of service function chaining for mobile networks must take into account an interaction between service function chains and the 3GPP Policy and Charging Control (PCC) environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-use-case-mobility-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 12 04:11:51 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0B91A1B8F; Mon, 12 Jan 2015 04:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcAz1J0MoKZO; Mon, 12 Jan 2015 04:11:47 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31AB1A1B81; Mon, 12 Jan 2015 04:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3470; q=dns/txt; s=iport; t=1421064706; x=1422274306; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=E/7CSt1q6Nm61lZjYCQD7p4CK3n5e0tgutKE8W9QEuU=; b=Srf3KgPdZonhTfsGF0nuR8Q0mx08B8r3mNyOWikQu0USCMzePjSwZ0lR HuqpX3SFULmjWXhLXZMazrd68iwf5buxrCPrmXPXuxU2BlnjgrJBF+gbF vAU5i0ItqrufrUc3xKtAVXwNbdDvAUuyRN7DBJpKCTtjA2cLMGQKwH8aZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFADG5s1StJA2K/2dsb2JhbABbgwZSUwnDWIIbCoVxAoERQwEBAQEBfYQMAQEBBAEBATctBwsMBAIBCBEBAgECFgkQJwsXBggCBAENBQmIIwgFyzcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj3kHBgSEHwWOPYNFhUiBDzCCQo13IoNub4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,743,1413244800"; d="scan'208";a="112428826" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 12 Jan 2015 12:11:44 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t0CCBio7004277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 12:11:44 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.7]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 06:11:43 -0600 From: "Jeffrey Napper (jenapper)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt Thread-Index: AQHQLOiZ6FGB0rIHEEenftRW8YaHK5y83WEA Date: Mon, 12 Jan 2015 12:11:43 +0000 Message-ID: References: <20150110151735.24428.85673.idtracker@ietfa.amsl.com> In-Reply-To: <20150110151735.24428.85673.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.206.45] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 12:11:50 -0000 This draft is largely wordsmithing and typos. There are a couple of new paragraphs that are available from the diff tool. Please send comments and suggestions to the list as we believe the document is ready for last call. The document seems to be quite stable now. Cheers, Jeff -----Original Message----- From: "internet-drafts@ietf.org" Date: Saturday, January 10, 2015 at 4:17 PM To: "i-d-announce@ietf.org" Cc: "sfc@ietf.org" Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Service Function Chaining Working Group >of the IETF. > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Martin Stiemerling > Diego R. Lopez > Jim Uttaro > Filename : draft-ietf-sfc-use-case-mobility-02.txt > Pages : 20 > Date : 2015-01-10 > >Abstract: > This document provides some exemplary use cases for service function > chaining in mobile service provider networks. The objective of this > draft is not to cover all conceivable service chains in detail. > Rather, the intention is to localize and explain the application > domain of service chaining within mobile networks as far as it is > required to complement the problem statement > [ietf-sfc-problem-statement] and architecture framework > [ietf-sfc-arch] of the working group. > > Service function chains typically reside in a LAN segment which links > the mobile access network to the actual application platforms located > in the carrier's datacenters or somewhere else in the Internet. > Service function chains (SFC) ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery or take care of security and privacy. > SFCs may also include Value Added Services (VAS). Commonly, SFCs are > typical middlebox services. > > General considerations and specific use cases are presented in this > document to demonstrate the different technical requirements of these > goals for service function chaining in mobile service provider > networks. > > The specification of service function chaining for mobile networks > must take into account an interaction between service function chains > and the 3GPP Policy and Charging Control (PCC) environment. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-use-case-mobility-02 > > >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/ > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jan 12 08:30:07 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E6C1A6FF5; Mon, 12 Jan 2015 08:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooiqubNcsXix; Mon, 12 Jan 2015 08:30:03 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5448B1A6FF0; Mon, 12 Jan 2015 08:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13426; q=dns/txt; s=iport; t=1421080203; x=1422289803; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yWO3Kg4yXRF1hp7Do1aAAdpsW0GREMLMSzKg2iRbvVs=; b=R1M9CldCqKS9lwoP0GZZll2X+s7WElBiv/4G5Y9yVO+OzadptYaUvCok AQVuPf9d7ViARheRY0P+lG4zCIL9yEMgReaOTTMPnfCvELcrkaIytsFF3 CJm/+7+oTaxUuCGRolhH9ddchNInXBHsyuCQNi5Mg3DQ2hSRl9CuLJ2rO A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8GAB72s1StJV2Y/2dsb2JhbABbgwZSXIMBwnMKhXECHHRDAQEBAQF9hAwBAQEDAQEBASAROgEKBQsCAQgSBgICJgICAiULFQIOAgQOBRuICQgNuTiTRwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGIboUHYweCaC6BEwWFNocsgVuFS4NCgQ+CcoI6iAODOiKCMoE8b4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,744,1413244800"; d="scan'208";a="112512861" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 12 Jan 2015 16:29:57 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t0CGTsvR018654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 16:29:57 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.163]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 10:28:38 -0600 From: "Paul Quinn (paulq)" To: Adrian Farrel Thread-Topic: [sfc] Adrian Farrel's No Objection on draft-ietf-sfc-problem-statement-10: (with COMMENT) Thread-Index: AQHQIo05Vksh+tAHokS7paL7NYZtsJy9KRsA Date: Mon, 12 Jan 2015 16:28:38 +0000 Message-ID: <2DE4302F-284A-4785-A29A-8CF55469DE89@cisco.com> References: <20141228105814.27249.17491.idtracker@ietfa.amsl.com> In-Reply-To: <20141228105814.27249.17491.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="utf-8" Content-ID: <3CF0B5AF27BACD47AA4432A457548F29@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "jmh@joelhalpern.com" , "sfc-chairs@tools.ietf.org" , The IESG , "sfc@ietf.org" , "draft-ietf-sfc-problem-statement@tools.ietf.org" Subject: Re: [sfc] Adrian Farrel's No Objection on draft-ietf-sfc-problem-statement-10: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 16:30:06 -0000 SGkgQWRyaWFuLA0KDQpUaGFuayB5b3UgZm9yIHRha2luZyB0aGUgdGltZSB0byByZXZpZXcgdGhl IGRyYWZ0LiAgUGxlYXNlIHNlZSBzb21lIGNvbW1lbnRzIGlubGluZSBiZWxvdy4gIA0KDQpBcyB5 b3Uga25vdyB0aGlzIGRyYWZ0IHJlY2VpdmVkIHNpZ25pZmlhbnQgV0cgcmV2aWV3LiAgQW55IG9m IHRoZSBzdWJzdGFudGl2ZSBjaGFuZ2VzIGRpc2N1c3NlZCBiZWxvdyB3aWxsIG5lZWQgdG8gZ28g YmFjayB0byB0aGUgbGlzdCBmb3IgcmV2aWV3IGFnYWluLiAgVG9tIGFuZCBJIHdpbGwgZ2V0IGEg cmV2IG91dCBhc2FwLg0KDQpQYXVsDQoNCg0KPiBPbiBEZWMgMjgsIDIwMTQsIGF0IDU6NTggQU0s IEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+IHdyb3RlOg0KPiANCj4gDQo+IA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEknbSBi YWxsb3RpbmcgTm8gT2JqZWN0aW9uIG9uIHRoaXMgZG9jdW1lbnQgYWx0aG91Z2ggSSBkaWQgbm90 IGZpbmQgaXQgYQ0KPiBzYXRpc2Z5aW5nIG9yIGRldGFpbGVkIHJlYWQuIEkgdGhpbmsgaXQgY29u dGFpbnMgdGV4dCB0aGF0IGNvdWxkIGJlIGxlZnQNCj4gb3V0IGFuZCB3b3VsZCBpbXByb3ZlIHRo ZSBkb2N1bWVudC4gSSB0aGluayBpdCBvbWl0cyBtYXRlcmlhbCANCj4gKGRlc2NyaWJpbmcgdGhl IGRlcGxveW1lbnQgYW5kIG9wZXJhdGlvbiBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWlucw0KPiB0 b2RheSwgYW5kIGRpc2N1c3Npbmcgc2VjdXJpdHkpIHRoYXQgc2hvdWxkIGJlIGluY2x1ZGVkLiBO b25lIG9mIHRoZXNlDQo+IGlzc3VlcyBxdWl0ZSBtYWtlcyBpdCB0byB0aGUgbGV2ZWwgb2YgYSBE aXNjdXNzIGZvciBtZSwgYnV0IGl0IHdhcyBhDQo+IGNsb3NlIHRoaW5nLiANCg0KT24gdGhlIHNl Y3VyaXR5IGZyb250IEkgcmVwbGllZCB0byBCZW7igJlzIGNvbW1lbnRzLCBhbmQgYWdyZWUgd2Ug d2lsbCBhZGQgc29tZSBhZGRpdGlvbmFsIGRldGFpbHMgdG8gdGhlIHNlY3VyaXR5IHNlY3Rpb24u ICANCg0KSeKAmW0gbm90IHN1cmUgd2hhdCBtYXRlcmlhbCB0b3BpY3MgeW91IGZlZWwgYXJlIG1p c3NpbmcgZnJvbSB0aGUgZHJhZnQgd3J0IHNlcnZpY2UgY2hhaW5zIG92ZXJhbGwuICBUaGUgZ29h bCBvZiB0aGUgZHJhZnQsIGFzIHlvdSBrbm93LCBpcyB0byBwcm92aWRlIGEgaGlnaCBsZXZlbCBy ZXZpZXcgb2YgdGhlIGlzc3VlcyBhc3NvY2lhdGVkIHdpdGggZXhpc3Rpbmcgc2VydmljZSBkZXBs b3ltZW50LiAgIFdlIGRlbGliZXJhdGVseSBkZWNpZGVkIHRvIG5vdCBtYWtlIGl0IGEgdHJlYXRp c2Ugb24gYWxsIHRoaW5ncyBzZXJ2aWNlIGNoYWluaW5nIGluIG9yZGVyIHRvIGtlZXAgdGhlIGRy YWZ0IGJvdGggc3VjY2luY3QgYW5kIGZvY3VzZWQgb24gdGhlIGtleSBpc3N1ZXMuICBPZiBjb3Vy c2UsIGlmIHlvdSBmZWVsIHRoZXJlIGFyZSBzcGVjaWZpYyB0b3BpY3MgdGhhdCBuZWVkIHRvIGJl IGFkZHJlc3NlZCBwbGVhc2UgbGV0IHVzIGtub3cuDQoNCg0KPiANCj4gUGVyaGFwcyB0aGUgYXV0 aG9ycyBhbmQgd29ya2luZyBncm91cCB3b3VsZCBsaWtlIHRvIGxvb2sgYXQgdGhlIA0KPiBkb2N1 bWVudCBtb3JlIGNsb3NlbHkuDQo+IA0KPiAtLS0NCj4gDQo+IFNlY3Rpb24gMQ0KPiANCj4gICBG dXJ0aGVybW9yZQ0KPiAgIHRoZXJlIGlzIGEgY2FzY2FkaW5nIGVmZmVjdDogc2VydmljZSBjaGFu Z2VzIGFmZmVjdCBvdGhlciBzZXJ2aWNlcy4NCj4gDQo+IFRoaXMgaXMgbm90IGNsZWFyICh0byBt ZSkuIA0KPiBQZXJoYXBzIHlvdSBpbnRlbmQgcy9hZmZlY3QvbWF5IGFmZmVjdC8NCj4gUGVyaGFw cyB5b3UgaW50ZW5kIHMvc2VydmljZSBjaGFuZ2VzL3NlcnZpY2UgZnVuY3Rpb24gY2hhbmdlcy8N Cj4gQW5kIG1heWJlIHlvdSBtZWFudCB0aGF0IHRoZSBpbnRyb2R1Y3Rpb24gb2YgYSBuZXcgc2Vy dmljZSBmdW5jdGlvbiBvbnRvDQo+IGEgcGF0aCBpbiBvcmRlciB0byBjaGFuZ2Ugb25lIHNlcnZp Y2UsIGNhdXNlcyB0aGF0IHNhbWUgc2VydmljZSBmdW5jdGlvbg0KPiB0byBiZSBhcHBsaWVkIHRv IGFsbCB0cmFmZmljIG9uIHRoYXQgcGF0aCB0aGVyZWJ5IGNoYW5naW5nIG90aGVyDQo+IHNlcnZp Y2VzLg0KPiANCg0KV2Ugd2lsbCByZXZpZXcgdGhlIHBocmFzaW5nIHRvIG1ha2UgaXQgY2xlYXJl ciB0aGF0IG1vdmVzL2FkZC9jaGFuZ2VzIG9mIGEgc3BlY2lmaWMgc2VydmljZSwgbWF5IGluIG1h bnkgY2FzZXMgYWZmZWN0IG90aGVyIGRlcGxveWVkIHNlcnZpY2VzLg0KDQoNCj4gLS0tDQo+IA0K PiBTZWN0aW9uIDEuMQ0KPiBUaGFuayB5b3UgZm9yIHRoZSByZWZlcmVuY2UgdG8gT1NJIGxheWVy cy4gSXQncyBiZWVuIGEgbG9uZyB0aW1lIGFuZA0KPiB0aGV5IGhhdmUgYmVlbiBzb3JlbHkgbWlz c2VkLiANCj4gSW4gYSBkb2N1bWVudCB3aGVyZSB5b3UgYXJlIGhvdCBvbiBvdmVybGF5cyAod2hp Y2ggaW1wbHkgbGF5ZXIgDQo+IGludmVyc2lvbnMpIHRoZSBtZW50aW9uIG9mIE9TSSBsYXllcnMg aXMgY2VydGFpbmx5ICJpbnRlcmVzdGluZyIuDQo+IA0KPiAtLS0NCj4gDQo+IE5vdHdpdGhzdGFu ZGluZyB5b3VyIGRlZmluaXRpb24gaW4gc2VjdGlvbiAxLjEsIHRoZSB0ZXJtICJTZXJ2aWNlIA0K PiBGdW5jdGlvbiIgcmVtYWlucyBhbWJpZ3VvdXMuIFVuZGVyIHlvdXIgZGVmaW5pdGlvbiwgYSBw YWNrZXQgZm9yd2FyZGVyDQo+IGlzIGEgc2VydmljZSBmdW5jdGlvbi4gV2hhdCBhYm91dCBhIHBh Y2tldCBjbGFzc2lmaWVyPw0KDQoNCkNvbWluZyB1cCB3aXRoIGEgU0YgZGVmaW5pdGlvbiBpcyBz b21ldGhpbmcgdGhlIFdHIHNwZW50IGEgbG90IG9mIHRpbWUgb24uICBTdHJpY3RseSBzcGVha2lu ZywgeW91IGFyZSBjb3JyZWN0LCB0aGUgY3VycmVudCBkZWZpbml0aW9uIHdvdWxkIGluY2x1ZGUg Zm9yd2FyZGVycy4gIEkgd2lsbCByYWlzZSB0aGUgcG9pbnQgd2l0aCB0aGUgV0cgYW5kIGdldCBz b21lIGZlZWRiYWNrIA0KDQoNCj4gDQo+IC0tLQ0KPiANCj4gU2VjdGlvbiAxLjEgU2VydmljZSBG dW5jdGlvbiBDaGFpbg0KPiBJIHN0dW1ibGVkIG92ZXIgIlRoZSBpbXBsaWVkIG9yZGVyIG1heSBu b3QgYmUgYSBsaW5lYXIgcHJvZ3Jlc3Npb24iLg0KPiBJIHRoaW5rIHlvdSBuZWVkIHMvaW1wbGll ZCBvcmRlci9vcmRlcmluZyBjb25zdHJhaW50cy8NCg0KSSB0aGluayBwZXJoYXBzIOKAnGRlZmlu ZWQgb3IgcHJlc2NyaWJlZCBvcmRlcuKAnSBpcyBtb3JlIGFjY3VyYXRlLg0KDQoNCg0KPiANCj4g LS0tDQo+IA0KPiBJIHN1c3BlY3QgMi4yIG5lZWRzIHRvIHNheSAicGh5c2ljYWwgdG9wb2xvZ3ki IHNpbmNlIHRoZSBwb2ludCBvZiB0aGlzDQo+IHdvcmsgaXMgdG8gaW50cm9kdWNlIG92ZXJsYXlz IHRoYXQgbWFrZSBjaGFuZ2VzIHRvIHRoZSBzZXJ2aWNlIHRvcG9sb2d5DQo+IHBvc3NpYmxlIHdp dGggc2ltcGxlIGNvbmZpZ3VyYXRpb24uDQo+IA0KDQoNCkdpdmVuIHRoYXQgMi4yIGNhbiBhbHNv IGFwcGx5IHRvIGEgbG9naWNhbCB1bmRlcmxheSAodGhlIG1vc3QgY29tbW9uIGNhc2UpLCBwZXJo YXBzIHdlIGFyZSBiZXN0IHNlcnZlZCBieSBzdGF0aW5nIHRoZSBsb2dpY2FsIG9yIHBoeXNpY2Fs IHVuZGVybGF5IHRvcG9sb2d5Lg0KDQo+IC0tLQ0KPiANCj4gU2VjdGlvbiAyLjMNCj4gDQo+IEZs aXAgdGhlIG9yZGVyIG9mIHRoZSBwYXJhZ3JhcGhzIHNvIHRoYXQgdGhlIGN1cnJlbnQgZmlyc3Qg cGFyYWdyYXBoDQo+IGhhcyBjb250ZXh0IGZvciBpdHMgc3RhdGVtZW50cy4gICAgICAgICAgICAg IA0KPiANCj4gSG93ZXZlciwgSSB0aGluayBJIGNvbnRlc3QgdGhlIHNjb3BlIG9mIHlvdXIgc3Rh dGVtZW50cy4gVGhleSBhcmUgDQo+IHRydWUgd2hlbiB0aGUgZmFpbHVyZSBpcyB0aGUgZmFpbHVy ZSBvZiBhIHNlcnZpY2UgZnVuY3Rpb24gYnV0IHRoZXJlIGlzDQo+IGNvbnRpbnVlZCBhYmlsaXR5 IHRvIGZvcndhcmQgdHJhZmZpYy4gVGhleSBhcmUgbm90IHRydWUgd2hlbiB0aGUgZmFpbHVyZQ0K PiBpcyBvZiBjb25uZWN0aXZpdHkgKHN1Y2ggYXMgYSBsaW5rKSBvciBvZiBmb3J3YXJkaW5nIChz dWNoIGFzIGEgc2VydmljZQ0KPiBmdW5jdGlvbiBub2RlKS4gSW4gdGhvc2UgY2FzZXMgImluIHRo ZSBzYW1lIHRvcG9sb2d5IiBtaWdodCBiZSBiZXR0ZXINCj4gcGhyYXNlZCBhcyAiaW4gcGFyYWxs ZWwgcGF0aHMgdGhyb3VnaCB0aGUgc2FtZSB0b3BvbG9neS7igJ0NCg0KPiAtLS0NCj4gDQo+IFNl Y3Rpb24gMi40IGlzIHNvbWV0aGluZyBvZiBhIG1hcmtldGluZyBzdGF0ZW1lbnQgd2hpY2ggaXMg YSBzaGFtZS4NCj4gQW55d2F5LCBpdCBjb25mbGljdHMgd2l0aCB0d28gdGhpbmdzIHdoZW4gaXQg c2F5czogDQo+ICAgU2VydmljZSBmdW5jdGlvbiBjaGFpbnMgdG9kYXkgYXJlIG1vc3QgdHlwaWNh bGx5IGJ1aWx0IHRocm91Z2ggbWFudWFsDQo+ICAgY29uZmlndXJhdGlvbiBwcm9jZXNzZXMuIFRo ZXNlIGFyZSBzbG93IGFuZCBlcnJvciBwcm9uZS4gIFdpdGggdGhlDQo+ICAgYWR2ZW50IG9mIG5l d2VyIHNlcnZpY2UgZGVwbG95bWVudCBtb2RlbHMNCj4gRmlyc3RseSwgdGhlIHByaW9yIHRleHQg Z2l2ZXMgdGhlIGltcHJlc3Npb24gdGhhdCB0aGUgc2VydmljZSBmdW5jdGlvbg0KPiBjaGFpbiBp cyBtb3N0IHR5cGljYWxseSBidWlsdCB0aHJvdWdoIHBoeXNpY2FsIGRlcGxveW1lbnQgb2Ygc2Vy dmljZQ0KPiBmdW5jdGlvbiBub2RlcyBhbG9uZyB0cmFmZmljIHBhdGhzIGFuZCB0aGVpciBzdWJz ZXF1ZW50IGNvbmZpZ3VyYXRpb24uDQo+IFNlY29uZGx5LCB0aGVyZSBpcyBsaXR0bGUgKGlmIGFu eSkgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgbWFudWFsIA0KPiBjb25maWd1cmF0aW9uIHByb2Nlc3Mg YW5kIGEgIm5ld2VyIHNlcnZpY2UgZGVwbG95bWVudCBtb2RlbCIuIFRoYXQgaXMsDQo+IGF1dG9t YXRpb24gb2YgY29uZmlndXJhdGlvbiBpcyBpZGVudGljYWwgaW4gZWZmZWN0IHRvIG1hbnVhbCAN Cj4gY29uZmlndXJhdGlvbi4NCj4gU3VyZWx5IHRoZSBkaXN0aW5jdGlvbiB5b3Ugd2FudCB0byBk cmF3IG91dCBpcyB0aGUgY2hhbmdlIGZyb20gcGh5c2ljYWwNCj4gcGxhY2VtZW50IG9mIHNlcnZp Y2UgZnVuY3Rpb24gbm9kZXMgYW5kIHRoZSBjb25zZXF1ZW50IGNvbnN0cmFpbnRzIG9uDQo+IG9y ZGVyaW5nIHdpdGggdGhlIHByb3Bvc2VkIHZpcnR1YWxpc2F0aW9uIG9mIHRvcG9sb2d5IHRocm91 Z2ggdGhlIA0KPiBvdmVybGF5IHRoYXQgYWxsb3dzIHNlcnZpY2UgZnVuY3Rpb24gbm9kZXMgdG8g YmUgbG9jYXRlZCBhbnl3aGVyZSBhbmQNCj4gY2hhaW5lZCBpbiBhcmJpdHJhcnkgb3JkZXJzLg0K PiANCg0KSSB0aGluayB3ZSBjYW4gY2xlYW4gdXAgMi40LiAgVGhlIGtleSBwb2ludCBvZiB0aGUg c2VjdGlvbiBpcyBpbiB0aGUgMXN0IHBhcmFncmFwaC4NCg0KDQo+IC0tLQ0KPiANCj4gSSB0aGlu ayB0aGUgY29uY2VwdCBvZiAidHJhbnNwb3J0IiBpbiBzZWN0aW9uIDIuNiB3aWxsIChvciBzaG91 bGQpIHJ1bg0KPiBpbnRvIHRoZSBjbGFzc2ljIHByb2JsZW0gb2YgdGhlIHR3byBtZWFuaW5ncyBv ZiAidHJhbnNwb3J0Ii4gQ2FuIHlvdSANCj4gbWFrZSB0aGUgdGV4dCBjbGVhcmVyIHRoYXQgeW91 IGFyZSBub3QgZGlzY3Vzc2luZyB3aGV0aGVyIFVEUCwgUlRQLCBTQ1RQDQo+IGV0Yy4gYXJlIGlu IHVzZS4NCj4gDQo+IOKAlA0KPiANCg0KWWVzLg0KDQoNCg0KPiBEb2VzIDIuNyBtZWFuICJmbGV4 aWJsZSIgaW5zdGVhZCBvZiAiZWxhc3RpYyI/DQo+IFdvdWxkIGl0IGJlIGdvb2QgdG8gaGF2ZSBl eHBsYWluZWQgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGFyZSANCj4gZGVzY3JpYmVkIGhlcmUg Zm9yIHRoZSBmaXJzdCB0aW1lPyBNYXliZSBhbiBlYXJseSBzZWN0aW9uIG9mIHRoZSANCj4gZG9j dW1lbnQgY291bGQgc3BlbmQgc29tZSAobW9yZSkgdGltZSBkZXNjcmliaW5nIGhvdyBTRkMgaXMg ZG9uZSB0b2RheS4NCg0KDQpEZXBlbmRzIG9uIGhvdyB5b3UgZGVmaW5lIGZsZXhpYmxlLiAgRWxh c3RpYyBoYXMgYW4gYWNjZXB0ZWQgaW1wbGljYXRpb24gYWJvdXQgc2NhbGluZyB1cCBhbmQgZG93 bi4gIElzIHRoYXQgeW91ciBkZWZuIG9mIGZsZXhpYmxlPw0KDQoNCg0KPiANCj4gLS0tDQo+IA0K PiBTaG91bGRuJ3QgMi44IHNheSAiLi4udW5sZXNzIHBhY2tldHMgYXJlIHJlY2xhc3NpZmllZCBh bmQgY2xhc3NpZmljYXRpb24NCj4gYmVoYXZpb3JzIGFyZSBjb25maWd1cmVkIGF0IGVhY2ggc2Vy dmljZSBmdW5jdGlvbiBub2Rl4oCdID8NCg0KVGhlIHBvaW50IGJlaW5nIG1hZGUgaGVyZSBpcyBz bGlnaHRseSBkaWZmZXJlbnQ6IGV2ZW4gaWYgYSBub2RlIHJlY2xhc3NpZmllcywgaXQgc3RpbGwg KG9mdGVuKSBoYXMgdG8gcmVseSBvbiBjb2Fyc2Ug4oCcc3RlZXJpbmfigJ0gbWVjaGFuaXNtcyB0 byBkaXJlY3QgdGhlIHRyYWZmaWMuICBPZiBjb3Vyc2UgdGhlIGxvY2FsIGdyYW51bGFyIGNsYXNz aWZpY2F0aW9uIGlzIHVzZWZ1bCBmb3IgbG9jYWwgcG9saWN5IGVuZm9yY2VtZW50IGJ1dCBub3Qg bmVjZXNzYXJpbHkgZm9yIGNoYWluaW5nLg0KDQoNCg0KPiBUaGUgcG9pbnQgYmVpbmcgdGhhdCBh IG1vcmUgZmxleGlibGUgYW5kIGdyYW51bGFyIFNGQyBtZWNoYW5pc20gKHN1Y2gNCj4gYXMgdGhl IFdHIGlzIHByb2R1Y2luZykgZWZmZWN0aXZlbHkgcGVyZm9ybXMgZmluZS1ncmFpbmVkIGNsYXNz aWZpY2F0aW9uDQo+IGF0IHRoZSBoZWFkIG9mIHRoZSBjaGFpbiBhbmQgdGhlbiAibWFya3MiIGVh Y2ggcGFja2V0IHdpdGggdGhlIHJlc3VsdCBvZg0KPiB0aGF0IGNsYXNzaWZpY2F0aW9uIHRocm91 Z2ggYSBjaGFpbiBpZGVudGlmaWVyLCB0aHJvdWdoIGEgY29tcG9zaXRlIA0KPiBjaGFpbiwgb3Ig aW4gbWV0YWRhdGEuDQoNClRoZSBnb2FsIGhlcmUgd2FzIHRvIGhpZ2hsaWdodCB0aGUgZXhpc3Rp bmcgaXNzdWUgd3J0IGNsYXNzaWZpY2F0aW9uIHZpcyBhIHZpcyBjaGFpbmluZy4gIFdlIGRlbGli ZXJhdGVseSBkaWQgbm90IHByZXNjcmliZSBzb2x1dGlvbiAoYnV0IHNlY3Rpb24gMy4yIGhpZ2hs aWdodHMgdGhlIHJlbGV2YW5jZSBvZiBjbGFzc2lmaWNhdGlvbiksIHJhdGhlciBsZWF2aW5nIHRo YXQgdG8gdGhlIGFyY2hpdGVjdHVyZSBkcmFmdC4gDQoNCg0KPiBXaGVyZSBhbiBvdmVybGF5IHRv cG9sb2d5IGlzIHVzZWQsIHlvdSBhcmUgbm90DQo+IGFjdHVhbGx5IGNoYW5naW5nIHRoZSBiZWhh dmlvciB5b3UgZGVzY3JpYmUgaW4gdGhpcyBzZWN0aW9uICh0aGUgbWFwcGluZw0KPiBvZiB0cmFm ZmljIG9uIGEgc2VnbWVudCBpbnRvIGEgc2VydmljZSBmdW5jdGlvbiBpcyBzdGlsbCBjb2Fyc2Up LCBidXQgDQo+IHlvdSBhcmUgY2hhbmdpbmcgdGhlIGdyYW51bGFyaXR5IG9mIHRoZSB0b3BvbG9n eS4NCg0KSSBub3Qgc3VyZSBJIGZvbGxvdzogd2UgYXJlIGNoYW5naW5nIHRoaXMgYmVoYXZpb3I6 IHRoZSBzZXJ2aWNlIHRvcG9sb2d5IHNlbGVjdGlvbiBpcyBiYXNlZCBvbiBjbGFzc2lmaWNhdGlv biAoYW5kIHBvc3NpYmxlIHJlLWNsYXNzaWZjYXRpb24pLg0KDQoNCj4gDQo+IC0tLQ0KPiANCj4g U2VjdGlvbiAyLjEwDQo+IA0KPiBJcyAibWF5IG5vdCIgIm1pZ2h0IG5vdCIsICJtdXN0IG5vdCIs IG9yICJjYW5ub3TigJ0/DQoNCkkgdGhpbmsgdGhhdCB3YXMgYSBjdXQgYW5kIHBhc3RlIGVycm9y OiDigJxtYXkgbm90IGJlIGFibGUgdG/igKYiDQoNCj4gLS0tDQo+IA0KPiBXaHkgZG9lc24ndCBz ZWN0aW9uIDMgbWVudGlvbiBlbmNhcHN1bGF0aW9uPyBJc24ndCB0aGlzIGEgbGFyZ2UgcGFydA0K PiBvZiB0aGUgd29yayBhbmQgc29sdXRpb24/DQo+IA0KDQpUaGUg4oCcZGF0YXBsYW5lIG1ldGFk YXRh4oCdIGJ1bGxldCB3YXMgbWVhbnQgdG8gaW1wbHkgZW5jYXAsIGJ1dCBJIGNhbiBzZWUgaG93 IGl0IGlzbuKAmXQgY2xlYXIgZW5vdWdoLiAgVGhhbmsgeW91Lg0KDQoNCj4gLS0tDQo+IA0KPiBJ IHNob3VsZCByZWFsbHkgYmUgaGFwcGllciB3ZXJlIFNlY3Rpb24gNCB0byBiZSByZW1vdmVkLiBJ IGRvbid0IGJlbGlldmUNCj4gaXQgYWRkcyBhbnl0aGluZywgaXQgaXMgKGJ5IGl0cyBvd24gYWRt aXNzaW9uKSBpbmNvbXBsZXRlIGFuZCBsZWF2ZXMgb25lDQo+IHRvIHdvbmRlciBhYm91dCB0aGUg c2lnbmlmaWNhbmNlIG9mIG9taXNzaW9ucywgYW5kIGl0IGlzIG91dCBvZiBkYXRlDQo+IGV2ZW4g YmVmb3JlIGl0IGlzIHB1Ymxpc2hlZC4NCj4gDQo+IEFjdHVhbGx5LCBJIGhhdmUgdGhpcyBwYXJ0 aWN1bGFyIENvbW1lbnQgYWxtb3N0IGF0IHRoZSBsZXZlbCBvZiBhIA0KPiBEaXNjdXNzOiB0aGlz IHNlY3Rpb24gaXMgaGFybWZ1bCB0byB0aGUgd29yayBvZiB0aGUgSUVURiBhbmQgZGV0cmFjdHMN Cj4gZnJvbSB0aGUgdmFsdWUgb2YgdGhpcyBkb2N1bWVudC4NCj4gDQoNCklJUkMsIHRoZXJlIHdh cyBhIHJlcXVlc3QgdG8gaW5jbHVkZSBpdCAoSeKAmWQgaGF2ZSB0byBjaGVjayB0aGUgYXJjaGl2 ZXMpLiAgU3BlYWtpbmcgYXMgYW4gZWRpdG9yLCBJ4oCZbSBoYXBweSB0byB0YWtlIGl0IG91dCwg YW5kIHdpbGwgb2YgY291cnNlIHJldmlldyB0aGF0IGNob2ljZSB3aXRoIHRoZSBXRy4NCg0KDQoN Cj4gLS0tDQo+IA0KPiBTZWN0aW9uIDUgKHJpZ2h0bHkpIG5vdGVzIHRoZSBjb250ZW50IHByZXNl bnQgaW4gU2VjdGlvbiAzLg0KPiBXaHkgZG9lc24ndCB0aGUgQWJzdHJhY3QgYWxzbyBtZW50aW9u IHdoYXQgd2lsbCBiZSBpbiBTZWN0aW9uIDM/DQo+IFdoeSBkb2Vzbid0IHRoZSBJbnRyb2R1Y3Rp b24gbWVudGlvbiB0aGUgY29udGVudCBvZiBTZWN0aW9uIDM/DQo+IFdoYXQgdmFsdWUgZG9lcyBT ZWN0aW9uIDUgYWRkIHRvIHRoZSBkb2N1bWVudD8NCg0KTGV0IG1lIHRyeSB0byBhdWdtZW50IHRo ZSBhYnN0cmFjdCwgYW5kIHJldmlldyB0aGUgY29uY2x1c2lvbi4NCg0KDQo+IA0KPiAtLS0NCj4g DQo+IFNlY3Rpb24gNyBpcyBkZWZpY2llbnQsIElNSE8uIFRoZSBwcm9ibGVtIHN0YXRlbWVudCBz aG91bGQgZGVzY3JpYmUgdGhlDQo+IHByb2JsZW0gb2Ygc2VjdXJpdHkgb2YgY29uZmlndXJhdGlv biBhbmQgY29uc3RydWN0aW9uIG9mIHNlcnZpY2UgY2hhaW5zDQo+IHRvZGF5LiBJdCBzaG91bGQg YWxzbyBvYnNlcnZlIHRoYXQgc29tZSBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgDQo+IHNwZWNpZmlj YWxseSBzZWN1cml0eSBmdW5jdGlvbnM6IHBsYWNpbmcgc3VjaCBmdW5jdGlvbnMgb24gdGhlIHBo eXNpY2FsIA0KPiBwYXRoIGVuc3VyZXMgdGhhdCB0aGV5IGFyZSBleGVjdXRlZCwgd2hpbGUgYWxs b3dpbmcgdGhlbSB0byBiZSBieS1wYXNzZWQNCj4gaW4gdGhlIG92ZXJsYXkgbmV0d29yayBvciBs ZWZ0IG91dCBvZiBhIGNoYWluIGlzIGEgY29uc2lkZXJhYmxlIHJpc2suDQo+IA0KPiBIb3dldmVy LCBJIHdpbGwgbGVhdmUgaXQgZm9yIHRoZSBTZWN1cml0eSBBRHMgdG8gZGVjaWRlIHdoZXRoZXIg dGhpcyANCj4gcG9pbnQgbmVlZHMgdG8gYmUgRGlzY3Vzc2VkLg0KPiANCg0KWWVzLCB3b3JraW5n IHdpdGggc2VjZGlyIG9uIHRoaXMuDQoNCg0KDQo+IC0tLQ0KPiANCj4gRGF2ZSBNY2R5c2FuIG5l ZWRzIGEgY2FwaXRhbCBEDQoNClRoYW5rIHlvdS4NCg0KDQo+IA0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0K PiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCg0K From nobody Mon Jan 12 08:41:06 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6051A6FF5 for ; Mon, 12 Jan 2015 08:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKefaHcTLsrz; Mon, 12 Jan 2015 08:38:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC9F1A1BB1; Mon, 12 Jan 2015 08:38:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: sfc-chairs@tools.ietf.org, draft-ietf-sfc-problem-statement@tools.ietf.org, jmh@joelhalpern.com, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112163834.22457.53595.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 08:38:34 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Mon, 12 Jan 2015 08:41:03 -0800 Subject: [sfc] ID Tracker State Update Notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 16:38:36 -0000 IESG state changed to AD Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead::Revised I-D Needed Various reviews (secdir and IESG) need changes that are technical. Therefore, this draft is going back to the WG for a quick update and additional WGLC. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Mon Jan 12 13:28:23 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB7D1ACDE7; Mon, 12 Jan 2015 13:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYvt2nqLfeJX; Mon, 12 Jan 2015 13:28:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C87B1A6F0A; Mon, 12 Jan 2015 13:28:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112212817.13116.3721.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 13:28:17 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-architecture-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 21:28:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining (SFC) Architecture Authors : Joel Halpern Carlos Pignataro Filename : draft-ietf-sfc-architecture-04.txt Pages : 27 Date : 2015-01-12 Abstract: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-architecture-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 13 06:12:12 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D041A8AF7; Tue, 13 Jan 2015 06:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCcFiJ1qm7Os; Tue, 13 Jan 2015 06:11:47 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529571A8A6C; Tue, 13 Jan 2015 06:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6770; q=dns/txt; s=iport; t=1421158308; x=1422367908; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=grRmuTTa25kerU47TSO/nLwhrGfNc0UfFm6TNoNkoOg=; b=B5mvrLMz6PMcp7H77X1JflffwtUWKI1azDdFnQxOVQbQQSft9zG6Nfds CUslg3BchN5rFaIsvuicJ57r+0DYtkOOyDcPM8x+kpqK4JfM3KhKNfO14 sqDa7clVAXwco19TkzSWSqUqjQKX7fgm6IAkVJD+MnSym62xggbLcGnx/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIHAEkntVStJA2B/2dsb2JhbABbgwaBKgSDAch8Ahx4QwEBAQEBfYQMAQEBAwEjEUUFCwIBCBgCAhEVAgICHxEVEAIEDgWIGAMJCLpdkAANg1EBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGIboNAgVIlMwcKgl4ugRMFhTaHMYFbhUuBfoFEgQ+CcogXhWQigjKBPG8BgQJCfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,750,1413244800"; d="scan'208";a="386607286" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP; 13 Jan 2015 14:11:47 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t0DEBkcD015206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 14:11:46 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.163]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 08:11:45 -0600 From: "Paul Quinn (paulq)" To: Kathleen Moriarty Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) Thread-Index: AQHQKrzRZ/IN5VrM6Emtyk3yZjMjpJy+hNMA Date: Tue, 13 Jan 2015 14:11:45 +0000 Message-ID: References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> In-Reply-To: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "jmh@joelhalpern.com" , "draft-ietf-sfc-problem-statement@tools.ietf.org" , The IESG , "sfc@ietf.org" , "sfc-chairs@tools.ietf.org" Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 14:12:04 -0000 SGkgS2F0aGxlZW4sDQoNCldlIGFyZSB3b3JraW5nIG15IHdheSB0aHJvdWdoIHRoZSBJRVNHIGNv bW1lbnRzLCB0aGFua3MgZm9yIHNlbmRpbmcgeW91cnMhDQoNClBsZWFzZSBzZWUgaW5saW5lLg0K DQpQYXVsDQoNCg0KPiBPbiBKYW4gNywgMjAxNSwgYXQgMzo1OCBQTSwgS2F0aGxlZW4gTW9yaWFy dHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEkgZGlkbid0 IHNlZSBhbnkgbWVudGlvbiBvZiByaXNrcyB3aXRoIG11bHRpcGxlIHRlbmFudHMgYW5kIHNoYXJl ZA0KPiBpbmZyYXN0cnVjdHVyZSBmb3Igc2VydmljZSBmdW5jdGlvbnMsIGlzIHRoYXQgYSBjb25j ZXJuPyAgVGhpcw0KPiBjb25zaWRlcmF0aW9uIG1heSBmYWxsIGludG8gdGhlIHNhbWUgZGVzY3Jp cHRpb24gYXMgdGhlIHNlY29uZCBwb2ludCBmcm9tDQo+IEJlbidzIFNlY0RpciByZXZpZXcgKGxp bmtlZCBpbiBTdGVwaGVuJ3MgcmV2aWV3KS4gQWx0aG91Z2ggdGhlIFNlY0Rpcg0KPiByZXZpZXcg cG9pbnQgY291bGQgYmUgd2l0aGluIGEgc2luZ2xlIHRlbmFudCBlbnZpcm9ubWVudCB3aGVyZSB0 aGVyZSBtYXkNCj4gb3IgbWF5IG5vdCBiZSB2YXJpb3VzIGxldmVscyBvZiB0cnVzdCBkZXBlbmRp bmcgb24gYWNjZXNzIGNvbnN0cmFpbnRzICh0bw0KPiB0aGUgc2FtZSBvciBkaWZmZXJlbnQgc2V0 IG9mIGFwcGxpY2F0aW9ucyBmb3IgYSBzaW5nbGUgdGVuYW50KS4gIEknZCBsaWtlDQo+IHRvIG1h a2Ugc3VyZSBib3RoIHBvaW50cyBnZXQgYWRkcmVzc2VkIG9yIGlmIHNvbWVvbmUgY2FuIHRlbGwg bWUgd2h5IGl0DQo+IGRvZXNuJ3QgbWF0dGVyLCB0aGF0IHdvdWxkIGJlIGZpbmUgdG9vLg0KPiAN Cj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4g SSBhZ3JlZSB3aXRoIEJhcnJ5LCBBbGlzc2EsIGFuZCBtYXliZSBvdGhlcnMgdGhhdCBhIHdpa2kg bWF5IGJlIGEgYmV0dGVyDQo+IG9wdGlvbiwgYnV0IEkgd29uJ3Qgc3RhbmQgaW4gdGhlIHdheSBv ZiBwdWJsaWNhdGlvbi4gIEkgZG8gdGhpbmsgdGhlDQo+IHByb2JsZW0gU0ZDIGlzIHdvcmtpbmcg b24gaXMgaW1wb3J0YW50IGFuZCB0aGUgd29yayB3aWxsIGJlIHdvcnRod2hpbGUsDQo+IGJ1dCB0 aGlzIGRyYWZ0IGlzbid0IHJlYWR5IHJlYWR5IG9yIG1heSBub3QgbmVlZCB0byBiZSBwdWJsaXNo ZWQuICAgDQoNCkhhdmluZyB3b3JrZWQgb24gU0ZDIHNpbmNlIHRoZSBmaXJzdCBCb0YgSSBzdHJv bmdseSBmZWVsIHRoYXQgYSBmb3JtYWwgcHJvYmxlbSBzdGF0ZW1lbnQgbmVlZHMgdG8gYmUgY29k aWZpZWQsIHBhcnRpY3VsYXJseSBpbiBhIHNwYWNlIHRoYXQgaXNu4oCZdCBhcyBmYW1pbGlhciB0 byBtYW55IGFzIG90aGVyIHdvcmtpbmcgZ3JvdXBzLiAgQXMgSSBtZW50aW9uZWQgdG8gQWxpYSwg dGhlcmUgaXMgYSBjbGVhciBuZWVkIGZvciB0aGUgaW5mb3JtYXRpb24sIGFuZCB0byBoYXZlIGl0 IG9mZmljaWFsbHkgZG9jdW1lbnRlZCBhcyBhbiBSRkMgZm9yIHRoZSByZXN0IG9mIHRoZSBXRyBl ZmZvcnRzLg0KDQoNCj4gDQo+IFRoZXJlIGFyZSBzdGlsbCBudW1lcm91cyBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyB0byBiZSBpbmNsdWRlZCBhcw0KPiBwb2ludGVkIG91dCBpbiB0aGUgU2VjRGly IHJldmlldyBhbmQgaW4gU3RlcGhlbidzIERJU0NVU1MgcG9pbnRzIHRoYXQgSQ0KPiBzdXBwb3J0 Lg0KPiANCg0KV2Ugd2lsbCBhdWdtZW50IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhcHBy b3ByaWF0ZWx5Lg0KDQoNCj4gVGhlIGRyYWZ0IG1lbnRpb25zIG9yZGVyaW5nIGZvciBzZXJ2aWNl IGZ1bmN0aW9ucywgYW5kIGl0IHdvdWxkIGJlIGdvb2QNCj4gdG8gc2VlIHNvbWUgY29uY3JldGUg ZXhhbXBsZXMgb2YgaG93IHNlY3VyaXR5IG1heSBiZSBhbiBpc3N1ZSB3aXRoDQo+IGRpZmZlcmVu dCBvcHRpb25zIGZvciBvcmRlcmluZy4gIFNpbmNlIFNGQydzIHNjb3BlIGlzIGEgc2luZ2xlDQo+ IGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgdGhlIHNlcnZpY2UgY2hhaW5pbmcgY291bGQgcmVzdWx0 IGluIHNlc3Npb24NCj4gZGVjcnlwdGlvbiBhdCB2YXJpb3VzIHBvaW50cyBpbiB0aGUgY2hhaW4g dGhhdCBjb3VsZCByZXN1bHQgaW4gc2VjdXJpdHkNCj4gYW5kIHByaXZhY3kgZXhwb3N1cmVzIHdp dGhpbiB0aGF0IGRvbWFpbiAodHlwaWNhbGx5IGNvbnNpZGVyZWQgYQ0KPiBtYW5hZ2VhYmxlIHJp c2spLg0KDQpCdXQgdGhpcyBpc27igJl0IHJlYWxseSB0aGUgZm9jdXMgb2YgU0ZDIFdHIGJlY2F1 c2UgdGhhdCBlbmNyeXB0L2RlY3J5cHQgY2FuIGhhcHBlbiB0b2RheSB1c2luZyB0aGUgZXhpdGlu ZyBzZXJ2aWNlIGluc2VydGlvbiB0ZWNobmlxdWVzLiAgV2hhdCB3ZSBhcmUgZm9jdXNlZCBvbiBo ZXJlIGlzIGhvdyB0byBpbXByb3ZlIHNlcnZpY2UgY2hhaW5pbmcgdGVjaG5vbG9neSwgd2UgZG9u 4oCZdCBnZXQgaW52b2x2ZWQgaW4gdGhlIGFjdHVhbCBzZXJ2aWNlcy4NCg0KDQo+ICAgRnVuY3Rp b25hbGl0eSBtYXkgYmUgbGltaXRlZCBmb3Igc29tZSBvZiB0aGUgc2VydmljZQ0KPiBmdW5jdGlv bnMgaWYgdGhlIGRlY3J5cHRpb24gZG9lcyBub3QgaGFwcGVuIHByaW9yIHRvIHRoYXQgcG9pbnQg YW5kIHJpc2sNCj4gcHJpb3JpdGl6YXRpb24gd2lsbCBiZSBuZWNlc3NhcnkgKGV4cG9zdXJlIG9m IGRhdGEsIHNlc3Npb24gaW50ZXJjZXB0aW9uLA0KPiBjb3JydXB0aW9uIG9mIGRhdGEsIGV0Yy4g Y291bGQgcmVzdWx0IGZyb20gdGhpcyBleHBvc3VyZSkgc2luY2UgdGhpcyBpcw0KPiBsaWtlbHkg dG8gYmUgdXNlZCBpbiBob3N0ZWQgZW52aXJvbm1lbnRzIHdpdGggbXVsdGlwbGUgdGVuYW50cy4g IFRoZQ0KPiBTZWNEaXIgcmV2aWV3IGRpZCBtZW50aW9uIGNyb3Nzb3ZlciBiZXR3ZWVuIG1hbmFn ZW1lbnQvY29udHJvbCBhbmQgZGF0YQ0KPiBwbGFuZXMsIGJ1dCB0ZW5hbnQgaXNvbGF0aW9uIG1h eSBhbHNvIG5lZWQgdG8gYmUgbWVudGlvbmVkLg0KPiANCj4gU29tZSBuaXRzIChJIGRvbid0IHRo aW5rIG90aGVycyBtZW50aW9uZWQgdGhlc2UsIGJ1dCBzb3JyeSBpZiB0aGV5IHdlcmUNCj4gYWxy ZWFkeSBhZGRyZXNzZWQpOg0KPiBTZWN0aW9uIDIuMTogM3JkIHBhcmFncmFwaDoNCj4gSXMgdGhp cyBpbnRlbmRlZCB0byBtZWFuIGFmdGVyIGEgbmV3IHNlcnZpY2UgZnVuY3Rpb24gaXMgYWRkZWQ/ ICBJIGNhbid0DQo+IGltYWdpbmUgdGhhdCB0aGlzIG91ciBoYXBwZW4gb24gdGhlIGZseSwgc28g SSB0aGluayB0aGF0J3MgdGhlIGNhc2UgYW5kDQo+IGFkZGluZyBhIHdvcmQgb3IgdHdvIG1heSBo ZWxwOg0KPiBmcm9tOg0KPiAgIEFzIG1vcmUgc2VydmljZSBmdW5jdGlvbnMgYXJlIHJlcXVpcmVk IC0gb2Z0ZW4gd2l0aCBzdHJpY3Qgb3JkZXJpbmcgLQ0KPiAgIHRvcG9sb2d5IGNoYW5nZXMgYXJl IG5lZWRlZCBiZWZvcmUgYW5kIGFmdGVyIGVhY2ggc2VydmljZSBmdW5jdGlvbiBpcw0KPiBhZGRl ZA0KPiAgIHJlc3VsdGluZyBpbiBjb21wbGV4IG5ldHdvcmsgY2hhbmdlcyBhbmQgZGV2aWNlIGNv bmZpZ3VyYXRpb24uICANCg0KVGhhbmsgeW91LCB3ZeKAmWxsIG1ha2UgdGhhdCBwYXJhZ3JhcGgg bW9yZSBzcGVjaWZpYy4NCg0KPiANCj4gNHRoIHBhcmFncmFwaDogIEknbSBoYXZlIHRyb3VibGUg cmVhZGluZyB0aGlzIHBhcmFncmFwaCBhcyBJIHRoaW5rIGl0DQo+IGNvbnRyYWRpY3RzIGl0c2Vs ZiwgYnV0IHRoZSBleGFtcGxlIGluIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoIGlzDQo+IGhlbHBm dWwuICBJZiB0b3BvbG9neSBkaWN0YXRlcyBwbGFjZW1lbnQsIGhvdyBjb3VsZCB1c2luZyB0b3Bv bG9neSBub3QgYmUNCj4gdmlhYmxlPyAgTWF5YmUgcmV3b3JkaW5nIGl0IHdvdWxkIGhlbHA6DQo+ ICAgVGhlIHRvcG9sb2dpY2FsIGNvdXBsaW5nIGxpbWl0cyBwbGFjZW1lbnQgYW5kIHNlbGVjdGlv biBvZiBzZXJ2aWNlDQo+ICAgZnVuY3Rpb25zOiBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgImZpeGVk IiBpbiBwbGFjZSBieSB0b3BvbG9neSBhbmQNCj4gICB0aGVyZWZvcmUgcGxhY2VtZW50IGFuZCBz ZXJ2aWNlIGZ1bmN0aW9uIHNlbGVjdGlvbiB0YWtpbmcgaW50bw0KPiAgIGFjY291bnQgbmV0d29y ayB0b3BvbG9neSBpbmZvcm1hdGlvbiBpcyBub3QgdmlhYmxlLiAgRnVydGhlcm1vcmUsDQo+ICAg YWx0ZXJpbmcgdGhlIHNlcnZpY2VzIHRyYXZlcnNlZCwgb3IgdGhlaXIgb3JkZXIsIGJhc2VkIG9u IGZsb3cNCj4gICBkaXJlY3Rpb24gaXMgbm90IHBvc3NpYmxlLg0KPiANCg0KVGhlIGludGVudCBo ZXJlIHdhcyB0byBjb252ZXkgdGhhdCBwbGFjZW1lbnQgaXNu4oCZdCBkeW5hbWljLCBhbmQgb25l IGZ1bmN0aW9ucyBhcmUg4oCcaW5zZXJ0ZWTigJ0gYW4gb3BlcmF0b3IgY2Fubm90IGVhc2lseSB0 YWtlIG5ldHdvcmsgaW5mb3JtYXRpb24gaW50byBhY2NvdW50IGlmL3doZW4gdGhpbmdzIG5lZWQg dG8gY2hhbmdlIG9yIGJlIHVwZGF0ZWQuICBJbiBvdGhlciB3b3JkcywgdGhlIHRvcG9sb2d5IGRp Y3RhdGVzIHBsYWNlbWVudCwgcmF0aGVyIHRoYW4gdGhlIHRyYWZmaWMuICBJIGFncmVlIHRoZSB0 ZXh0IGRvZXMgZXhwbGFpbiBpdCB3ZWxsIGFuZCB3aWxsIGNsZWFuIGl0IHVwLg0KDQoNCj4gVGhh bmtzLA0KPiBLYXRobGVlbg0KPiANCg0KVGhhbmtzIGFnYWluIQ0KUGF1bA== From nobody Tue Jan 13 09:17:25 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4AF1A8FD7 for ; Tue, 13 Jan 2015 09:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR67j0q3-3KH for ; Tue, 13 Jan 2015 09:17:21 -0800 (PST) Received: from sangam.sce.carleton.ca (sangam.sce.carleton.ca [134.117.56.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA4F1A8FD3 for ; Tue, 13 Jan 2015 09:17:21 -0800 (PST) Received: from MacPC2 (206-188-90-150.cpe.distributel.net [206.188.90.150]) (authenticated bits=0) by sangam.sce.carleton.ca (8.14.4/8.14.4) with ESMTP id t0DHHF3w009799 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 13 Jan 2015 12:17:15 -0500 From: "Changcheng Huang" To: Date: Tue, 13 Jan 2015 12:17:15 -0500 Organization: Carleton University Message-ID: <002601d02f54$c7803190$568094b0$@carleton.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAvU2GZodwPc5OsQtekbocIEG8LmQAAFCFA Content-Language: en-us Archived-At: Subject: [sfc] revised use case draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huang@sce.carleton.ca List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 17:17:24 -0000 We have posted a revised use case draft on recursive SFC service. In = this revision, we added a scenario that recursive service is delegated = to a single administrator and therefore is implemented in a single = domain. Your comments are welcome. Best regards, Chang -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Tuesday, January 13, 2015 12:07 PM To: Jiafeng Zhu; Peng He; Jiafeng Zhu; Changcheng Huang; Peng He; = Changcheng Huang Subject: New Version Notification for = draft-huang-sfc-use-case-recursive-service-01.txt A new version of I-D, draft-huang-sfc-use-case-recursive-service-01.txt has been successfully submitted by Changcheng Huang and posted to the = IETF repository. Name: draft-huang-sfc-use-case-recursive-service Revision: 01 Title: SFC Use Cases on Recursive Services Document date: 2015-01-13 Group: Individual Submission Pages: 8 URL: = http://www.ietf.org/internet-drafts/draft-huang-sfc-use-case-recursive-se= rvice-01.txt Status: = https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recursive-servi= ce/ Htmlized: = http://tools.ietf.org/html/draft-huang-sfc-use-case-recursive-service-01 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-huang-sfc-use-case-recursive-ser= vice-01 Abstract: Service function chaining (SFC) provides various services that can be tailored to different requirements from diversified user groups, where each user group forms a collective client that requires similar service. SFC is typically deployed as a service overlay with its own service topology on top of existing network topology. This kind of virtualized structure naturally enables recursive service relationship where a client may become a service provider and resell SFC services to its own user groups. Alternatively, a client may also choose to ask its service provider to provide a structured service for its user groups. This document describes some exemplary use cases that show the usage of recursive (e.g. nested) or structured service function chaining relationship. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Tue Jan 13 13:33:40 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4AF1B29A6; Tue, 13 Jan 2015 13:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD2yWRdq5I_Z; Tue, 13 Jan 2015 13:33:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FBC1AD49D; Tue, 13 Jan 2015 13:33:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113213337.5779.4840.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 13:33:37 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 21:33:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Use Cases in Mobile Networks Authors : Walter Haeffner Jeffrey Napper Martin Stiemerling Diego R. Lopez Jim Uttaro Filename : draft-ietf-sfc-use-case-mobility-03.txt Pages : 25 Date : 2015-01-13 Abstract: This document provides some exemplary use cases for service function chaining in mobile service provider networks. The objective of this draft is not to cover all conceivable service chains in detail. Rather, the intention is to localize and explain the application domain of service chaining within mobile networks as far as it is required to complement the problem statement [ietf-sfc-problem-statement] and architecture framework [ietf-sfc-arch] of the working group. Service function chains typically reside in a LAN segment which links the mobile access network to the actual application platforms located in the carrier's datacenters or somewhere else in the Internet. Service function chains (SFC) ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery or take care of security and privacy. SFCs may also include Value Added Services (VAS). Commonly, SFCs are typical middlebox services. General considerations and specific use cases are presented in this document to demonstrate the different technical requirements of these goals for service function chaining in mobile service provider networks. The specification of service function chaining for mobile networks must take into account an interaction between service function chains and the 3GPP Policy and Charging Control (PCC) environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-use-case-mobility-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 13 13:36:47 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23251B29A5 for ; Tue, 13 Jan 2015 13:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3utCXeUVx52Z for ; Tue, 13 Jan 2015 13:36:43 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735D71B29A4 for ; Tue, 13 Jan 2015 13:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3338; q=dns/txt; s=iport; t=1421185003; x=1422394603; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jqMBwz/X+FAaFSIkUhMAaD3Gj4esDdCRLTx5Xp/8G84=; b=Ht6wVfv0DlnsJwiBQf8hbDL5r0h9aFSADZVz65McAfXKAYORJqvKKULF Umj/x7OtG3riEGAZm85C5Q5jx1dcw2eC8RB8MONZdOyz6NhjNxM7yGrJC fEb0Ol57av+yz1g5S6lCTvDpvLQ6+AU33H4Uhu1IINT76yIcuhjdZFWDl E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsGAE+PtVStJA2L/2dsb2JhbABbgwZSUwUEw2+CGwqFcQKBG0MBAQEBAX2EDAEBAQQBAQE3LQcXBAIBCBEBAgECFgkQJwsXBggCBBMJiCMIBc9zAQEBAQEBBAEBAQEBAQEbkAAGBIQfBY5Cg0WFSIEPMIJCjXsig25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,751,1413244800"; d="scan'208";a="112937219" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP; 13 Jan 2015 21:36:42 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t0DLafaC007767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 13 Jan 2015 21:36:41 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.7]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 15:36:41 -0600 From: "Jeffrey Napper (jenapper)" To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-03.txt Thread-Index: AQHQL3ieVsfVjhtEjEOMVqiCbol+d5y/CE4A Date: Tue, 13 Jan 2015 21:36:40 +0000 Message-ID: References: <20150113213337.5779.4840.idtracker@ietfa.amsl.com> In-Reply-To: <20150113213337.5779.4840.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.67.175] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 21:36:45 -0000 This is just a revision over -02 to add page numbers because I erroneously used the unpaginated txt source for -02. Sorry for the confusion. Cheers, Jeff -----Original Message----- From: "internet-drafts@ietf.org" Date: Tuesday, January 13, 2015 at 10:33 PM To: "i-d-announce@ietf.org" Cc: "sfc@ietf.org" Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-03.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Service Function Chaining Working Group >of the IETF. > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Martin Stiemerling > Diego R. Lopez > Jim Uttaro > Filename : draft-ietf-sfc-use-case-mobility-03.txt > Pages : 25 > Date : 2015-01-13 > >Abstract: > This document provides some exemplary use cases for service function > chaining in mobile service provider networks. The objective of this > draft is not to cover all conceivable service chains in detail. > Rather, the intention is to localize and explain the application > domain of service chaining within mobile networks as far as it is > required to complement the problem statement > [ietf-sfc-problem-statement] and architecture framework > [ietf-sfc-arch] of the working group. > > Service function chains typically reside in a LAN segment which links > the mobile access network to the actual application platforms located > in the carrier's datacenters or somewhere else in the Internet. > Service function chains (SFC) ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery or take care of security and privacy. > SFCs may also include Value Added Services (VAS). Commonly, SFCs are > typical middlebox services. > > General considerations and specific use cases are presented in this > document to demonstrate the different technical requirements of these > goals for service function chaining in mobile service provider > networks. > > The specification of service function chaining for mobile networks > must take into account an interaction between service function chains > and the 3GPP Policy and Charging Control (PCC) environment. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-use-case-mobility-03 > > >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/ > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Jan 15 09:11:09 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F128E1B2D02 for ; Thu, 15 Jan 2015 09:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coXM5y-1v7wC for ; Thu, 15 Jan 2015 09:11:05 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8CC1B2CE5 for ; Thu, 15 Jan 2015 09:11:03 -0800 (PST) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail21.telekom.de with ESMTP; 15 Jan 2015 18:10:59 +0100 X-IronPort-AV: E=Sophos;i="5.09,404,1418079600"; d="scan'208";a="197717071" Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 15 Jan 2015 18:10:58 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Thu, 15 Jan 2015 18:10:58 +0100 From: To: Date: Thu, 15 Jan 2015 18:10:56 +0100 Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt Thread-Index: AQHQLOiZ6FGB0rIHEEenftRW8YaHK5y83WEAgARxW6A= Message-ID: <05C81A773E48DD49B181B04BA21A342A2F7390694C@HE113484.emea1.cds.t-internal.com> References: <20150110151735.24428.85673.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 17:11:08 -0000 Dear authors, Thanks for the update of the mobility SFC use cases draft. IMO the document= is quite useful for further discussion on real-life applicability of SFC w= ork.=20 Just some minor comments below (mainly nit and typo picking, clarification = proposals, and further smithing ...) Sorry for that ;-) and thanks for all your work! Best regards Dirk ... p.3 HSS Home Subscriber System =3D> HSS Home Subscriber Server GTP GPRS (General Packet Radio Service) Tunnel Protocol =3D> GTP GPRS (Ge= neral Packet Radio Service) Tunnelling Protocol p.4: Important use cases classes =3D> Important use case classes p.5: 4. functions like CG-NAT/PAT =3D> 4. functions like CG-NAT/NAPT (not = sure about PAT!?) P-GW, a xDSL network =3D> P-GW, an xDSL network p.6: basically only seen in mobile networks only. The same may be true for video optimizers or HTTP header enrichment =3D> basically seen in mobile networks only. The same may be true for video optimizers or HTTP header enrichment entities p.7: The major functional components of a LTE network =3D> The major functi= onal components of an LTE network Figure 2 shows the end to end context including all major components of a LTE network. The actual 3GPP mobile network includes the elements from the user equipment [UE] to the packet gateway [P-GW]. Figure 2: End to end context including all major components of a LTE network. The actual 3GPP mobile network includes the elements from the user equipment [UE] to the packet gateway [P-GW]. =3D> I propose to exchange the lower caption with the upper text and use '_= an_ LTE' (;-)) according 3GPP standards. =3D> according to 3GPP standards. =20 p.8: [TS.29.061], but service function chaining is not specified by 3GPP.=20 =3D> one may add: A study on typical exemplary SFC use cases and potential requirements has b= een performed by 3GPP recently [TR.22.808] in the framework of Rel. 13. [TR.22.808] "Study on Flexible Mobile Service Steering (FMSS)", 3GPP TR 22= .808 V13.0.0, September 2014. to differentiate their services to their subscribers and reflect the business model and of mobile operators. =3D> to differentiate their services to their subscribers and reflect the business model and to distinguish between th= emselves and other mobile operators. (?) p.10: devices address use Access Point Names (APNs) to address a service =3D> = devices use Access Point Names (APNs) to address a service While a FQDN =3D> While an FQDN p.11: UE: terminal type (e.g., HTC one), =3D> UE: terminal type (e.g., ph= one capability, OS, vendor, ...), (?) <=3D [I suggest to omit real product = names here] 3GPP PCC (Policy and Charging Architecture, [TS.23.203])=20 =3D> 3GPP PCC (Policy and Charging Control Architecture, [TS.23.203]) p.14: Specifically, the Steering Proxy includes a TCP proxy and an ICAP Client =3D> Specifically, the Steering Proxy includes a TCP proxy and an ICAP (= Internet Content Adaptation Protocol) Client [include reference?] p.18: PCRF and the link would be a Gx or Diameter-based Sd interface. =3D> = PCRF and the link would be via a Gx or Diameter-based Sd reference point.=20 [correspondingly also on p.21] p.19: individual VRF implementations etc. =3D> individual VRF (virtual rout= ing and forwarding) implementations etc. [reference to add?] related metadata is extremely diffcult. =3D> related metadata i= s extremely difficult. p.21: methods in a service chain. Typically this data =3D> methods in a se= rvice chain. Typically these data plane. A mechanism where such metadata is carried =3D> plane. A mec= hanism where such metadata are carried p.22: o asynchronously from the control plain =3D> o asynchronously from = the control plane=20 o synchrounously, piggypacked with the user IP packet =3D> o synchro= nously, piggypacked with the user IP packet * or carried with http header enrichements =3D> * or carried = with http header enrichments -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jeffrey Napper (jenapp= er) Sent: Montag, 12. Januar 2015 13:12 To: internet-drafts@ietf.org; i-d-announce@ietf.org Cc: sfc@ietf.org Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt This draft is largely wordsmithing and typos. There are a couple of new par= agraphs that are available from the diff tool. Please send comments and suggestions to the list as we believe the document= is ready for last call. The document seems to be quite stable now. Cheers, Jeff -----Original Message----- From: "internet-drafts@ietf.org" Date: Saturday, January 10, 2015 at 4:17 PM To: "i-d-announce@ietf.org" Cc: "sfc@ietf.org" Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Service Function Chaining Working=20 >Group of the IETF. > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Martin Stiemerling > Diego R. Lopez > Jim Uttaro > Filename : draft-ietf-sfc-use-case-mobility-02.txt > Pages : 20 > Date : 2015-01-10 > >Abstract: > This document provides some exemplary use cases for service function > chaining in mobile service provider networks. The objective of this > draft is not to cover all conceivable service chains in detail. > Rather, the intention is to localize and explain the application > domain of service chaining within mobile networks as far as it is > required to complement the problem statement > [ietf-sfc-problem-statement] and architecture framework > [ietf-sfc-arch] of the working group. > > Service function chains typically reside in a LAN segment which links > the mobile access network to the actual application platforms located > in the carrier's datacenters or somewhere else in the Internet. > Service function chains (SFC) ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery or take care of security and privacy. > SFCs may also include Value Added Services (VAS). Commonly, SFCs are > typical middlebox services. > > General considerations and specific use cases are presented in this > document to demonstrate the different technical requirements of these > goals for service function chaining in mobile service provider > networks. > > The specification of service function chaining for mobile networks > must take into account an interaction between service function chains > and the 3GPP Policy and Charging Control (PCC) environment. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-use-case-mobility-02 > > >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/ > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jan 19 11:22:01 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9FB1B2C0F; Mon, 19 Jan 2015 11:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8aTe8u4BswF; Mon, 19 Jan 2015 11:21:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 946E91B2C12; Mon, 19 Jan 2015 11:21:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119192140.5504.44423.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 11:21:40 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 19:21:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Use Cases In Data Centers Authors : Surendra Kumar Mudassir Tufail Sumandra Majee Claudiu Captari Shunsuke Homma Filename : draft-ietf-sfc-dc-use-cases-02.txt Pages : 23 Date : 2015-01-19 Abstract: Data center operators deploy a variety of layer 4 through layer 7 service functions in both physical and virtual form factors. Most traffic originating, transiting, or terminating in the data center is subject to treatment by multiple service functions. This document describes use cases that demonstrate the applicability of Service Function Chaining (SFC) within a data center environment and provides SFC requirements for data center centric use cases, with primary focus on Enterprise data centers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-dc-use-cases-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-dc-use-cases-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 19 11:26:54 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299571B2B84 for ; Mon, 19 Jan 2015 11:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98qOQLrRyY8g for ; Mon, 19 Jan 2015 11:26:48 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABB71B2C0B for ; Mon, 19 Jan 2015 11:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2104; q=dns/txt; s=iport; t=1421695606; x=1422905206; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9UiIEAnE05ztN4g+jFlpGL+/z7C9Ifj1qo+nT0W1NsE=; b=Y4T4qY38HWTC5ZONFwAQZJBmVWJDK0m0tr5TaRI7u4ZjGZjququlLaxI ZY2Vb8qDTTqBHcYAG8ZeGNcnGfiV7yvjxWTxavYukbBMLvHDPFL8WY9I9 SGRG1y3wgABjUhN2e1hC4amfqyyFP4Y2UgZ5Chjo84UabpQZU05BnXam1 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAJxZvVStJA2L/2dsb2JhbABbgwZSUwnGOQqFcQKBJEMBAQEBAX2EDQEBBAEBATc0GwIBCDYQJwslAgQTCYgjCAXOcwEBAQEBAQQBAQEBAQEBG5AAhCkFjlmDR4VQgRQ2gkaOGiKDbm+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.09,428,1418083200"; d="scan'208";a="114674989" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP; 19 Jan 2015 19:26:45 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t0JJQi66030139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 19 Jan 2015 19:26:44 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.25]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Mon, 19 Jan 2015 13:26:44 -0600 From: "Surendra Kumar (smkumar)" To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-02.txt Thread-Index: AQHQNB07KXhXFkyLWUe00I1L7931o5zHsfMA Date: Mon, 19 Jan 2015 19:26:43 +0000 Message-ID: References: <20150119192140.5504.44423.idtracker@ietfa.amsl.com> In-Reply-To: <20150119192140.5504.44423.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.210.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <811B4DA31CEF38419D45F1D872AF2F31@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 19:26:52 -0000 This revision includes very minor updates in the form of corrected-typos and some wording. Thanks, Surendra. On 1/19/15, 11:21 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Service Function Chaining Working Group >of the IETF. > > Title : Service Function Chaining Use Cases In Data >Centers > Authors : Surendra Kumar > Mudassir Tufail > Sumandra Majee > Claudiu Captari > Shunsuke Homma > Filename : draft-ietf-sfc-dc-use-cases-02.txt > Pages : 23 > Date : 2015-01-19 > >Abstract: > Data center operators deploy a variety of layer 4 through layer 7 > service functions in both physical and virtual form factors. Most > traffic originating, transiting, or terminating in the data center is > subject to treatment by multiple service functions. > > This document describes use cases that demonstrate the applicability > of Service Function Chaining (SFC) within a data center environment > and provides SFC requirements for data center centric use cases, with > primary focus on Enterprise data centers. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-sfc-dc-use-cases-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-dc-use-cases-02 > > >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/ > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jan 20 12:46:59 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1D11B2B69; Tue, 20 Jan 2015 12:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVGWq4t7uRMu; Tue, 20 Jan 2015 12:28:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC4A1B2B01; Tue, 20 Jan 2015 12:28:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: iesg-secretary@ietf.org, iesg@ietf.org, sfc@ietf.org, sfc-chairs@tools.ietf.org, jmh@joelhalpern.com, draft-ietf-sfc-problem-statement@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120202839.18076.54955.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 12:28:39 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Tue, 20 Jan 2015 12:46:57 -0800 Subject: [sfc] Telechat update notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 20:28:40 -0000 Removed from agenda for telechat ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Tue Jan 20 12:47:01 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4811C1B2B6E for ; Tue, 20 Jan 2015 12:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLgOWBnQTu9s; Tue, 20 Jan 2015 12:28:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A64C41B2B69; Tue, 20 Jan 2015 12:28:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: sfc-chairs@tools.ietf.org, draft-ietf-sfc-problem-statement@tools.ietf.org, jmh@joelhalpern.com, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120202851.13301.34807.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 12:28:51 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Tue, 20 Jan 2015 12:46:57 -0800 Subject: [sfc] ID Tracker State Update Notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 20:28:55 -0000 IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Wed Jan 21 04:57:44 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB6B1A1A73 for ; Wed, 21 Jan 2015 04:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoHDxnqXRyUI for ; Wed, 21 Jan 2015 04:57:39 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE941A1A54 for ; Wed, 21 Jan 2015 04:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8909; q=dns/txt; s=iport; t=1421845059; x=1423054659; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PZ0lwlA7kxDrWuL7LiQBg6GamGS/veevsuAIITqnw7M=; b=UG5gm2Qfr5P/7R2Vx8IdWynXxdLC6GmWMFgSUFBdD4Bob2W9ycbYt+eW lTYyLUUBDHE5qFzq667ExwkHb8hxzwkdYcx2xHoT+Z+pFadqnQuihsipJ ENtXWPqFkS5IuphEaQbBBiKZ7jP1v6YDyFnBI1lgreKhhbtoO/Vt9loVb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAHOhv1StJV2Y/2dsb2JhbABbgwZSUwUEw3GCGwqFcQKBJkMBAQEBAX2EDAEBAQQBAQE3LQcLDAQCAQgRAQIBAQEWCQkHJwsUAwYIAgQOBQkQiBMIBdE8AQEBAQEBAQECAQEBAQEBAQEBAQEXj04rBwYEhB8FjlmDR4VQgRQ2gkaHbIJxgz0ig25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.09,441,1418083200"; d="scan'208";a="389427684" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 21 Jan 2015 12:57:37 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t0LCvbGA022506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Jan 2015 12:57:37 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.7]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Wed, 21 Jan 2015 06:57:37 -0600 From: "Jeffrey Napper (jenapper)" To: "Dirk.von-Hugo@telekom.de" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt Thread-Index: AQHQLOiZ6FGB0rIHEEenftRW8YaHK5y83WEAgARxW6CACcBygA== Date: Wed, 21 Jan 2015 12:57:36 +0000 Message-ID: References: <20150110151735.24428.85673.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2F7390694C@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2F7390694C@HE113484.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.198.89] Content-Type: text/plain; charset="us-ascii" Content-ID: <486799CBD437034386DF770243847AC9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 12:57:42 -0000 Thanks for the corrections, Dirk. I have added almost all of them to the next revision including the FMSS reference, which was a good catch. I edited the last one on p8 differently because there was simply an extraneous 'and' to be deleted. Cheers, Jeff -----Original Message----- From: "Dirk.von-Hugo@telekom.de" Date: Thursday, January 15, 2015 at 6:10 PM To: Jeffrey Napper Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt >Dear authors, >Thanks for the update of the mobility SFC use cases draft. IMO the >document is quite useful for further discussion on real-life >applicability of SFC work. > >Just some minor comments below (mainly nit and typo picking, >clarification proposals, and further smithing ...) >Sorry for that ;-) and thanks for all your work! > >Best regards >Dirk > >... >p.3 >HSS Home Subscriber System =3D> HSS Home Subscriber Server >GTP GPRS (General Packet Radio Service) Tunnel Protocol =3D> GTP GPRS >(General Packet Radio Service) Tunnelling Protocol > >p.4: >Important use cases classes =3D> Important use case classes > >p.5: > 4. functions like CG-NAT/PAT =3D> 4. functions like CG-NAT/NAPT (not >sure about PAT!?) >P-GW, a xDSL network =3D> P-GW, an xDSL network > >p.6: > basically only seen in mobile networks only. The same may be true > for video optimizers or HTTP header enrichment >=3D> basically seen in mobile networks only. The same may be true > for video optimizers or HTTP header enrichment entities > >p.7: > The major functional components of a LTE network =3D> The major >functional components of an LTE network > > Figure 2 shows the end to end context including all major components > of a LTE network. The actual 3GPP mobile network includes the > elements from the user equipment [UE] to the packet gateway [P-GW]. > > Figure 2: End to end context including all major components of a LTE > network. The actual 3GPP mobile network includes the elements from > the user equipment [UE] to the packet gateway [P-GW]. > >=3D> I propose to exchange the lower caption with the upper text and use >'_an_ LTE' (;-)) > >according 3GPP standards. =3D> according to 3GPP standards. > >p.8: > [TS.29.061], but service function chaining is not specified by 3GPP. >=3D> one may add: >A study on typical exemplary SFC use cases and potential requirements has >been performed by 3GPP recently [TR.22.808] in the framework of Rel. 13. >[TR.22.808] "Study on Flexible Mobile Service Steering (FMSS)", 3GPP TR >22.808 V13.0.0, September 2014. > >to differentiate their services to their > subscribers and reflect the business model and of mobile operators. >=3D> to differentiate their services to their > subscribers and reflect the business model and to distinguish between >themselves and other mobile operators. (?) > >p.10: > devices address use Access Point Names (APNs) to address a service =3D> > devices use Access Point Names (APNs) to address a service > While a FQDN =3D> While an FQDN > >p.11: > UE: terminal type (e.g., HTC one), =3D> UE: terminal type (e.g., >phone capability, OS, vendor, ...), (?) <=3D [I suggest to omit real >product names here] >3GPP PCC (Policy > and Charging Architecture, [TS.23.203]) >=3D> 3GPP PCC (Policy > and Charging Control Architecture, [TS.23.203]) > >p.14: > Specifically, the Steering Proxy includes a TCP proxy and an ICAP > Client >=3D> Specifically, the Steering Proxy includes a TCP proxy and an ICAP >(Internet Content Adaptation Protocol) > Client [include reference?] > >p.18: > PCRF and the link would be a Gx or Diameter-based Sd interface. =3D> >PCRF and the link would be via a Gx or Diameter-based Sd reference point. >[correspondingly also on p.21] > >p.19: > individual VRF implementations etc. =3D> individual VRF (virtual >routing and forwarding) implementations etc. [reference to add?] > related metadata is extremely diffcult. =3D> related metadata >is extremely difficult. > >p.21: > methods in a service chain. Typically this data =3D> methods in a >service chain. Typically these data > plane. A mechanism where such metadata is carried =3D> plane. A >mechanism where such metadata are carried > >p.22: > o asynchronously from the control plain =3D> o asynchronously from >the control plane=20 > o synchrounously, piggypacked with the user IP packet =3D> o >synchronously, piggypacked with the user IP packet > * or carried with http header enrichements =3D> * or carried >with http header enrichments > > > > -----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jeffrey Napper >(jenapper) >Sent: Montag, 12. Januar 2015 13:12 >To: internet-drafts@ietf.org; i-d-announce@ietf.org >Cc: sfc@ietf.org >Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt > >This draft is largely wordsmithing and typos. There are a couple of new >paragraphs that are available from the diff tool. > >Please send comments and suggestions to the list as we believe the >document is ready for last call. The document seems to be quite stable >now. > > >Cheers, >Jeff > > > >-----Original Message----- >From: "internet-drafts@ietf.org" >Date: Saturday, January 10, 2015 at 4:17 PM >To: "i-d-announce@ietf.org" >Cc: "sfc@ietf.org" >Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt > >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Service Function Chaining Working >>Group of the IETF. >> >> Title : Service Function Chaining Use Cases in Mobile >>Networks >> Authors : Walter Haeffner >> Jeffrey Napper >> Martin Stiemerling >> Diego R. Lopez >> Jim Uttaro >> Filename : draft-ietf-sfc-use-case-mobility-02.txt >> Pages : 20 >> Date : 2015-01-10 >> >>Abstract: >> This document provides some exemplary use cases for service function >> chaining in mobile service provider networks. The objective of this >> draft is not to cover all conceivable service chains in detail. >> Rather, the intention is to localize and explain the application >> domain of service chaining within mobile networks as far as it is >> required to complement the problem statement >> [ietf-sfc-problem-statement] and architecture framework >> [ietf-sfc-arch] of the working group. >> >> Service function chains typically reside in a LAN segment which links >> the mobile access network to the actual application platforms located >> in the carrier's datacenters or somewhere else in the Internet. >> Service function chains (SFC) ensure a fair distribution of network >> resources according to agreed service policies, enhance the >> performance of service delivery or take care of security and privacy. >> SFCs may also include Value Added Services (VAS). Commonly, SFCs are >> typical middlebox services. >> >> General considerations and specific use cases are presented in this >> document to demonstrate the different technical requirements of these >> goals for service function chaining in mobile service provider >> networks. >> >> The specification of service function chaining for mobile networks >> must take into account an interaction between service function chains >> and the 3GPP Policy and Charging Control (PCC) environment. >> >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-02 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-use-case-mobility-02 >> >> >>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/ >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jan 21 09:09:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F96C1A1B2F for ; Wed, 21 Jan 2015 09:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDH7LGqg3yDg for ; Wed, 21 Jan 2015 09:09:32 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF331A1AFA for ; Wed, 21 Jan 2015 09:09:31 -0800 (PST) Received: from [195.245.230.51] by server-7.bemta-3.messagelabs.com id BD/20-12541-A4DDFB45; Wed, 21 Jan 2015 17:09:30 +0000 X-Env-Sender: walter.haeffner@vodafone.com X-Msg-Ref: server-12.tower-33.messagelabs.com!1421860170!6519699!1 X-Originating-IP: [195.232.224.74] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19280 invoked from network); 21 Jan 2015 17:09:30 -0000 Received: from mailout05.vodafone.com (HELO mailout05.vodafone.com) (195.232.224.74) by server-12.tower-33.messagelabs.com with SMTP; 21 Jan 2015 17:09:30 -0000 Received: from mailint05.vodafone.com (localhost [127.0.0.1]) by mailout05.vodafone.com (Postfix) with ESMTP id DC79D200D0 for ; Wed, 21 Jan 2015 18:09:29 +0100 (CET) Received: from VOEXC01W.internal.vodafone.com (voexc01w.dc-ratingen.de [145.230.101.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint05.vodafone.com (Postfix) with ESMTPS id CEF45200CA; Wed, 21 Jan 2015 18:09:29 +0100 (CET) Received: from AVOEXC03W.internal.vodafone.com (145.230.15.132) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 21 Jan 2015 18:09:29 +0100 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.182]) by AVOEXC03W.internal.vodafone.com ([145.230.15.132]) with mapi id 14.03.0181.006; Wed, 21 Jan 2015 18:09:28 +0100 From: "Haeffner, Walter, Vodafone DE" To: Jeff Napper , "Dirk.von-Hugo@telekom.de" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt Thread-Index: AQHQLOiemNiTdXvFBkyfWJVW7vpVGZy8V0aAgAUKmACACSc1AIAAVyLJ Date: Wed, 21 Jan 2015 17:09:27 +0000 Message-ID: References: <20150110151735.24428.85673.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2F7390694C@HE113484.emea1.cds.t-internal.com>, In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C8C844F84E550E43865561FAE10471854C59D9A7VOEXM20Winterna_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 17:09:40 -0000 --_000_C8C844F84E550E43865561FAE10471854C59D9A7VOEXM20Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dirk, Many thanks for your careful reading and comments. Walter Gesendet mit meinem HTC ----- Reply message ----- Von: "Jeffrey Napper (jenapper)" An: "Dirk.von-Hugo@telekom.de" Cc: "sfc@ietf.org" Betreff: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt Datum: Mi., Jan 21, 2015 13:57 Thanks for the corrections, Dirk. I have added almost all of them to the next revision including the FMSS reference, which was a good catch. I edited the last one on p8 differently because there was simply an extraneous 'and' to be deleted. Cheers, Jeff -----Original Message----- From: "Dirk.von-Hugo@telekom.de" Date: Thursday, January 15, 2015 at 6:10 PM To: Jeffrey Napper Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt >Dear authors, >Thanks for the update of the mobility SFC use cases draft. IMO the >document is quite useful for further discussion on real-life >applicability of SFC work. > >Just some minor comments below (mainly nit and typo picking, >clarification proposals, and further smithing ...) >Sorry for that ;-) and thanks for all your work! > >Best regards >Dirk > >... >p.3 >HSS Home Subscriber System =3D> HSS Home Subscriber Server >GTP GPRS (General Packet Radio Service) Tunnel Protocol =3D> GTP GPRS >(General Packet Radio Service) Tunnelling Protocol > >p.4: >Important use cases classes =3D> Important use case classes > >p.5: > 4. functions like CG-NAT/PAT =3D> 4. functions like CG-NAT/NAPT (not >sure about PAT!?) >P-GW, a xDSL network =3D> P-GW, an xDSL network > >p.6: > basically only seen in mobile networks only. The same may be true > for video optimizers or HTTP header enrichment >=3D> basically seen in mobile networks only. The same may be true > for video optimizers or HTTP header enrichment entities > >p.7: > The major functional components of a LTE network =3D> The major >functional components of an LTE network > > Figure 2 shows the end to end context including all major components > of a LTE network. The actual 3GPP mobile network includes the > elements from the user equipment [UE] to the packet gateway [P-GW]. > > Figure 2: End to end context including all major components of a LTE > network. The actual 3GPP mobile network includes the elements from > the user equipment [UE] to the packet gateway [P-GW]. > >=3D> I propose to exchange the lower caption with the upper text and use >'_an_ LTE' (;-)) > >according 3GPP standards. =3D> according to 3GPP standards. > >p.8: > [TS.29.061], but service function chaining is not specified by 3GPP. >=3D> one may add: >A study on typical exemplary SFC use cases and potential requirements has >been performed by 3GPP recently [TR.22.808] in the framework of Rel. 13. >[TR.22.808] "Study on Flexible Mobile Service Steering (FMSS)", 3GPP T= R >22.808 V13.0.0, September 2014. > >to differentiate their services to their > subscribers and reflect the business model and of mobile operators. >=3D> to differentiate their services to their > subscribers and reflect the business model and to distinguish between >themselves and other mobile operators. (?) > >p.10: > devices address use Access Point Names (APNs) to address a service =3D> > devices use Access Point Names (APNs) to address a service > While a FQDN =3D> While an FQDN > >p.11: > UE: terminal type (e.g., HTC one), =3D> UE: terminal type (e.g., >phone capability, OS, vendor, ...), (?) <=3D [I suggest to omit real >product names here] >3GPP PCC (Policy > and Charging Architecture, [TS.23.203]) >=3D> 3GPP PCC (Policy > and Charging Control Architecture, [TS.23.203]) > >p.14: > Specifically, the Steering Proxy includes a TCP proxy and an ICAP > Client >=3D> Specifically, the Steering Proxy includes a TCP proxy and an ICAP >(Internet Content Adaptation Protocol) > Client [include reference?] > >p.18: > PCRF and the link would be a Gx or Diameter-based Sd interface. =3D> >PCRF and the link would be via a Gx or Diameter-based Sd reference point. >[correspondingly also on p.21] > >p.19: > individual VRF implementations etc. =3D> individual VRF (virtual >routing and forwarding) implementations etc. [reference to add?] > related metadata is extremely diffcult. =3D> related metadata >is extremely difficult. > >p.21: > methods in a service chain. Typically this data =3D> methods in a >service chain. Typically these data > plane. A mechanism where such metadata is carried =3D> plane. A >mechanism where such metadata are carried > >p.22: > o asynchronously from the control plain =3D> o asynchronously from >the control plane > o synchrounously, piggypacked with the user IP packet =3D> o >synchronously, piggypacked with the user IP packet > * or carried with http header enrichements =3D> * or carried >with http header enrichments > > > > -----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jeffrey Napper >(jenapper) >Sent: Montag, 12. Januar 2015 13:12 >To: internet-drafts@ietf.org; i-d-announce@ietf.org >Cc: sfc@ietf.org >Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt > >This draft is largely wordsmithing and typos. There are a couple of new >paragraphs that are available from the diff tool. > >Please send comments and suggestions to the list as we believe the >document is ready for last call. The document seems to be quite stable >now. > > >Cheers, >Jeff > > > >-----Original Message----- >From: "internet-drafts@ietf.org" >Date: Saturday, January 10, 2015 at 4:17 PM >To: "i-d-announce@ietf.org" >Cc: "sfc@ietf.org" >Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt > >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Service Function Chaining Working >>Group of the IETF. >> >> Title : Service Function Chaining Use Cases in Mobile >>Networks >> Authors : Walter Haeffner >> Jeffrey Napper >> Martin Stiemerling >> Diego R. Lopez >> Jim Uttaro >> Filename : draft-ietf-sfc-use-case-mobility-02.txt >> Pages : 20 >> Date : 2015-01-10 >> >>Abstract: >> This document provides some exemplary use cases for service function >> chaining in mobile service provider networks. The objective of this >> draft is not to cover all conceivable service chains in detail. >> Rather, the intention is to localize and explain the application >> domain of service chaining within mobile networks as far as it is >> required to complement the problem statement >> [ietf-sfc-problem-statement] and architecture framework >> [ietf-sfc-arch] of the working group. >> >> Service function chains typically reside in a LAN segment which links >> the mobile access network to the actual application platforms located >> in the carrier's datacenters or somewhere else in the Internet. >> Service function chains (SFC) ensure a fair distribution of network >> resources according to agreed service policies, enhance the >> performance of service delivery or take care of security and privacy. >> SFCs may also include Value Added Services (VAS). Commonly, SFCs are >> typical middlebox services. >> >> General considerations and specific use cases are presented in this >> document to demonstrate the different technical requirements of these >> goals for service function chaining in mobile service provider >> networks. >> >> The specification of service function chaining for mobile networks >> must take into account an interaction between service function chains >> and the 3GPP Policy and Charging Control (PCC) environment. >> >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-02 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-use-case-mobility-02 >> >> >>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/ >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_C8C844F84E550E43865561FAE10471854C59D9A7VOEXM20Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Dirk,
Many thanks for your careful reading and comments.
Walter

Gesendet mit meinem HTC

----- Reply message -----
Von: "Jeffrey Napper (jenapper)" <jenapper@cisco.com>
An: "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de> Cc: "sfc@ietf.org" <sfc@ietf.org>
Betreff: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt
Datum: Mi., Jan 21, 2015 13:57

Thanks for the corrections, Dirk. I have added alm= ost all of them to the
next revision including the FMSS reference, which was a good catch. I
edited the last one on p8 differently because there was simply an
extraneous 'and' to be deleted.

Cheers,
Jeff

-----Original Message-----
From: "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>=
Date: Thursday, January 15, 2015 at 6:10 PM
To: Jeffrey Napper <jenapper@cisco.com>
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt

>Dear authors,
>Thanks for the update of the mobility SFC use cases draft. IMO the
>document is quite useful for further discussion on real-life
>applicability of SFC work.
>
>Just some minor comments below (mainly nit and typo picking,
>clarification proposals, and further smithing ...)
>Sorry for that ;-) and thanks for all your work!
>
>Best regards
>Dirk
>
>...
>p.3
>HSS  Home Subscriber System =3D> HSS  Home Subscriber Serv= er
>GTP  GPRS (General Packet Radio Service) Tunnel Protocol =3D> G= TP  GPRS
>(General Packet Radio Service) Tunnelling Protocol
>
>p.4:
>Important use cases classes =3D> Important use case classes
>
>p.5:
>  4.  functions like CG-NAT/PAT  =3D>  4.  = functions like CG-NAT/NAPT (not
>sure about PAT!?)
>P-GW, a xDSL network =3D> P-GW, an xDSL network
>
>p.6:
>   basically only seen in mobile networks only.  The sam= e may be true
>   for video optimizers or HTTP header enrichment
>=3D>   basically seen in mobile networks only.  The s= ame may be true
>   for video optimizers or HTTP header enrichment entities >
>p.7:
>   The major functional components of a LTE network =3D>&n= bsp;  The major
>functional components of an LTE network
>
>   Figure 2 shows the end to end context including all major = components
>   of a LTE network.  The actual 3GPP mobile network inc= ludes the
>   elements from the user equipment [UE] to the packet gatewa= y [P-GW].
>
>   Figure 2: End to end context including all major component= s of a LTE
>    network.  The actual 3GPP mobile network includ= es the elements from
>           the user e= quipment [UE] to the packet gateway [P-GW].
>
>=3D> I propose to exchange the lower caption with the upper text and= use
>'_an_ LTE' (;-))
>
>according 3GPP standards.  =3D> according to 3GPP standards. >
>p.8:
>   [TS.29.061], but service function chaining is not specifie= d by 3GPP.
>=3D>   one may add:
>A study on typical exemplary SFC use cases and potential requirements h= as
>been performed by 3GPP recently [TR.22.808] in the framework of Rel. 13= .
>[TR.22.808]     "Study on Flexible Mobile Serv= ice Steering (FMSS)", 3GPP TR
>22.808 V13.0.0, September 2014.
>
>to differentiate their services to their
>   subscribers and reflect the business model and of mobile o= perators.
>=3D> to differentiate their services to their
>   subscribers and reflect the business model and to distingu= ish between
>themselves and other mobile operators. (?)
>
>p.10:
>   devices address use Access Point Names (APNs) to address a= service =3D>
>  devices use Access Point Names (APNs) to address a service
>  While a FQDN =3D>   While an FQDN
>
>p.11:
>   UE:  terminal type (e.g., HTC one), =3D> &nbs= p;  UE:  terminal type (e.g.,
>phone capability, OS, vendor, ...), (?) <=3D [I suggest to omit real=
>product names here]
>3GPP PCC (Policy
>   and Charging Architecture, [TS.23.203])
>=3D> 3GPP PCC (Policy
>   and Charging Control Architecture, [TS.23.203])
>
>p.14:
>   Specifically, the Steering Proxy includes a TCP proxy and = an ICAP
>   Client
>=3D>    Specifically, the Steering Proxy includes a T= CP proxy and an ICAP
>(Internet Content Adaptation Protocol)
>   Client [include reference?]
>
>p.18:
>   PCRF and the link would be a Gx or Diameter-based Sd inter= face. =3D>
>PCRF and the link would be via a Gx or Diameter-based Sd reference poin= t.
>[correspondingly also on p.21]
>
>p.19:
>   individual VRF implementations etc. =3D>  &nb= sp; individual VRF (virtual
>routing and forwarding) implementations etc. [reference to add?]
>      related metadata is extremely diffcult. = =3D>       related metadata
>is extremely difficult.
>
>p.21:
>   methods in a service chain.  Typically this data =3D&= gt;    methods in a
>service chain.  Typically these data
>   plane.  A mechanism where such metadata is carried = =3D>    plane.  A
>mechanism where such metadata are carried
>
>p.22:
>   o  asynchronously from the control plain  =3D>= ;   o  asynchronously from
>the control plane
>   o  synchrounously, piggypacked with the user IP packe= t =3D>   o
>synchronously, piggypacked with the user IP packet
>      *  or carried with http header enri= chements =3D>       *  or carried
>with http header enrichments
>
>
>
> -----Original Message-----
>From: sfc [mailto:sfc-bounces@i= etf.org] On Behalf Of Jeffrey Napper
>(jenapper)
>Sent: Montag, 12. Januar 2015 13:12
>To: internet-drafts@ietf.org; i-d-announce@ietf.org
>Cc: sfc@ietf.org
>Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt<= br> >
>This draft is largely wordsmithing and typos. There are a couple of new=
>paragraphs that are available from the diff tool.
>
>Please send comments and suggestions to the list as we believe the
>document is ready for last call. The document seems to be quite stable<= br> >now.
>
>
>Cheers,
>Jeff
>
>
>
>-----Original Message-----
>From: "internet-drafts@ietf.org" <internet-drafts@ietf.org= >
>Date: Saturday, January 10, 2015 at 4:17 PM
>To: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
>Cc: "sfc@ietf.org" <sfc@ietf.org>
>Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-02.txt
>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts<= br> >>directories.
>> This draft is a work item of the Service Function Chaining Working=
>>Group of the IETF.
>>
>>        Title   &= nbsp;       : Service Function Chaining Use C= ases in Mobile
>>Networks
>>        Authors   = ;      : Walter Haeffner
>>           &= nbsp;           &nbs= p;  Jeffrey Napper
>>           &= nbsp;           &nbs= p;  Martin Stiemerling
>>           &= nbsp;           &nbs= p;  Diego R. Lopez
>>           &= nbsp;           &nbs= p;  Jim Uttaro
>>      Filename    &nbs= p;   : draft-ietf-sfc-use-case-mobility-02.txt
>>      Pages     &= nbsp;     : 20
>>      Date     &n= bsp;      : 2015-01-10
>>
>>Abstract:
>>   This document provides some exemplary use cases for se= rvice function
>>   chaining in mobile service provider networks.  Th= e objective of this
>>   draft is not to cover all conceivable service chains i= n detail.
>>   Rather, the intention is to localize and explain the a= pplication
>>   domain of service chaining within mobile networks as f= ar as it is
>>   required to complement the problem statement
>>   [ietf-sfc-problem-statement] and architecture framewor= k
>>   [ietf-sfc-arch] of the working group.
>>
>>   Service function chains typically reside in a LAN segm= ent which links
>>   the mobile access network to the actual application pl= atforms located
>>   in the carrier's datacenters or somewhere else in the = Internet.
>>   Service function chains (SFC) ensure a fair distributi= on of network
>>   resources according to agreed service policies, enhanc= e the
>>   performance of service delivery or take care of securi= ty and privacy.
>>   SFCs may also include Value Added Services (VAS). = ; Commonly, SFCs are
>>   typical middlebox services.
>>
>>   General considerations and specific use cases are pres= ented in this
>>   document to demonstrate the different technical requir= ements of these
>>   goals for service function chaining in mobile service = provider
>>   networks.
>>
>>   The specification of service function chaining for mob= ile networks
>>   must take into account an interaction between service = function chains
>>   and the 3GPP Policy and Charging Control (PCC) environ= ment.
>>
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobili= ty/
>>
>>There's also a htmlized version available at:
>>http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-02<= br> >>
>>A diff from the previous version is available at:
>>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-use-case-= mobility-02
>>
>>
>>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/
>>
>>_______________________________________________
>>sfc mailing list
>>sfc@ietf.org
>>https://www.i= etf.org/mailman/listinfo/sfc
>
>_______________________________________________
>sfc mailing list
>sfc@ietf.org
>https://www.ietf.= org/mailman/listinfo/sfc
>
>_______________________________________________
>sfc mailing list
>sfc@ietf.org
>https://www.ietf.= org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc
 --_000_C8C844F84E550E43865561FAE10471854C59D9A7VOEXM20Winterna_-- From nobody Wed Jan 21 21:05:53 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C27E1A916F; Wed, 21 Jan 2015 21:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbTPseGn-fUJ; Wed, 21 Jan 2015 21:05:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA75E1A916E; Wed, 21 Jan 2015 21:05:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122050544.1915.6657.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 21:05:44 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-long-lived-flow-use-cases-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 05:05:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : SFC Long-lived Flow Use Cases Authors : Ram Krishnan Anoop Ghanwani Joel Halpern Sriganesh Kini Diego Lopez Filename : draft-ietf-sfc-long-lived-flow-use-cases-02.txt Pages : 10 Date : 2015-01-21 Abstract: Long-lived flows such as file transfers, video streams are common in today's networks. In the context of service function chaining, this draft suggests use cases for dynamic bypass of certain service functions for such flows. The benefit of this approach would be to avoid expensive Layer 7 service function processing for such flows based on dynamic decisions and thus improve overall performance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-long-lived-flow-use-cases-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-long-lived-flow-use-cases-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 21 21:09:06 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7561A9177 for ; Wed, 21 Jan 2015 21:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzxu4jojXmBu for ; Wed, 21 Jan 2015 21:09:02 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B3A1A9175 for ; Wed, 21 Jan 2015 21:09:02 -0800 (PST) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t0M4WBBX030023; Wed, 21 Jan 2015 21:08:58 -0800 Received: from brmwp-exchub01.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 1s2ddkhr0m-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 Jan 2015 21:08:58 -0800 Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 21 Jan 2015 22:08:57 -0700 Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 21 Jan 2015 22:08:57 -0700 Received: from BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9]) by BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9%23]) with mapi id 15.00.1044.021; Wed, 21 Jan 2015 22:08:56 -0700 From: Ramki Krishnan To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQ Date: Thu, 22 Jan 2015 05:08:55 +0000 Message-ID: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.180.50] Content-Type: multipart/alternative; boundary="_000_6db19ce9c26c435d86de16352557c7b2BRMWPEXMB11corpbrocadec_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-22_02:2015-01-22,2015-01-22,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-1402240000 definitions=main-1501220051 Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 05:09:04 -0000 --_000_6db19ce9c26c435d86de16352557c7b2BRMWPEXMB11corpbrocadec_ Content-Type: text/plain; charset="us-ascii" Many thanks for the comments so far; please find an updated version of the draft addressing them. http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/ Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Monday, December 15, 2014 7:15 AM To: sfc@ietf.org Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Dear WG: This note begins a 2-week WG LC on draft-ietf-sfc-long-lived-flow-use-cases.01.txt. The document authors have indicated that they have addressed all known comments and that there are no open issues with the current version of the document. Substantive comments to the list please, editorial comments can go directly to the document editors. Jim & Thomas --_000_6db19ce9c26c435d86de16352557c7b2BRMWPEXMB11corpbrocadec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Many thanks for the comments so far; = please find an updated version of the draft addressing them.

 

http://datatracker.ietf.or= g/doc/draft-ietf-sfc-long-lived-flow-use-cases/

 

Thanks,

Ramki

 

From: sfc [mailto:sfc-bounces@ietf.o= rg] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, December 15, 2014 7:15 AM
To: sfc@ietf.org
Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01=

 

Dear WG:

 

This note begins a 2-week WG LC on draf= t-ietf-sfc-long-lived-flow-use-cases.01.txt.

 

The document authors have indicated tha= t they have addressed all known comments and that there are no open issues = with the current version of the document. 

 

Substantive comments to the list please= , editorial comments can go directly to the document editors.

 

Jim & Thomas

--_000_6db19ce9c26c435d86de16352557c7b2BRMWPEXMB11corpbrocadec_-- From nobody Thu Jan 22 18:17:35 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E511A00CD; Thu, 22 Jan 2015 18:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ1l1QiWP-yH; Thu, 22 Jan 2015 18:17:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8903F1A00BE; Thu, 22 Jan 2015 18:17:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOI36055; Fri, 23 Jan 2015 02:17:27 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 02:17:26 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 23 Jan 2015 10:17:20 +0800 From: Xuxiaohu To: "sfc@ietf.org" , "mpls@ietf.org" Thread-Topic: How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSeg== Date: Fri, 23 Jan 2015 02:17:20 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [sfc] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 02:17:30 -0000 Hi all, It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04): The service header is independent of the encapsulation used and is encapsulated in existing transports. The presence of NSH is indicated via protocol type or other indicator in the outer encapsulation. In the case where the outer encapsulation is an MPLS LSP, how to indicate t= he presence of NSH since the MPLS encapsulation has no explicit protocol id= entifier field to indicate the protocol type of the MPLS payload? Should we= make each SFF to allocate a unique label for indicating the presence of NS= H? Or should we use the control word to indicate it? Or should we reconside= r the possibility of adding an explicit protocol identifier field to the MP= LS encapsulation so as to solve such kind of issues once and for all? Best regards, Xiaohu From nobody Thu Jan 22 20:27:21 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD441A016B for ; Thu, 22 Jan 2015 20:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M70q2OSFhrJS for ; Thu, 22 Jan 2015 20:27:17 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16001A0169 for ; Thu, 22 Jan 2015 20:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14158; q=dns/txt; s=iport; t=1421987236; x=1423196836; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=iv1r7nyqj4ClASWtdENYcYFUZ2RbgnLhXxgw+fh1kJ8=; b=Bv1+ymUI+9oMzxes07Limhr3hLriBWZqKVx9z7FI8uRS5APdXzsExSq6 00o3qmICD/CCCF0UgOup7t/qqhGMLKnCObyIvK9NEKELBNliqfdBda8if HMXGv5bg6YuYj/3cAVZ3u9ZzvvtJ8OeLQAKer6IoR6rCAPNQvT5pSUqpw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4IAOvMwVStJA2F/2dsb2JhbABagkNDUlgEtxuNAjyBa4VvAoEWQwEBAQEBfYQMAQEBBC1cAgEIDgMEAQELHQcyFAkIAgQBCQkIiCQN0kgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0c3AYMWgRMFjQaBYINKhmM2gkiOIyKDbm+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.09,453,1418083200"; d="scan'208,217";a="116816945" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 23 Jan 2015 04:27:15 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t0N4RFKY025446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 04:27:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 22:27:15 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Ramki Krishnan , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQgAFlkJA= Date: Fri, 23 Jan 2015 04:27:14 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> In-Reply-To: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.67.151] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3552F98Bxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 04:27:20 -0000 --_000_913383AAA69FF945B8F946018B75898A3552F98Bxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ramki, Comments: 1. A transparent firewall may be able to determine that a long-lived flow (e.g. video stream, file transfer) has no security issues. Comment> In the above line you may want to consider removing "file transfe= r", FW to inspect files has to act as a L7 proxy and it is not possible to = remove itself from the path after the file transfer is initiated. 2. a. The packets which are encrypted at the application layer using protocols such as HTTPS [RFC 2660] cannot be decrypted and examined further. Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used for f= ile transfer and Firewall acts as HTTPS proxy then it cannot by-pass the fl= ow. HTTP/2.0 mandates TLS. 3. b. The packets are from a trusted source. c. The packets are from a trusted application. Comment> If firewall is white-listing based on destination IP address then = the by-pass decision can be made on the SYN packet itself. 4. A monitoring element such as a DPI appliance analyzes the new flows arriving at the default SecGW device used by a given eNodeB device according to criteria such as: Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS proxy and= will result in privacy problems. It may also conflict with the work in oth= er WG like tcpinc with proposals to automatically use TLS without modifying= the application layer protocol. -Tiru From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ramki Krishnan Sent: Thursday, January 22, 2015 10:39 AM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Many thanks for the comments so far; please find an updated version of the = draft addressing them. http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/ Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, December 15, 2014 7:15 AM To: sfc@ietf.org Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Dear WG: This note begins a 2-week WG LC on draft-ietf-sfc-long-lived-flow-use-cases= .01.txt. The document authors have indicated that they have addressed all known comm= ents and that there are no open issues with the current version of the docu= ment. Substantive comments to the list please, editorial comments can go directly= to the document editors. Jim & Thomas --_000_913383AAA69FF945B8F946018B75898A3552F98Bxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ramki,

 

Comments:

 

1.

 

   A transparent firewall may be able t= o determine that a long-lived

   flow (e.g. video stream, file transf= er) has no security issues.

 

Comment>  In the above line you may want = to consider removing “file transfer”, FW to inspect files has t= o act as a L7 proxy and it is not possible to remove itself from the path a= fter the file transfer is initiated.

 

2.

 

        a.&nbs= p; The packets which are encrypted at the application layer

        &= nbsp; using protocols such as HTTPS [RFC 2660] cannot be decrypted

        &= nbsp; and examined further.

 

Comment> Enterprise Firewalls do act as HTTPS = proxy. If HTTPS is used for file transfer and Firewall acts as HTTPS proxy = then it cannot by-pass the flow. HTTP/2.0 mandates TLS.

 

3.

 

        b.&nbs= p; The packets are from a trusted source.

 

        c.&nbs= p; The packets are from a trusted application.

 

Comment> If firewall is white-listing based on= destination IP address then the by-pass decision can be made on the SYN pa= cket itself.

 

4. 

     A monitoring elemen= t such as a DPI appliance analyzes the new

     flows arriving at the de= fault SecGW device used by a given eNodeB

     device according to crit= eria such as:

 

Comment> DPI with HTTP/2.0 will require the IS= P to deploy a HTTPS proxy and will result in privacy problems. It may also = conflict with the work in other WG like tcpinc with proposals to automatica= lly use TLS without modifying the application layer protocol.

 <= /p>

-Tiru

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Ramki Krishnan
Sent: Thursday, January 22, 2015 10:39 AM
To: Jim Guichard (jguichar); sfc@ietf.org
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-case= s-01

 

Many thanks for the comme= nts so far; please find an updated version of the draft addressing them.

 <= /p>

http://datatra= cker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/<= /span>

 <= /p>

Thanks,=

Ramki

 <= /p>

From: sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, December 15, 2014 7:15 AM
To: sfc@ietf.org
Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01=

 

Dear WG:<= /p>

 

This note begins a 2-week W= G LC on draft-ietf-sfc-long-lived-flow-use-cases.01.txt.<= /p>

 

The document authors have i= ndicated that they have addressed all known comments and that there are no = open issues with the current version of the document. 

 

Substantive comments to the= list please, editorial comments can go directly to the document editors.

 

Jim & Thomas=

--_000_913383AAA69FF945B8F946018B75898A3552F98Bxmbrcdx10ciscoc_-- From nobody Thu Jan 22 21:10:58 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9FC1A01C6 for ; Thu, 22 Jan 2015 21:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk_c8ekDxxg2 for ; Thu, 22 Jan 2015 21:10:47 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FE61A01EC for ; Thu, 22 Jan 2015 21:10:47 -0800 (PST) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t0N57mDr029731; Thu, 22 Jan 2015 21:10:45 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1s37t28x0r-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Jan 2015 21:10:45 -0800 Received: from BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 22 Jan 2015 21:10:44 -0800 Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 22 Jan 2015 22:10:43 -0700 Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 22 Jan 2015 22:10:43 -0700 Received: from BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9]) by BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9%23]) with mapi id 15.00.1044.021; Thu, 22 Jan 2015 22:10:42 -0700 From: Ramki Krishnan To: "Tirumaleswar Reddy (tireddy)" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQgAFlkJCAACcfAA== Date: Fri, 23 Jan 2015 05:10:42 +0000 Message-ID: References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.181.50] Content-Type: multipart/alternative; boundary="_000_b3115d7f6f4548c9bb5cd07929162869BRMWPEXMB11corpbrocadec_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-23_02:2015-01-23,2015-01-23,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-1402240000 definitions=main-1501230050 Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 05:10:56 -0000 --_000_b3115d7f6f4548c9bb5cd07929162869BRMWPEXMB11corpbrocadec_ Content-Type: text/plain; charset="us-ascii" Hi Tiru, Thanks, please find inline. Thanks, Ramki From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Thursday, January 22, 2015 8:27 PM To: Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Hi Ramki, Comments: 1. A transparent firewall may be able to determine that a long-lived flow (e.g. video stream, file transfer) has no security issues. Comment> In the above line you may want to consider removing "file transfer", FW to inspect files has to act as a L7 proxy and it is not possible to remove itself from the path after the file transfer is initiated. Ramki: Firewalls do not examine every byte of content. Examining every byte of content is performed by virus scanner, content scanner etc. 2. a. The packets which are encrypted at the application layer using protocols such as HTTPS [RFC 2660] cannot be decrypted and examined further. Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used for file transfer and Firewall acts as HTTPS proxy then it cannot by-pass the flow. HTTP/2.0 mandates TLS. Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in the event sequence, SFC manipulation happens at the Layer 2/3/4 level. 3. b. The packets are from a trusted source. c. The packets are from a trusted application. Comment> If firewall is white-listing based on destination IP address then the by-pass decision can be made on the SYN packet itself. Ramki: Agree that this is a good criterion. As we described in the draft, the list of criteria is not exhaustive - it is hard to include every possible case. 4. A monitoring element such as a DPI appliance analyzes the new flows arriving at the default SecGW device used by a given eNodeB device according to criteria such as: Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS proxy and will result in privacy problems. It may also conflict with the work in other WG like tcpinc with proposals to automatically use TLS without modifying the application layer protocol. Ramki: HTTP/2.0 does not mandate encryption -- http://http2.github.io/faq/#does-http2-require-encryption. We are addressing only the non-encrypted case. -Tiru From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ramki Krishnan Sent: Thursday, January 22, 2015 10:39 AM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Many thanks for the comments so far; please find an updated version of the draft addressing them. http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/ Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Monday, December 15, 2014 7:15 AM To: sfc@ietf.org Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Dear WG: This note begins a 2-week WG LC on draft-ietf-sfc-long-lived-flow-use-cases.01.txt. The document authors have indicated that they have addressed all known comments and that there are no open issues with the current version of the document. Substantive comments to the list please, editorial comments can go directly to the document editors. Jim & Thomas --_000_b3115d7f6f4548c9bb5cd07929162869BRMWPEXMB11corpbrocadec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Thanks, please find inline.

 

Thanks,

Ramki

 

From: Tirumaleswar Reddy (tireddy) [= mailto:tireddy@cisco.com]
Sent: Thursday, January 22, 2015 8:27 PM
To: Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

 

Hi Ramki,

 

Comments:

 

1.

 

   A transparent firewall may be able t= o determine that a long-lived

   flow (e.g. video stream, file transf= er) has no security issues.

 

Comment>  In the above line you may want = to consider removing “file transfer”, FW to inspect files has t= o act as a L7 proxy and it is not possible to remove itself from the path a= fter the file transfer is initiated.

 

Ramki: Firewalls do= not examine every byte of content. Examining every byte of content is perf= ormed by virus scanner, content scanner etc.

 

2.

 

        a.&nbs= p; The packets which are encrypted at the application layer

        &= nbsp; using protocols such as HTTPS [RFC 2660] cannot be decrypted

        &= nbsp; and examined further.

 

Comment> Enterprise Firewalls do act as HTTPS = proxy. If HTTPS is used for file transfer and Firewall acts as HTTPS proxy = then it cannot by-pass the flow. HTTP/2.0 mandates TLS.

 

Ramki: HTTPS does n= ot encrypt Layer 2/3/4 headers. As described in the event sequence, SFC man= ipulation happens at the Layer 2/3/4 level.

 

3.

 

        b.&nbs= p; The packets are from a trusted source.

 

        c.&nbs= p; The packets are from a trusted application.

 

Comment> If firewall is white-listing based on= destination IP address then the by-pass decision can be made on the SYN pa= cket itself.

 

Ramki: Agree that t= his is a good criterion. As we described in the draft, the list of criteria= is not exhaustive – it is hard to include every possible case.<= /o:p>

 

4. 

     A monitoring elemen= t such as a DPI appliance analyzes the new

     flows arriving at the de= fault SecGW device used by a given eNodeB

     device according to crit= eria such as:

 

Comment> DPI with HTTP/2.0 will require the IS= P to deploy a HTTPS proxy and will result in privacy problems. It may also = conflict with the work in other WG like tcpinc with proposals to automatica= lly use TLS without modifying the application layer protocol.

 

Ramki: HTTP/2.0 doe= s not mandate encryption -- http:= //http2.github.io/faq/#does-http2-require-encryption. We are addressing= only the non-encrypted case.

 

-Tiru

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ramki Krishnan
Sent: Thursday, January 22, 2015 10:39 AM
To: Jim Guichard (jguichar); sfc@iet= f.org
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-case= s-01

 

Many thanks for the comments so far; = please find an updated version of the draft addressing them.

 

http://datatracker.ietf.or= g/doc/draft-ietf-sfc-long-lived-flow-use-cases/

 

Thanks,

Ramki

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, December 15, 2014 7:15 AM
To: sfc@ietf.org
Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01=

 

Dear WG:

 

This note begins a 2-week WG LC on draf= t-ietf-sfc-long-lived-flow-use-cases.01.txt.

 

The document authors have indicated tha= t they have addressed all known comments and that there are no open issues = with the current version of the document. 

 

Substantive comments to the list please= , editorial comments can go directly to the document editors.

 

Jim & Thomas

--_000_b3115d7f6f4548c9bb5cd07929162869BRMWPEXMB11corpbrocadec_-- From nobody Thu Jan 22 22:02:02 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24FA1A01D6 for ; Thu, 22 Jan 2015 22:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRWATsStulGv for ; Thu, 22 Jan 2015 22:01:56 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC601A0167 for ; Thu, 22 Jan 2015 22:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22026; q=dns/txt; s=iport; t=1421992917; x=1423202517; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=LAs6ZT6ewYLALcdIyp8WXhQjy+tszWb5Oa1oVx2tUBw=; b=Lpwax4+ArcJ731juM/3wIbycy1fXCV1Nb1gxbBp9UTT84LSS2fG7z08A nGYLcrXVTIA7x5ufrbLR9s91qcyZwzslmt11+4YgxKBXvdLb5jcqkEMq6 zoaqtBsZ3lJ0nQdIKejm/J4VWZIHjdVZui8uCzQeoUlhHe5SP/ejvsefG k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4IAHniwVStJV2a/2dsb2JhbABagkNDUlgEtx2NAjyBa4VvAoESQwEBAQEBfYQMAQEBBC1cAgEIDgMEAQELFgcHMhQJCAIEAQkJCIgkDdJbAQEBAQEBAQEBAQEBAQEBAQEBAQEBF49HNwGDFoETBY0GgWCDSoZjNoJIjiMig25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.09,453,1418083200"; d="scan'208,217";a="390216996" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 23 Jan 2015 06:01:55 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0N61sTd020905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 06:01:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 00:01:54 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Ramki Krishnan , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQgAFlkJCAACcfAIAADCYw Date: Fri, 23 Jan 2015 06:01:53 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.67.151] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3552FA60xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 06:02:00 -0000 --_000_913383AAA69FF945B8F946018B75898A3552FA60xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline [TR] From: Ramki Krishnan [mailto:ramk@Brocade.com] Sent: Friday, January 23, 2015 10:41 AM To: Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); sfc@ietf.org Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Hi Tiru, Thanks, please find inline. Thanks, Ramki From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Thursday, January 22, 2015 8:27 PM To: Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Hi Ramki, Comments: 1. A transparent firewall may be able to determine that a long-lived flow (e.g. video stream, file transfer) has no security issues. Comment> In the above line you may want to consider removing "file transfe= r", FW to inspect files has to act as a L7 proxy and it is not possible to = remove itself from the path after the file transfer is initiated. Ramki: Firewalls do not examine every byte of content. Examining every byte= of content is performed by virus scanner, content scanner etc. [TR] Firewalls do have the capability to inspect files to block viruses, ma= lware etc.. FW acts as a proxy, fetches the complete file from the server a= nd scans the file. 2. a. The packets which are encrypted at the application layer using protocols such as HTTPS [RFC 2660] cannot be decrypted and examined further. Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used for f= ile transfer and Firewall acts as HTTPS proxy then it cannot by-pass the fl= ow. HTTP/2.0 mandates TLS. Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in the even= t sequence, SFC manipulation happens at the Layer 2/3/4 level. [TR] I may have missed, but did not see any mention in the draft that the s= ervice functions do not modify L7 and only manipulate 2/3/4 level. If will = be good to explicitly mention that to avoid confusion and also discuss the = implication of L4 manipulations with TCP authentication in Security conside= rations section. 3. b. The packets are from a trusted source. c. The packets are from a trusted application. Comment> If firewall is white-listing based on destination IP address then = the by-pass decision can be made on the SYN packet itself. Ramki: Agree that this is a good criterion. As we described in the draft, t= he list of criteria is not exhaustive - it is hard to include every possibl= e case. [TR] Okay. 4. A monitoring element such as a DPI appliance analyzes the new flows arriving at the default SecGW device used by a given eNodeB device according to criteria such as: Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS proxy and= will result in privacy problems. It may also conflict with the work in oth= er WG like tcpinc with proposals to automatically use TLS without modifying= the application layer protocol. Ramki: HTTP/2.0 does not mandate encryption -- http://http2.github.io/faq/#= does-http2-require-encryption. We are addressing only the non-encrypted cas= e. [TR] It may be good to explicitly mention that the use cases deal with only= plain text traffic. -Tiru From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ramki Krishnan Sent: Thursday, January 22, 2015 10:39 AM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Many thanks for the comments so far; please find an updated version of the = draft addressing them. http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/ Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, December 15, 2014 7:15 AM To: sfc@ietf.org Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Dear WG: This note begins a 2-week WG LC on draft-ietf-sfc-long-lived-flow-use-cases= .01.txt. The document authors have indicated that they have addressed all known comm= ents and that there are no open issues with the current version of the docu= ment. Substantive comments to the list please, editorial comments can go directly= to the document editors. Jim & Thomas --_000_913383AAA69FF945B8F946018B75898A3552FA60xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Inline [TR]

 <= /p>

From: Ramki Kr= ishnan [mailto:ramk@Brocade.com]
Sent: Friday, January 23, 2015 10:41 AM
To: Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); sfc@ietf.= org
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

 

Hi Tiru,

 <= /p>

Thanks, please find inlin= e.

 <= /p>

Thanks,=

Ramki

 <= /p>

From: Tiruma= leswar Reddy (tireddy) [mailto:tireddy= @cisco.com]
Sent: Thursday, January 22, 2015 8:27 PM
To: Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

 

Hi Ramki,

 

Comments:

 

1.

 

   A transparent firewall may be able t= o determine that a long-lived

   flow (e.g. video stream, file transf= er) has no security issues.

 

Comment>  In the above line you may want = to consider removing “file transfer”, FW to inspect files has t= o act as a L7 proxy and it is not possible to remove itself from the path a= fter the file transfer is initiated.

 

Ramki: Firewalls do= not examine every byte of content. Examining every byte of content is perf= ormed by virus scanner, content scanner etc.

 

[TR] Firewalls do h= ave the capability to inspect files to block viruses, malware etc.. FW acts= as a proxy, fetches the complete file from the server and scans the file.<= o:p>

 

2.

 

        a.&nbs= p; The packets which are encrypted at the application layer

        &= nbsp; using protocols such as HTTPS [RFC 2660] cannot be decrypted

        &= nbsp; and examined further.

 

Comment> Enterprise Firewalls do act as HTTPS = proxy. If HTTPS is used for file transfer and Firewall acts as HTTPS proxy = then it cannot by-pass the flow. HTTP/2.0 mandates TLS.

 

Ramki: HTTPS does n= ot encrypt Layer 2/3/4 headers. As described in the event sequence, SFC man= ipulation happens at the Layer 2/3/4 level.

 

[TR] I may have mis= sed, but did not see any mention in the draft that the service functions do= not modify L7 and only manipulate 2/3/4 level. If will be good to explic= itly mention that to avoid confusion and also discuss the implication of L4= manipulations with TCP authentication in Security considerations section.<= /span>

 

3.

 

        b.&nbs= p; The packets are from a trusted source.

 

        c.&nbs= p; The packets are from a trusted application.

 

Comment> If firewall is white-listing based on= destination IP address then the by-pass decision can be made on the SYN pa= cket itself.

 

Ramki: Agree that t= his is a good criterion. As we described in the draft, the list of criteria= is not exhaustive – it is hard to include every possible case.<= /o:p>

 

[TR] Okay.

 

4. 

     A monitoring elemen= t such as a DPI appliance analyzes the new

     flows arriving at the de= fault SecGW device used by a given eNodeB

     device according to crit= eria such as:

 

Comment> DPI with HTTP/2.0 will require the IS= P to deploy a HTTPS proxy and will result in privacy problems. It may also = conflict with the work in other WG like tcpinc with proposals to automatica= lly use TLS without modifying the application layer protocol.

 

Ramki: HTTP/2.0 doe= s not mandate encryption -- http:= //http2.github.io/faq/#does-http2-require-encryption. We are addressing= only the non-encrypted case.

 

[TR] It may be good= to explicitly mention that the use cases deal with only plain text traffic= .

 

-Tiru

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ramki Krishnan
Sent: Thursday, January 22, 2015 10:39 AM
To: Jim Guichard (jguichar); sfc@iet= f.org
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-case= s-01

 

Many thanks for the comme= nts so far; please find an updated version of the draft addressing them.

 <= /p>

http://datatra= cker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/<= /span>

 <= /p>

Thanks,=

Ramki

 <= /p>

From: sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, December 15, 2014 7:15 AM
To: sfc@ietf.org
Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01=

 

Dear WG:<= /p>

 

This note begins a 2-week W= G LC on draft-ietf-sfc-long-lived-flow-use-cases.01.txt.<= /p>

 

The document authors have i= ndicated that they have addressed all known comments and that there are no = open issues with the current version of the document. 

 

Substantive comments to the= list please, editorial comments can go directly to the document editors.

 

Jim & Thomas=

--_000_913383AAA69FF945B8F946018B75898A3552FA60xmbrcdx10ciscoc_-- From nobody Fri Jan 23 01:29:33 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDFC1A1A91 for ; Fri, 23 Jan 2015 01:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.597 X-Spam-Level: ** X-Spam-Status: No, score=2.597 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf3mp_7wusD4 for ; Fri, 23 Jan 2015 01:29:29 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0681A01D8 for ; Fri, 23 Jan 2015 01:29:28 -0800 (PST) Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t0N9TSlU031042 for ; Fri, 23 Jan 2015 18:29:28 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 4DE335F594 for ; Fri, 23 Jan 2015 18:29:28 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 375D55F593 for ; Fri, 23 Jan 2015 18:29:28 +0900 (JST) Received: from [127.0.0.1] ([129.60.20.75]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t0N9TP0v009713 for ; Fri, 23 Jan 2015 18:29:28 +0900 Message-ID: <54C21423.1080309@lab.ntt.co.jp> Date: Fri, 23 Jan 2015 18:28:03 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "sfc@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable Archived-At: Subject: [sfc] SFC Requirement draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 09:29:31 -0000 Hi all, Draft-boucadair-sfc-requirements-05 has been expired, but I would like to ask WG again, that do we really should leave this expired or not. http://www.ietf.org/archive/id/draft-boucadair-sfc-requirements-05.txt I believe the documentation of requirements is helpful to keep useful discussion about sfc, as we can refer at anytime "what we really require". Please send any opinion to the mailing list. Best regards, Kengo -- ---------------------------------------- NTT Network Technology Laboratories Kengo Naito E-Mail:naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- From nobody Fri Jan 23 03:14:16 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE3B1A9094 for ; Fri, 23 Jan 2015 03:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf0D3vVLvFCE for ; Fri, 23 Jan 2015 03:14:08 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 30DC91A9093 for ; Fri, 23 Jan 2015 03:14:08 -0800 (PST) Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t0NBE6Yf001184 for ; Fri, 23 Jan 2015 20:14:07 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id CEF9F5F594 for ; Fri, 23 Jan 2015 20:14:06 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id C20AB5F593 for ; Fri, 23 Jan 2015 20:14:06 +0900 (JST) Received: from [IPv6:::1] ([129.60.13.28]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t0NBE08h019306 for ; Fri, 23 Jan 2015 20:14:06 +0900 Message-ID: <54C22D39.8080604@lab.ntt.co.jp> Date: Fri, 23 Jan 2015 20:15:05 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 References: <20150123103128.1280.74366.idtracker@ietfa.amsl.com> In-Reply-To: <20150123103128.1280.74366.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150123103128.1280.74366.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: sfc@ietf.org X-TM-AS-MML: disable Archived-At: Subject: [sfc] Fwd: New Version Notification for draft-homma-sfc-forwarding-methods-analysis-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 11:14:12 -0000 Hi all, We have updated the draft which describes analysis on forwarding methods for service chaining. In this revision, two members had participated as coauthors, and we have added analysis of "Hierarchical Service Path Domain" as a new topic. If you have any opinions or comments, please let us know. We will welcome any other point of view about the analysis. Best regards, Shunsuke -------- Forwarded Message -------- Subject: New Version Notification for draft-homma-sfc-forwarding-methods-analysis-01.txt Date: Fri, 23 Jan 2015 02:31:28 -0800 From: internet-drafts@ietf.org To: Kengo , Shunsuke Homma , Diego R. Lopez , David Dolson , Diego Lopez , Kengo Naito , David Dolson , Shunsuke Homma A new version of I-D, draft-homma-sfc-forwarding-methods-analysis-01.txt has been successfully submitted by Shunsuke Homma and posted to the IETF repository. Name: draft-homma-sfc-forwarding-methods-analysis Revision: 01 Title: Analysis on Forwarding Methods for Service Chaining Document date: 2015-01-23 Group: Individual Submission Pages: 28 URL: http://www.ietf.org/internet-drafts/draft-homma-sfc-forwarding-methods-analysis-01.txt Status: https://datatracker.ietf.org/doc/draft-homma-sfc-forwarding-methods-analysis/ Htmlized: http://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analysis-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-homma-sfc-forwarding-methods-analysis-01 Abstract: Some working groups of the IETF and other Standards Developing Organizations are now discussing use cases of a technology that enables data packets to traverse appropriate service functions located remotely through networks. This is called Service Chaining in this document. (Also, in Network Functions Virtualisation (NFV), a subject that forwarding packets to required service functions in appropriate order is called VNF Forwarding Graph.) This draft does not focus only on SFC method, and thus, use the term "Service Chaining". SFC may be one of approaches to realize Service Chaining. There are several Service Chaining methods to forward data packets to service functions, and the applicable methods will vary depending on the service requirements of individual networks. This document presents the results of analyzing packet forwarding methods and path selection patterns for achieving Service Chaining. For forwarding data packets to the appropriate service functions, distribution of route information and steering data packets following the route information, are required. Examples of route information are packet identifier and the routing configurations based on the identifier. Also, forwarding functions are required to decide the path according to the route information. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Jan 23 04:23:34 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A721A066C; Fri, 23 Jan 2015 02:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDPtkIlldHA1; Fri, 23 Jan 2015 02:28:13 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C401A049C; Fri, 23 Jan 2015 02:28:13 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id bs8so1758653wib.5; Fri, 23 Jan 2015 02:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=TlKN9okzEMYp/eoA00hh/YfvXTbDsk1M/evJC4zvR2Y=; b=nQAgLFfkf/AuwwkF78v+/POvgJrI+waYQnai5f8ZmbSMRH4T0GHYYmDIlSbAwHWZEd c3HO/9GpmwiqyRQ3car6vZO8bNmV6s+odLxn6pj1HYIhLZtKAEE696Ao5ZG0doaXAA09 1Vj0xvWb5ocWnUVZh/0z69kwwDABBf3l9l7KVwNqyKpe0+H5tsMDfHbFUjQRwf9TFmcA tXjGJFht6h7dEyoMOxdjwdyDeYABiCLnL7BZuPjDp+vJ0Dmf8BE7eQvwKVL9Oc+fl85H c+OS4LrH8SRyLRARXX9tQFlsN/QBVE3T26bKpl5QFr+ybyfImvUk1F3RDWaeiJtP8Se+ qb9Q== X-Received: by 10.180.38.66 with SMTP id e2mr2169317wik.55.1422008892143; Fri, 23 Jan 2015 02:28:12 -0800 (PST) Received: from McObelix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id u13sm1600259wjr.26.2015.01.23.02.28.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jan 2015 02:28:11 -0800 (PST) Message-ID: <54C2223A.3080605@gmail.com> Date: Fri, 23 Jan 2015 11:28:10 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Xuxiaohu , "sfc@ietf.org" , "mpls@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 23 Jan 2015 04:23:27 -0800 Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 10:28:18 -0000 Xuxiaohu æ‚¨å¥½ï¼ Please correct me if I am wrong: It has always been my understanding that the MPLS header/label was independent of the protocol/payload. So no indication of the actual payload content was necessary. IMHO you could use the alert label 1 to indicate to the LSR that it has to further examine the content of a packet. Regards, Huub. ======== > It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04): > > The service header is independent of the encapsulation used and is > encapsulated in existing transports. The presence of NSH is > indicated via protocol type or other indicator in the outer > encapsulation. > > In the case where the outer encapsulation is an MPLS LSP, how to indicate the presence of NSH since the MPLS encapsulation has no explicit protocol identifier field to indicate the protocol type of the MPLS payload? Should we make each SFF to allocate a unique label for indicating the presence of NSH? Or should we use the control word to indicate it? Or should we reconsider the possibility of adding an explicit protocol identifier field to the MPLS encapsulation so as to solve such kind of issues once and for all? > > Best regards, > Xiaohu > -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From nobody Fri Jan 23 08:24:49 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7EF1A9126 for ; Fri, 23 Jan 2015 08:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SDcORPSznBA for ; Fri, 23 Jan 2015 08:24:44 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD301A1B06 for ; Fri, 23 Jan 2015 08:24:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 617AE1BC287B; Fri, 23 Jan 2015 08:24:27 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-12.clppva.east.verizon.net [70.106.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 224B31BC1E49; Fri, 23 Jan 2015 08:24:26 -0800 (PST) Message-ID: <54C27592.2050507@joelhalpern.com> Date: Fri, 23 Jan 2015 11:23:46 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Ramki Krishnan , "Jim Guichard (jguichar)" , "sfc@ietf.org" References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 16:24:46 -0000 Tiru, with regard to the ter firewall, I think the problem is what we mean by the word. Unfortunately, there is no industry or IETF standard definition. In my experience, people differentiate between firewall functionality, intrusion detection functionality, and various forms of malware detection / protection functionality. Some firewall products offer combinations of these features. In our terms, we are discussing functionality, not product. Firewall is the term that I am familiar with for a device that does statefull or stateless filtering based on the L2, L3, and L4-header portions of the message. Is there another term you would like us to use instead of firewall for this kind of functionality? Yours, Joel On 1/23/15 1:01 AM, Tirumaleswar Reddy (tireddy) wrote: > Inline [TR] > > *From:*Ramki Krishnan [mailto:ramk@Brocade.com] > *Sent:* Friday, January 23, 2015 10:41 AM > *To:* Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); sfc@ietf.org > *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Hi Tiru, > > Thanks, please find inline. > > Thanks, > > Ramki > > *From:*Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > *Sent:* Thursday, January 22, 2015 8:27 PM > *To:* Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org > > *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Hi Ramki, > > Comments: > > 1. > > A transparent firewall may be able to determine that a long-lived > > flow (e.g. video stream, file transfer) has no security issues. > > Comment> In the above line you may want to consider removing “file > transfer”, FW to inspect files has to act as a L7 proxy and it is not > possible to remove itself from the path after the file transfer is > initiated. > > Ramki: Firewalls do not examine every byte of content. Examining every > byte of content is performed by virus scanner, content scanner etc. > > [TR] Firewalls do have the capability to inspect files to block viruses, > malware etc.. FW acts as a proxy, fetches the complete file from the > server and scans the file. > > 2. > > a. The packets which are encrypted at the application layer > > using protocols such as HTTPS [RFC 2660] cannot be decrypted > > and examined further. > > Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used > for file transfer and Firewall acts as HTTPS proxy then it cannot > by-pass the flow. HTTP/2.0 mandates TLS. > > Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in the > event sequence, SFC manipulation happens at the Layer 2/3/4 level. > > [TR] I may have missed, but did not see any mention in the draft that > the service functions do not modify L7 and only manipulate 2/3/4 level. > If will be good to explicitly mention that to avoid confusion and also > discuss the implication of L4 manipulations with TCP authentication in > Security considerations section. > > 3. > > b. The packets are from a trusted source. > > c. The packets are from a trusted application. > > Comment> If firewall is white-listing based on destination IP address > then the by-pass decision can be made on the SYN packet itself. > > Ramki: Agree that this is a good criterion. As we described in the > draft, the list of criteria is not exhaustive – it is hard to include > every possible case. > > [TR] Okay. > > 4. > > A monitoring element such as a DPI appliance analyzes the new > > flows arriving at the default SecGW device used by a given eNodeB > > device according to criteria such as: > > Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS proxy > and will result in privacy problems. It may also conflict with the work > in other WG like tcpinc with proposals to automatically use TLS without > modifying the application layer protocol. > > Ramki: HTTP/2.0 does not mandate encryption -- > http://http2.github.io/faq/#does-http2-require-encryption. We are > addressing only the non-encrypted case. > > [TR] It may be good to explicitly mention that the use cases deal with > only plain text traffic. > > -Tiru > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ramki Krishnan > *Sent:* Thursday, January 22, 2015 10:39 AM > *To:* Jim Guichard (jguichar); sfc@ietf.org > *Subject:* Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Many thanks for the comments so far; please find an updated version of > the draft addressing them. > > http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/ > > Thanks, > > Ramki > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > (jguichar) > *Sent:* Monday, December 15, 2014 7:15 AM > *To:* sfc@ietf.org > *Subject:* [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Dear WG: > > This note begins a 2-week WG LC on > draft-ietf-sfc-long-lived-flow-use-cases.01.txt. > > The document authors have indicated that they have addressed all known > comments and that there are no open issues with the current version of > the document. > > Substantive comments to the list please, editorial comments can go > directly to the document editors. > > Jim & Thomas > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri Jan 23 08:40:52 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947091A1B06 for ; Fri, 23 Jan 2015 08:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Rgvr2Ha_9Y9 for ; Fri, 23 Jan 2015 08:40:49 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58EE31A1AD8 for ; Fri, 23 Jan 2015 08:40:49 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-70-54c226e98291 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E3.46.03307.9E622C45; Fri, 23 Jan 2015 11:48:09 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 11:40:47 -0500 From: David Allan I To: "Joel M. Halpern" , "Tirumaleswar Reddy (tireddy)" , Ramki Krishnan , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQgAFlkJCAACcfAIAADCYwgAEKfgD//7DS0A== Date: Fri, 23 Jan 2015 16:40:46 +0000 Message-ID: References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> <54C27592.2050507@joelhalpern.com> In-Reply-To: <54C27592.2050507@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPiO5LtUMhBm9viVksnadu8fHUGyaL bTN/Mls8ebCV3eLE7m2MDqwePccus3lM+b2R1WPJkp9MHuemfGcMYInisklJzcksSy3St0vg ynh6qK5gjkHF1o1LWBoYr6t1MXJySAiYSKyZvIYdwhaTuHBvPVsXIxeHkMARRomJO6cyQjjL GSU2v13NCFLFJmAgsef/F7CEiMBVRokpnceYQBLCAh4S3w+2sIDYIgKeEse2dbFB2GES+7tP ga1gEVCVuH98I1A9BwevgK9E79soiAUPmCQurF8PVs8poC/x8FwjmM0IdNL3U2vA5jMLiEvc ejKfCeJUAYkle84zQ9iiEi8f/2OFsJUkJi09xwpRryOxYPcnNghbW2LZwtdg9bwCghInZz5h mcAoOgvJ2FlIWmYhaZmFpGUBI8sqRo7S4tSy3HQjg02MwPg5JsGmu4Nxz0vLQ4wCHIxKPLwf Gg6GCLEmlhVX5h5ilOZgURLnXfQAKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxM3ZFcam2 lru8T7GNhvdp3RVv46+mzxeVltWYs+bBWcbjLdde7Go57GwnvVRSQXDT4YnLrfQfBM6cKv5W d3/L1Guef7Kn7lJ2mZAfUOu5+dMBHz5p59lHGpzXVM9eXTtpvvVa23fpHArbqiV16u9FbVPa fbd4+goWdp9FxbOMjR9ty7Cold6pxFKckWioxVxUnAgAhYyLaIACAAA= Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 16:40:51 -0000 My calendar is up to date...and I'm in San Jose next week. Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Friday, January 23, 2015 8:24 AM To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard (jguichar); = sfc@ietf.org Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Tiru, with regard to the ter firewall, I think the problem is what we mean = by the word. Unfortunately, there is no industry or IETF standard definition. In my experience, people differentiate between firewall functionality, intr= usion detection functionality, and various forms of malware detection / pro= tection functionality. Some firewall products offer combinations of these features. In our terms, we are discussing functionality, not product. Firewall is th= e term that I am familiar with for a device that does statefull or stateles= s filtering based on the L2, L3, and L4-header portions of the message. Is there another term you would like us to use instead of firewall for this= kind of functionality? Yours, Joel On 1/23/15 1:01 AM, Tirumaleswar Reddy (tireddy) wrote: > Inline [TR] > > *From:*Ramki Krishnan [mailto:ramk@Brocade.com] > *Sent:* Friday, January 23, 2015 10:41 AM > *To:* Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar);=20 > sfc@ietf.org > *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Hi Tiru, > > Thanks, please find inline. > > Thanks, > > Ramki > > *From:*Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > *Sent:* Thursday, January 22, 2015 8:27 PM > *To:* Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org=20 > > *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Hi Ramki, > > Comments: > > 1. > > A transparent firewall may be able to determine that a long-lived > > flow (e.g. video stream, file transfer) has no security issues. > > Comment> In the above line you may want to consider removing "file > transfer", FW to inspect files has to act as a L7 proxy and it is not=20 > possible to remove itself from the path after the file transfer is=20 > initiated. > > Ramki: Firewalls do not examine every byte of content. Examining every=20 > byte of content is performed by virus scanner, content scanner etc. > > [TR] Firewalls do have the capability to inspect files to block=20 > viruses, malware etc.. FW acts as a proxy, fetches the complete file=20 > from the server and scans the file. > > 2. > > a. The packets which are encrypted at the application layer > > using protocols such as HTTPS [RFC 2660] cannot be=20 > decrypted > > and examined further. > > Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used > for file transfer and Firewall acts as HTTPS proxy then it cannot=20 > by-pass the flow. HTTP/2.0 mandates TLS. > > Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in the=20 > event sequence, SFC manipulation happens at the Layer 2/3/4 level. > > [TR] I may have missed, but did not see any mention in the draft that=20 > the service functions do not modify L7 and only manipulate 2/3/4 level. > If will be good to explicitly mention that to avoid confusion and also=20 > discuss the implication of L4 manipulations with TCP authentication in=20 > Security considerations section. > > 3. > > b. The packets are from a trusted source. > > c. The packets are from a trusted application. > > Comment> If firewall is white-listing based on destination IP address > then the by-pass decision can be made on the SYN packet itself. > > Ramki: Agree that this is a good criterion. As we described in the=20 > draft, the list of criteria is not exhaustive - it is hard to include=20 > every possible case. > > [TR] Okay. > > 4. > > A monitoring element such as a DPI appliance analyzes the new > > flows arriving at the default SecGW device used by a given=20 > eNodeB > > device according to criteria such as: > > Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS=20 > Comment> proxy > and will result in privacy problems. It may also conflict with the=20 > work in other WG like tcpinc with proposals to automatically use TLS=20 > without modifying the application layer protocol. > > Ramki: HTTP/2.0 does not mandate encryption --=20 > http://http2.github.io/faq/#does-http2-require-encryption. We are=20 > addressing only the non-encrypted case. > > [TR] It may be good to explicitly mention that the use cases deal with=20 > only plain text traffic. > > -Tiru > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ramki Krishnan > *Sent:* Thursday, January 22, 2015 10:39 AM > *To:* Jim Guichard (jguichar); sfc@ietf.org > *Subject:* Re: [sfc] WG LC for=20 > draft-ietf-sfc-long-lived-flow-use-cases-01 > > Many thanks for the comments so far; please find an updated version of=20 > the draft addressing them. > > http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cas > es/ > > Thanks, > > Ramki > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > (jguichar) > *Sent:* Monday, December 15, 2014 7:15 AM > *To:* sfc@ietf.org > *Subject:* [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Dear WG: > > This note begins a 2-week WG LC on > draft-ietf-sfc-long-lived-flow-use-cases.01.txt. > > The document authors have indicated that they have addressed all known=20 > comments and that there are no open issues with the current version of=20 > the document. > > Substantive comments to the list please, editorial comments can go=20 > directly to the document editors. > > Jim & Thomas > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jan 23 08:42:00 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088891A9121 for ; Fri, 23 Jan 2015 08:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yao8P-UtSejX for ; Fri, 23 Jan 2015 08:41:55 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EF51A8877 for ; Fri, 23 Jan 2015 08:41:55 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-18-54c21b0024a2 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 23.85.25146.00B12C45; Fri, 23 Jan 2015 10:57:20 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 11:41:53 -0500 From: David Allan I To: David Allan I , "Joel M. Halpern" , "Tirumaleswar Reddy (tireddy)" , Ramki Krishnan , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQgAFlkJCAACcfAIAADCYwgAEKfgD//7DS0IAAAFUQ Date: Fri, 23 Jan 2015 16:41:53 +0000 Message-ID: References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> <54C27592.2050507@joelhalpern.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.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPuC6D9KEQg8mLpSyWzlO3+HjqDZPF tpk/mS2ePNjKbnFi9zZGB1aPnmOX2Tym/N7I6rFkyU8mj3NTvjMGsERx2aSk5mSWpRbp2yVw ZfRNOstW0GhS0d6+mb2B8ZtmFyMnh4SAicTnjZNZIGwxiQv31rN1MXJxCAkcYZRYuuUOC4Sz nFFi/c+HzCBVbAIGEnv+f2EESYgINDNJzH76kw0kISzgIfH9YAvYKBEBT4lj27rYIOwoiSUz ZrGD2CwCqhL3Xx4Bi/MK+Ers+rKAHWLDEmaJ1yshmjkF/CQ29F4BsxmBbvp+ag0TiM0sIC5x 68l8JohbBSSW7DnPDGGLSrx8/I8VwlaSmLT0HCtEvY7Egt2f2CBsbYllC18zQywWlDg58wnL BEbRWUjGzkLSMgtJyywkLQsYWVYxcpQWp5blphsZbmIExtAxCTbHHYwLPlkeYhTgYFTi4f3Q cDBEiDWxrLgy9xCjNAeLkjhv2RWgkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkZhxfOhVQyz gxkDcrdqsW63U6ph+nNIhyfxvWGJh+YuFa4OFbtb53+Z87gs/3LcXlfJb+7hHTZpxeWH+yca 7eB/tN4h7lWU3MLoQ6cOVG65+2Mdw4Iz/oHvTtzTr1e8uZZ1b6dfM/usSsZ640kbFgU8aPa4 66l0QufQxtOxM1XlJk/6obvt/VwlluKMREMt5qLiRAABTvzRggIAAA== Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 16:41:58 -0000 Please ignore, outlook hiccup Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of David Allan I Sent: Friday, January 23, 2015 8:41 AM To: Joel M. Halpern; Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guic= hard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 My calendar is up to date...and I'm in San Jose next week. Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Friday, January 23, 2015 8:24 AM To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard (jguichar); = sfc@ietf.org Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Tiru, with regard to the ter firewall, I think the problem is what we mean = by the word. Unfortunately, there is no industry or IETF standard definition. In my experience, people differentiate between firewall functionality, intr= usion detection functionality, and various forms of malware detection / pro= tection functionality. Some firewall products offer combinations of these features. In our terms, we are discussing functionality, not product. Firewall is th= e term that I am familiar with for a device that does statefull or stateles= s filtering based on the L2, L3, and L4-header portions of the message. Is there another term you would like us to use instead of firewall for this= kind of functionality? Yours, Joel On 1/23/15 1:01 AM, Tirumaleswar Reddy (tireddy) wrote: > Inline [TR] > > *From:*Ramki Krishnan [mailto:ramk@Brocade.com] > *Sent:* Friday, January 23, 2015 10:41 AM > *To:* Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar);=20 > sfc@ietf.org > *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Hi Tiru, > > Thanks, please find inline. > > Thanks, > > Ramki > > *From:*Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > *Sent:* Thursday, January 22, 2015 8:27 PM > *To:* Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org=20 > > *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Hi Ramki, > > Comments: > > 1. > > A transparent firewall may be able to determine that a long-lived > > flow (e.g. video stream, file transfer) has no security issues. > > Comment> In the above line you may want to consider removing "file > transfer", FW to inspect files has to act as a L7 proxy and it is not=20 > possible to remove itself from the path after the file transfer is=20 > initiated. > > Ramki: Firewalls do not examine every byte of content. Examining every=20 > byte of content is performed by virus scanner, content scanner etc. > > [TR] Firewalls do have the capability to inspect files to block=20 > viruses, malware etc.. FW acts as a proxy, fetches the complete file=20 > from the server and scans the file. > > 2. > > a. The packets which are encrypted at the application layer > > using protocols such as HTTPS [RFC 2660] cannot be=20 > decrypted > > and examined further. > > Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used > for file transfer and Firewall acts as HTTPS proxy then it cannot=20 > by-pass the flow. HTTP/2.0 mandates TLS. > > Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in the=20 > event sequence, SFC manipulation happens at the Layer 2/3/4 level. > > [TR] I may have missed, but did not see any mention in the draft that=20 > the service functions do not modify L7 and only manipulate 2/3/4 level. > If will be good to explicitly mention that to avoid confusion and also=20 > discuss the implication of L4 manipulations with TCP authentication in=20 > Security considerations section. > > 3. > > b. The packets are from a trusted source. > > c. The packets are from a trusted application. > > Comment> If firewall is white-listing based on destination IP address > then the by-pass decision can be made on the SYN packet itself. > > Ramki: Agree that this is a good criterion. As we described in the=20 > draft, the list of criteria is not exhaustive - it is hard to include=20 > every possible case. > > [TR] Okay. > > 4. > > A monitoring element such as a DPI appliance analyzes the new > > flows arriving at the default SecGW device used by a given=20 > eNodeB > > device according to criteria such as: > > Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS=20 > Comment> proxy > and will result in privacy problems. It may also conflict with the=20 > work in other WG like tcpinc with proposals to automatically use TLS=20 > without modifying the application layer protocol. > > Ramki: HTTP/2.0 does not mandate encryption --=20 > http://http2.github.io/faq/#does-http2-require-encryption. We are=20 > addressing only the non-encrypted case. > > [TR] It may be good to explicitly mention that the use cases deal with=20 > only plain text traffic. > > -Tiru > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ramki Krishnan > *Sent:* Thursday, January 22, 2015 10:39 AM > *To:* Jim Guichard (jguichar); sfc@ietf.org > *Subject:* Re: [sfc] WG LC for > draft-ietf-sfc-long-lived-flow-use-cases-01 > > Many thanks for the comments so far; please find an updated version of=20 > the draft addressing them. > > http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cas > es/ > > Thanks, > > Ramki > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > (jguichar) > *Sent:* Monday, December 15, 2014 7:15 AM > *To:* sfc@ietf.org > *Subject:* [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > Dear WG: > > This note begins a 2-week WG LC on > draft-ietf-sfc-long-lived-flow-use-cases.01.txt. > > The document authors have indicated that they have addressed all known=20 > comments and that there are no open issues with the current version of=20 > the document. > > Substantive comments to the list please, editorial comments can go=20 > directly to the document editors. > > Jim & Thomas > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jan 23 09:24:57 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAE01AC39E for ; Fri, 23 Jan 2015 09:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZxPKH8RAy7A for ; Fri, 23 Jan 2015 09:24:53 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36AC11A8873 for ; Fri, 23 Jan 2015 09:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6564; q=dns/txt; s=iport; t=1422033890; x=1423243490; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=V4HPsSDVAWSH607wgRR3shImVYlVx8b3q56c1KKFUnQ=; b=atEeruuX3muu6u+vv52/9oylejWs7hG6c6aE64GBaBwfSvLPuSHjh6sx X0A3lvuA3QQlrLQF6pzK/x+U0rIK51NKIcrLA2pyMGGboW01hDLUzHA80 z5GASTsCqwkx5c/8Xi4hqVUXVL/YBDkV4iTWFTemojY348UdLqrF0kcTA s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsFABKDwlStJV2Z/2dsb2JhbABagwZSWATEKoIbCoVxAoEXQwEBAQEBfYQMAQEBAwEBAQE3NBcEAgEIEQQBAQEKFAkHJwsUCQgCBAEJCQiIHAgN0hoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0c4BoMQgRMFjmaDSoZjNoJIjiMig25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.09,454,1418083200"; d="scan'208";a="390301241" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 23 Jan 2015 17:24:49 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0NHOmTG020387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 17:24:48 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 11:24:47 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Joel M. Halpern" , Ramki Krishnan , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQgAFlkJCAACcfAIAADCYwgAEbQQD//6qx4A== Date: Fri, 23 Jan 2015 17:24:47 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35530207@xmb-rcd-x10.cisco.com> References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> <54C27592.2050507@joelhalpern.com> In-Reply-To: <54C27592.2050507@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.67.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 17:24:56 -0000 Hi Joel, Please see inline > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Friday, January 23, 2015 9:54 PM > To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard (jguichar)= ; > sfc@ietf.org > Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 >=20 > Tiru, with regard to the ter firewall, I think the problem is what we mea= n by > the word. >=20 > Unfortunately, there is no industry or IETF standard definition. > In my experience, people differentiate between firewall functionality, > intrusion detection functionality, and various forms of malware detection= / > protection functionality. > Some firewall products offer combinations of these features. >=20 > In our terms, we are discussing functionality, not product. Firewall is = the > term that I am familiar with for a device that does statefull or stateles= s > filtering based on the L2, L3, and L4-header portions of the message. Firewalls also operate at Layer 7, you may refer to the terminology explain= ed in https://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01=20 >=20 > Is there another term you would like us to use instead of firewall for th= is kind > of functionality? I guess a note in the draft that the firewall discussed does not operate at= Layer 7 would avoid the confusion. Cheers, -Tiru >=20 > Yours, > Joel >=20 > On 1/23/15 1:01 AM, Tirumaleswar Reddy (tireddy) wrote: > > Inline [TR] > > > > *From:*Ramki Krishnan [mailto:ramk@Brocade.com] > > *Sent:* Friday, January 23, 2015 10:41 AM > > *To:* Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); > > sfc@ietf.org > > *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > > > Hi Tiru, > > > > Thanks, please find inline. > > > > Thanks, > > > > Ramki > > > > *From:*Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > > *Sent:* Thursday, January 22, 2015 8:27 PM > > *To:* Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org > > > > *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > > > Hi Ramki, > > > > Comments: > > > > 1. > > > > A transparent firewall may be able to determine that a long-lived > > > > flow (e.g. video stream, file transfer) has no security issues. > > > > Comment> In the above line you may want to consider removing "file > > transfer", FW to inspect files has to act as a L7 proxy and it is not > > possible to remove itself from the path after the file transfer is > > initiated. > > > > Ramki: Firewalls do not examine every byte of content. Examining every > > byte of content is performed by virus scanner, content scanner etc. > > > > [TR] Firewalls do have the capability to inspect files to block > > viruses, malware etc.. FW acts as a proxy, fetches the complete file > > from the server and scans the file. > > > > 2. > > > > a. The packets which are encrypted at the application layer > > > > using protocols such as HTTPS [RFC 2660] cannot be > > decrypted > > > > and examined further. > > > > Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used > > for file transfer and Firewall acts as HTTPS proxy then it cannot > > by-pass the flow. HTTP/2.0 mandates TLS. > > > > Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in the > > event sequence, SFC manipulation happens at the Layer 2/3/4 level. > > > > [TR] I may have missed, but did not see any mention in the draft that > > the service functions do not modify L7 and only manipulate 2/3/4 level. > > If will be good to explicitly mention that to avoid confusion and also > > discuss the implication of L4 manipulations with TCP authentication in > > Security considerations section. > > > > 3. > > > > b. The packets are from a trusted source. > > > > c. The packets are from a trusted application. > > > > Comment> If firewall is white-listing based on destination IP address > > then the by-pass decision can be made on the SYN packet itself. > > > > Ramki: Agree that this is a good criterion. As we described in the > > draft, the list of criteria is not exhaustive - it is hard to include > > every possible case. > > > > [TR] Okay. > > > > 4. > > > > A monitoring element such as a DPI appliance analyzes the new > > > > flows arriving at the default SecGW device used by a given > > eNodeB > > > > device according to criteria such as: > > > > Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS > > Comment> proxy > > and will result in privacy problems. It may also conflict with the > > work in other WG like tcpinc with proposals to automatically use TLS > > without modifying the application layer protocol. > > > > Ramki: HTTP/2.0 does not mandate encryption -- > > http://http2.github.io/faq/#does-http2-require-encryption. We are > > addressing only the non-encrypted case. > > > > [TR] It may be good to explicitly mention that the use cases deal with > > only plain text traffic. > > > > -Tiru > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ramki Krishnan > > *Sent:* Thursday, January 22, 2015 10:39 AM > > *To:* Jim Guichard (jguichar); sfc@ietf.org > > *Subject:* Re: [sfc] WG LC for > > draft-ietf-sfc-long-lived-flow-use-cases-01 > > > > Many thanks for the comments so far; please find an updated version of > > the draft addressing them. > > > > http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cas > > es/ > > > > Thanks, > > > > Ramki > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > > (jguichar) > > *Sent:* Monday, December 15, 2014 7:15 AM > > *To:* sfc@ietf.org > > *Subject:* [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > > > > Dear WG: > > > > This note begins a 2-week WG LC on > > draft-ietf-sfc-long-lived-flow-use-cases.01.txt. > > > > The document authors have indicated that they have addressed all known > > comments and that there are no open issues with the current version of > > the document. > > > > Substantive comments to the list please, editorial comments can go > > directly to the document editors. > > > > Jim & Thomas > > > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Fri Jan 23 09:40:49 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1E61A1EE8 for ; Fri, 23 Jan 2015 09:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aJV0ywTN6B8 for ; Fri, 23 Jan 2015 09:40:45 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255911A1ADB for ; Fri, 23 Jan 2015 09:40:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id F074F1BC6BC6; Fri, 23 Jan 2015 09:40:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-12.clppva.east.verizon.net [70.106.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 56E1C1BC6AC6; Fri, 23 Jan 2015 09:40:35 -0800 (PST) Message-ID: <54C28767.20305@joelhalpern.com> Date: Fri, 23 Jan 2015 12:39:51 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Ramki Krishnan , "Jim Guichard (jguichar)" , "sfc@ietf.org" References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> <54C27592.2050507@joelhalpern.com> <913383AAA69FF945B8F946018B75898A35530207@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A35530207@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 17:40:47 -0000 I can live with a parenthetical or sentence indicating that the firewalls we are referring to are those operating at layer 3 or 4. If you think it is helpful, we could put in an informative reference to the OPSAWG document. I had not seen that before myself. Thank you for the pointer. Yours, Joel On 1/23/15 12:24 PM, Tirumaleswar Reddy (tireddy) wrote: > Hi Joel, > > Please see inline > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Friday, January 23, 2015 9:54 PM >> To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard (jguichar); >> sfc@ietf.org >> Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 >> >> Tiru, with regard to the ter firewall, I think the problem is what we mean by >> the word. >> >> Unfortunately, there is no industry or IETF standard definition. >> In my experience, people differentiate between firewall functionality, >> intrusion detection functionality, and various forms of malware detection / >> protection functionality. >> Some firewall products offer combinations of these features. >> >> In our terms, we are discussing functionality, not product. Firewall is the >> term that I am familiar with for a device that does statefull or stateless >> filtering based on the L2, L3, and L4-header portions of the message. > > Firewalls also operate at Layer 7, you may refer to the terminology explained in https://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01 > >> >> Is there another term you would like us to use instead of firewall for this kind >> of functionality? > > I guess a note in the draft that the firewall discussed does not operate at Layer 7 would avoid the confusion. > > Cheers, > -Tiru > >> >> Yours, >> Joel >> >> On 1/23/15 1:01 AM, Tirumaleswar Reddy (tireddy) wrote: >>> Inline [TR] >>> >>> *From:*Ramki Krishnan [mailto:ramk@Brocade.com] >>> *Sent:* Friday, January 23, 2015 10:41 AM >>> *To:* Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); >>> sfc@ietf.org >>> *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 >>> >>> Hi Tiru, >>> >>> Thanks, please find inline. >>> >>> Thanks, >>> >>> Ramki >>> >>> *From:*Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >>> *Sent:* Thursday, January 22, 2015 8:27 PM >>> *To:* Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org >>> >>> *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 >>> >>> Hi Ramki, >>> >>> Comments: >>> >>> 1. >>> >>> A transparent firewall may be able to determine that a long-lived >>> >>> flow (e.g. video stream, file transfer) has no security issues. >>> >>> Comment> In the above line you may want to consider removing "file >>> transfer", FW to inspect files has to act as a L7 proxy and it is not >>> possible to remove itself from the path after the file transfer is >>> initiated. >>> >>> Ramki: Firewalls do not examine every byte of content. Examining every >>> byte of content is performed by virus scanner, content scanner etc. >>> >>> [TR] Firewalls do have the capability to inspect files to block >>> viruses, malware etc.. FW acts as a proxy, fetches the complete file >>> from the server and scans the file. >>> >>> 2. >>> >>> a. The packets which are encrypted at the application layer >>> >>> using protocols such as HTTPS [RFC 2660] cannot be >>> decrypted >>> >>> and examined further. >>> >>> Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used >>> for file transfer and Firewall acts as HTTPS proxy then it cannot >>> by-pass the flow. HTTP/2.0 mandates TLS. >>> >>> Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in the >>> event sequence, SFC manipulation happens at the Layer 2/3/4 level. >>> >>> [TR] I may have missed, but did not see any mention in the draft that >>> the service functions do not modify L7 and only manipulate 2/3/4 level. >>> If will be good to explicitly mention that to avoid confusion and also >>> discuss the implication of L4 manipulations with TCP authentication in >>> Security considerations section. >>> >>> 3. >>> >>> b. The packets are from a trusted source. >>> >>> c. The packets are from a trusted application. >>> >>> Comment> If firewall is white-listing based on destination IP address >>> then the by-pass decision can be made on the SYN packet itself. >>> >>> Ramki: Agree that this is a good criterion. As we described in the >>> draft, the list of criteria is not exhaustive - it is hard to include >>> every possible case. >>> >>> [TR] Okay. >>> >>> 4. >>> >>> A monitoring element such as a DPI appliance analyzes the new >>> >>> flows arriving at the default SecGW device used by a given >>> eNodeB >>> >>> device according to criteria such as: >>> >>> Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS >>> Comment> proxy >>> and will result in privacy problems. It may also conflict with the >>> work in other WG like tcpinc with proposals to automatically use TLS >>> without modifying the application layer protocol. >>> >>> Ramki: HTTP/2.0 does not mandate encryption -- >>> http://http2.github.io/faq/#does-http2-require-encryption. We are >>> addressing only the non-encrypted case. >>> >>> [TR] It may be good to explicitly mention that the use cases deal with >>> only plain text traffic. >>> >>> -Tiru >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ramki Krishnan >>> *Sent:* Thursday, January 22, 2015 10:39 AM >>> *To:* Jim Guichard (jguichar); sfc@ietf.org >>> *Subject:* Re: [sfc] WG LC for >>> draft-ietf-sfc-long-lived-flow-use-cases-01 >>> >>> Many thanks for the comments so far; please find an updated version of >>> the draft addressing them. >>> >>> http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cas >>> es/ >>> >>> Thanks, >>> >>> Ramki >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >>> (jguichar) >>> *Sent:* Monday, December 15, 2014 7:15 AM >>> *To:* sfc@ietf.org >>> *Subject:* [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 >>> >>> Dear WG: >>> >>> This note begins a 2-week WG LC on >>> draft-ietf-sfc-long-lived-flow-use-cases.01.txt. >>> >>> The document authors have indicated that they have addressed all known >>> comments and that there are no open issues with the current version of >>> the document. >>> >>> Substantive comments to the list please, editorial comments can go >>> directly to the document editors. >>> >>> Jim & Thomas >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> > From nobody Fri Jan 23 10:17:19 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D1C1ACD43 for ; Fri, 23 Jan 2015 10:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srA3rLZ9pPV2 for ; Fri, 23 Jan 2015 10:17:14 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5DE1ACD3F for ; Fri, 23 Jan 2015 10:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7794; q=dns/txt; s=iport; t=1422037034; x=1423246634; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PVzxPchnBlXoVHIsDV8xQSMlZ82XwSvr95/wmN1O5FA=; b=EgJs+NTJxi5ppgxhMUFB4KY48ubeXURdGCQGWJ4BGyhlMnq5nk95BZwN KPTyu8mS7BxOM3OXV9dT9JCDwJEeXK3qCZclezedJ6gQrw5nGgHZYF6sk iC1i+QnD3RDjzTM60W2bLJIxpfQ3HIHLyEZvoqqqzGLauck2/DSoFShJ2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsFAGaPwlStJA2M/2dsb2JhbABagwZSWATEKoIbCoVxAoEXQwEBAQEBfYQMAQEBAwEBAQE3NBAHBAIBCBEEAQEBChQJBycLFAkIAgQBCQkIiBwIDdIHAQEBAQEBAQEBAQEBAQEBAQEBAQEBF49HOAaDEIETBY0GgWCDSoZjNoJIjiMig25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.09,455,1418083200"; d="scan'208";a="117024030" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP; 23 Jan 2015 18:17:13 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t0NIHCqi005960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 18:17:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 12:17:12 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Joel M. Halpern" , Ramki Krishnan , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQgAFlkJCAACcfAIAADCYwgAEbQQD//6qx4IAAapGA//+lvFA= Date: Fri, 23 Jan 2015 18:17:12 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A355302AE@xmb-rcd-x10.cisco.com> References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> <54C27592.2050507@joelhalpern.com> <913383AAA69FF945B8F946018B75898A35530207@xmb-rcd-x10.cisco.com> <54C28767.20305@joelhalpern.com> In-Reply-To: <54C28767.20305@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.67.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 18:17:16 -0000 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Friday, January 23, 2015 11:10 PM > To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard (jguichar)= ; > sfc@ietf.org > Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 >=20 > I can live with a parenthetical or sentence indicating that the firewalls= we are > referring to are those operating at layer 3 or 4.=20 Works for me. -Tiru > If you think it is helpful, we > could put in an informative reference to the OPSAWG document. I had not > seen that before myself. Thank you for the pointer. >=20 > Yours, > Joel >=20 > On 1/23/15 12:24 PM, Tirumaleswar Reddy (tireddy) wrote: > > Hi Joel, > > > > Please see inline > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Friday, January 23, 2015 9:54 PM > >> To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard > >> (jguichar); sfc@ietf.org > >> Subject: Re: [sfc] WG LC for > >> draft-ietf-sfc-long-lived-flow-use-cases-01 > >> > >> Tiru, with regard to the ter firewall, I think the problem is what we > >> mean by the word. > >> > >> Unfortunately, there is no industry or IETF standard definition. > >> In my experience, people differentiate between firewall > >> functionality, intrusion detection functionality, and various forms > >> of malware detection / protection functionality. > >> Some firewall products offer combinations of these features. > >> > >> In our terms, we are discussing functionality, not product. Firewall > >> is the term that I am familiar with for a device that does statefull > >> or stateless filtering based on the L2, L3, and L4-header portions of = the > message. > > > > Firewalls also operate at Layer 7, you may refer to the terminology > > explained in > > https://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01 > > > >> > >> Is there another term you would like us to use instead of firewall > >> for this kind of functionality? > > > > I guess a note in the draft that the firewall discussed does not operat= e at > Layer 7 would avoid the confusion. > > > > Cheers, > > -Tiru > > > >> > >> Yours, > >> Joel > >> > >> On 1/23/15 1:01 AM, Tirumaleswar Reddy (tireddy) wrote: > >>> Inline [TR] > >>> > >>> *From:*Ramki Krishnan [mailto:ramk@Brocade.com] > >>> *Sent:* Friday, January 23, 2015 10:41 AM > >>> *To:* Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); > >>> sfc@ietf.org > >>> *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > >>> > >>> Hi Tiru, > >>> > >>> Thanks, please find inline. > >>> > >>> Thanks, > >>> > >>> Ramki > >>> > >>> *From:*Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > >>> *Sent:* Thursday, January 22, 2015 8:27 PM > >>> *To:* Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org > >>> > >>> *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > >>> > >>> Hi Ramki, > >>> > >>> Comments: > >>> > >>> 1. > >>> > >>> A transparent firewall may be able to determine that a > >>> long-lived > >>> > >>> flow (e.g. video stream, file transfer) has no security issues. > >>> > >>> Comment> In the above line you may want to consider removing "file > >>> transfer", FW to inspect files has to act as a L7 proxy and it is > >>> not possible to remove itself from the path after the file transfer > >>> is initiated. > >>> > >>> Ramki: Firewalls do not examine every byte of content. Examining > >>> every byte of content is performed by virus scanner, content scanner = etc. > >>> > >>> [TR] Firewalls do have the capability to inspect files to block > >>> viruses, malware etc.. FW acts as a proxy, fetches the complete file > >>> from the server and scans the file. > >>> > >>> 2. > >>> > >>> a. The packets which are encrypted at the application > >>> layer > >>> > >>> using protocols such as HTTPS [RFC 2660] cannot be > >>> decrypted > >>> > >>> and examined further. > >>> > >>> Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is > >>> Comment> used > >>> for file transfer and Firewall acts as HTTPS proxy then it cannot > >>> by-pass the flow. HTTP/2.0 mandates TLS. > >>> > >>> Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in > >>> the event sequence, SFC manipulation happens at the Layer 2/3/4 level= . > >>> > >>> [TR] I may have missed, but did not see any mention in the draft > >>> that the service functions do not modify L7 and only manipulate 2/3/4 > level. > >>> If will be good to explicitly mention that to avoid confusion and > >>> also discuss the implication of L4 manipulations with TCP > >>> authentication in Security considerations section. > >>> > >>> 3. > >>> > >>> b. The packets are from a trusted source. > >>> > >>> c. The packets are from a trusted application. > >>> > >>> Comment> If firewall is white-listing based on destination IP > >>> Comment> address > >>> then the by-pass decision can be made on the SYN packet itself. > >>> > >>> Ramki: Agree that this is a good criterion. As we described in the > >>> draft, the list of criteria is not exhaustive - it is hard to > >>> include every possible case. > >>> > >>> [TR] Okay. > >>> > >>> 4. > >>> > >>> A monitoring element such as a DPI appliance analyzes the new > >>> > >>> flows arriving at the default SecGW device used by a given > >>> eNodeB > >>> > >>> device according to criteria such as: > >>> > >>> Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS > >>> Comment> proxy > >>> and will result in privacy problems. It may also conflict with the > >>> work in other WG like tcpinc with proposals to automatically use TLS > >>> without modifying the application layer protocol. > >>> > >>> Ramki: HTTP/2.0 does not mandate encryption -- > >>> http://http2.github.io/faq/#does-http2-require-encryption. We are > >>> addressing only the non-encrypted case. > >>> > >>> [TR] It may be good to explicitly mention that the use cases deal > >>> with only plain text traffic. > >>> > >>> -Tiru > >>> > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ramki > >>> Krishnan > >>> *Sent:* Thursday, January 22, 2015 10:39 AM > >>> *To:* Jim Guichard (jguichar); sfc@ietf.org > >>> *Subject:* Re: [sfc] WG LC for > >>> draft-ietf-sfc-long-lived-flow-use-cases-01 > >>> > >>> Many thanks for the comments so far; please find an updated version > >>> of the draft addressing them. > >>> > >>> http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-c > >>> as > >>> es/ > >>> > >>> Thanks, > >>> > >>> Ramki > >>> > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > >>> (jguichar) > >>> *Sent:* Monday, December 15, 2014 7:15 AM > >>> *To:* sfc@ietf.org > >>> *Subject:* [sfc] WG LC for > >>> draft-ietf-sfc-long-lived-flow-use-cases-01 > >>> > >>> Dear WG: > >>> > >>> This note begins a 2-week WG LC on > >>> draft-ietf-sfc-long-lived-flow-use-cases.01.txt. > >>> > >>> The document authors have indicated that they have addressed all > >>> known comments and that there are no open issues with the current > >>> version of the document. > >>> > >>> Substantive comments to the list please, editorial comments can go > >>> directly to the document editors. > >>> > >>> Jim & Thomas > >>> > >>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > > From nobody Fri Jan 23 10:38:18 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72851ACDDB for ; Fri, 23 Jan 2015 10:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut4Nlm-P2rqs for ; Fri, 23 Jan 2015 10:37:48 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79FF1A872E for ; Fri, 23 Jan 2015 10:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8324; q=dns/txt; s=iport; t=1422038268; x=1423247868; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=b6wZVBne+d22s/wRg3/6Q6mNWZX+TnN4SyODm+OKWCk=; b=JhH96I4+ufHDh/5xugdaOKm3OTyQKs7dx+GlvZSptDC/ehIPh1Gz84pG 1EUUeXlrbeeu5LIdppO3W83AwNfb3Ko41I21vj1RIivArPUGqoWbin2GA oDoY8orFUmRZJC6fiDzEktaNJrFw1E5CKWvcMHY3wr6QqV6Mgegvci/BU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsFACiUwlStJA2F/2dsb2JhbABagwZSWATEKoIbDIVvAoEXQwEBAQEBfYQMAQEBBAEBATc0FwQCAQgRBAEBAQoUCQcnCxQJCAIEAQkJCIgkDdIDAQEBAQEBAQEBAQEBAQEBAQEBAQEBF48hJjgGgxCBEwWOZoNKhmM2gkiOIyKDbm+BBEF+AQEB X-IronPort-AV: E=Sophos;i="5.09,455,1418083200"; d="scan'208";a="387197284" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP; 23 Jan 2015 18:37:47 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t0NIbkRO030927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 18:37:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 12:37:46 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Joel M. Halpern" , Ramki Krishnan , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQgAFlkJCAACcfAIAADCYwgAEbQQD//6qx4IAAapGA//+qu2A= Date: Fri, 23 Jan 2015 18:37:45 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35530301@xmb-rcd-x10.cisco.com> References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> <54C27592.2050507@joelhalpern.com> <913383AAA69FF945B8F946018B75898A35530207@xmb-rcd-x10.cisco.com> <54C28767.20305@joelhalpern.com> In-Reply-To: <54C28767.20305@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.67.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 18:37:50 -0000 I don't know if the below comment is already discussed (Please ignore if it= is not a concern) The use case in section 4 of http://tools.ietf.org/html/draft-ietf-sfc-long= -lived-flow-use-cases-02#section-4 explains having a DPI appliance in ISP m= ay hit a road block in ISEG review because of privacy problem, there are ot= her possible approaches to solve the problem like Application server inform= ing the mobile network that the flow is critical, this way the use case doe= s not have to depend on DPI or limit to just HTTP and can handle HTTPS traf= fic. =20 -Tiru > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Friday, January 23, 2015 11:10 PM > To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard (jguichar)= ; > sfc@ietf.org > Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 >=20 > I can live with a parenthetical or sentence indicating that the > firewalls we are referring to are those operating at layer 3 or 4. If > you think it is helpful, we could put in an informative reference to the > OPSAWG document. I had not seen that before myself. Thank you for the > pointer. >=20 > Yours, > Joel >=20 > On 1/23/15 12:24 PM, Tirumaleswar Reddy (tireddy) wrote: > > Hi Joel, > > > > Please see inline > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Friday, January 23, 2015 9:54 PM > >> To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard > (jguichar); > >> sfc@ietf.org > >> Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-= 01 > >> > >> Tiru, with regard to the ter firewall, I think the problem is what we = mean > by > >> the word. > >> > >> Unfortunately, there is no industry or IETF standard definition. > >> In my experience, people differentiate between firewall functionality, > >> intrusion detection functionality, and various forms of malware detect= ion > / > >> protection functionality. > >> Some firewall products offer combinations of these features. > >> > >> In our terms, we are discussing functionality, not product. Firewall = is the > >> term that I am familiar with for a device that does statefull or state= less > >> filtering based on the L2, L3, and L4-header portions of the message. > > > > Firewalls also operate at Layer 7, you may refer to the terminology > explained in https://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01 > > > >> > >> Is there another term you would like us to use instead of firewall for= this > kind > >> of functionality? > > > > I guess a note in the draft that the firewall discussed does not operat= e at > Layer 7 would avoid the confusion. > > > > Cheers, > > -Tiru > > > >> > >> Yours, > >> Joel > >> > >> On 1/23/15 1:01 AM, Tirumaleswar Reddy (tireddy) wrote: > >>> Inline [TR] > >>> > >>> *From:*Ramki Krishnan [mailto:ramk@Brocade.com] > >>> *Sent:* Friday, January 23, 2015 10:41 AM > >>> *To:* Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); > >>> sfc@ietf.org > >>> *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > >>> > >>> Hi Tiru, > >>> > >>> Thanks, please find inline. > >>> > >>> Thanks, > >>> > >>> Ramki > >>> > >>> *From:*Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > >>> *Sent:* Thursday, January 22, 2015 8:27 PM > >>> *To:* Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org > >>> > >>> *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 > >>> > >>> Hi Ramki, > >>> > >>> Comments: > >>> > >>> 1. > >>> > >>> A transparent firewall may be able to determine that a long-live= d > >>> > >>> flow (e.g. video stream, file transfer) has no security issues. > >>> > >>> Comment> In the above line you may want to consider removing "file > >>> transfer", FW to inspect files has to act as a L7 proxy and it is not > >>> possible to remove itself from the path after the file transfer is > >>> initiated. > >>> > >>> Ramki: Firewalls do not examine every byte of content. Examining ever= y > >>> byte of content is performed by virus scanner, content scanner etc. > >>> > >>> [TR] Firewalls do have the capability to inspect files to block > >>> viruses, malware etc.. FW acts as a proxy, fetches the complete file > >>> from the server and scans the file. > >>> > >>> 2. > >>> > >>> a. The packets which are encrypted at the application laye= r > >>> > >>> using protocols such as HTTPS [RFC 2660] cannot be > >>> decrypted > >>> > >>> and examined further. > >>> > >>> Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used > >>> for file transfer and Firewall acts as HTTPS proxy then it cannot > >>> by-pass the flow. HTTP/2.0 mandates TLS. > >>> > >>> Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in th= e > >>> event sequence, SFC manipulation happens at the Layer 2/3/4 level. > >>> > >>> [TR] I may have missed, but did not see any mention in the draft that > >>> the service functions do not modify L7 and only manipulate 2/3/4 leve= l. > >>> If will be good to explicitly mention that to avoid confusion and als= o > >>> discuss the implication of L4 manipulations with TCP authentication i= n > >>> Security considerations section. > >>> > >>> 3. > >>> > >>> b. The packets are from a trusted source. > >>> > >>> c. The packets are from a trusted application. > >>> > >>> Comment> If firewall is white-listing based on destination IP address > >>> then the by-pass decision can be made on the SYN packet itself. > >>> > >>> Ramki: Agree that this is a good criterion. As we described in the > >>> draft, the list of criteria is not exhaustive - it is hard to include > >>> every possible case. > >>> > >>> [TR] Okay. > >>> > >>> 4. > >>> > >>> A monitoring element such as a DPI appliance analyzes the new > >>> > >>> flows arriving at the default SecGW device used by a given > >>> eNodeB > >>> > >>> device according to criteria such as: > >>> > >>> Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS > >>> Comment> proxy > >>> and will result in privacy problems. It may also conflict with the > >>> work in other WG like tcpinc with proposals to automatically use TLS > >>> without modifying the application layer protocol. > >>> > >>> Ramki: HTTP/2.0 does not mandate encryption -- > >>> http://http2.github.io/faq/#does-http2-require-encryption. We are > >>> addressing only the non-encrypted case. > >>> > >>> [TR] It may be good to explicitly mention that the use cases deal wit= h > >>> only plain text traffic. > >>> > >>> -Tiru > >>> > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ramki > Krishnan > >>> *Sent:* Thursday, January 22, 2015 10:39 AM > >>> *To:* Jim Guichard (jguichar); sfc@ietf.org > >>> *Subject:* Re: [sfc] WG LC for > >>> draft-ietf-sfc-long-lived-flow-use-cases-01 > >>> > >>> Many thanks for the comments so far; please find an updated version o= f > >>> the draft addressing them. > >>> > >>> http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-ca= s > >>> es/ > >>> > >>> Thanks, > >>> > >>> Ramki > >>> > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > >>> (jguichar) > >>> *Sent:* Monday, December 15, 2014 7:15 AM > >>> *To:* sfc@ietf.org > >>> *Subject:* [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-0= 1 > >>> > >>> Dear WG: > >>> > >>> This note begins a 2-week WG LC on > >>> draft-ietf-sfc-long-lived-flow-use-cases.01.txt. > >>> > >>> The document authors have indicated that they have addressed all > known > >>> comments and that there are no open issues with the current version o= f > >>> the document. > >>> > >>> Substantive comments to the list please, editorial comments can go > >>> directly to the document editors. > >>> > >>> Jim & Thomas > >>> > >>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > > From nobody Fri Jan 23 20:10:43 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225EB1A0081 for ; Fri, 23 Jan 2015 20:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTRgFXCovkzo for ; Fri, 23 Jan 2015 20:10:36 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853581A0033 for ; Fri, 23 Jan 2015 20:10:35 -0800 (PST) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t0O485JV026048; Fri, 23 Jan 2015 20:10:33 -0800 Received: from brmwp-exchub02.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 1s3tuch2qe-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 Jan 2015 20:10:33 -0800 Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 23 Jan 2015 21:10:32 -0700 Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 23 Jan 2015 21:10:31 -0700 Received: from BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9]) by BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9%23]) with mapi id 15.00.1044.021; Fri, 23 Jan 2015 21:10:31 -0700 From: Ramki Krishnan To: "Tirumaleswar Reddy (tireddy)" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQgAFlkJCAACcfAIAADCYwgAF6TWA= Date: Sat, 24 Jan 2015 04:10:30 +0000 Message-ID: <7bb48de0db22413fb6a8dd73158aca13@BRMWP-EXMB11.corp.brocade.com> References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.181.50] Content-Type: multipart/alternative; boundary="_000_7bb48de0db22413fb6a8dd73158aca13BRMWPEXMB11corpbrocadec_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-24_01:2015-01-24,2015-01-23,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-1402240000 definitions=main-1501240031 Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 04:10:41 -0000 --_000_7bb48de0db22413fb6a8dd73158aca13BRMWPEXMB11corpbrocadec_ Content-Type: text/plain; charset="us-ascii" We will add some clarifying text to address 2) and 4). Can you please elaborate on "implication of L4 manipulations with TCP authentication"? 1) has been addressed in the other thread with Joel. Thanks, Ramki From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Thursday, January 22, 2015 10:02 PM To: Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Inline [TR] From: Ramki Krishnan [mailto:ramk@Brocade.com] Sent: Friday, January 23, 2015 10:41 AM To: Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); sfc@ietf.org Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Hi Tiru, Thanks, please find inline. Thanks, Ramki From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Thursday, January 22, 2015 8:27 PM To: Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Hi Ramki, Comments: 1. A transparent firewall may be able to determine that a long-lived flow (e.g. video stream, file transfer) has no security issues. Comment> In the above line you may want to consider removing "file transfer", FW to inspect files has to act as a L7 proxy and it is not possible to remove itself from the path after the file transfer is initiated. Ramki: Firewalls do not examine every byte of content. Examining every byte of content is performed by virus scanner, content scanner etc. [TR] Firewalls do have the capability to inspect files to block viruses, malware etc.. FW acts as a proxy, fetches the complete file from the server and scans the file. 2. a. The packets which are encrypted at the application layer using protocols such as HTTPS [RFC 2660] cannot be decrypted and examined further. Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used for file transfer and Firewall acts as HTTPS proxy then it cannot by-pass the flow. HTTP/2.0 mandates TLS. Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in the event sequence, SFC manipulation happens at the Layer 2/3/4 level. [TR] I may have missed, but did not see any mention in the draft that the service functions do not modify L7 and only manipulate 2/3/4 level. If will be good to explicitly mention that to avoid confusion and also discuss the implication of L4 manipulations with TCP authentication in Security considerations section. 3. b. The packets are from a trusted source. c. The packets are from a trusted application. Comment> If firewall is white-listing based on destination IP address then the by-pass decision can be made on the SYN packet itself. Ramki: Agree that this is a good criterion. As we described in the draft, the list of criteria is not exhaustive - it is hard to include every possible case. [TR] Okay. 4. A monitoring element such as a DPI appliance analyzes the new flows arriving at the default SecGW device used by a given eNodeB device according to criteria such as: Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS proxy and will result in privacy problems. It may also conflict with the work in other WG like tcpinc with proposals to automatically use TLS without modifying the application layer protocol. Ramki: HTTP/2.0 does not mandate encryption -- http://http2.github.io/faq/#does-http2-require-encryption. We are addressing only the non-encrypted case. [TR] It may be good to explicitly mention that the use cases deal with only plain text traffic. -Tiru From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ramki Krishnan Sent: Thursday, January 22, 2015 10:39 AM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Many thanks for the comments so far; please find an updated version of the draft addressing them. http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/ Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Monday, December 15, 2014 7:15 AM To: sfc@ietf.org Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Dear WG: This note begins a 2-week WG LC on draft-ietf-sfc-long-lived-flow-use-cases.01.txt. The document authors have indicated that they have addressed all known comments and that there are no open issues with the current version of the document. Substantive comments to the list please, editorial comments can go directly to the document editors. Jim & Thomas --_000_7bb48de0db22413fb6a8dd73158aca13BRMWPEXMB11corpbrocadec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We will add some clarifying text to a= ddress 2) and 4).

 

Can you please elaborate on “implication of L4 manipulations with TCP authentication= ”?

 

1) has been addressed in the other th= read with Joel.

 

Thanks,

Ramki

 

From: Tirumaleswar Reddy (tireddy) [= mailto:tireddy@cisco.com]
Sent: Thursday, January 22, 2015 10:02 PM
To: Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

 

Inline [TR]

 

From: Ramki Krishnan [mailto:ramk@Brocade.com]
Sent: Friday, January 23, 2015 10:41 AM
To: Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); sfc@ietf.org
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

 

Hi Tiru,

 

Thanks, please find inline.

 

Thanks,

Ramki

 

From: Tirumaleswar Reddy (tireddy) [= mailto:tireddy@cisco.com]
Sent: Thursday, January 22, 2015 8:27 PM
To: Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

 

Hi Ramki,

 

Comments:

 

1.

 

   A transparent firewall may be able t= o determine that a long-lived

   flow (e.g. video stream, file transf= er) has no security issues.

 

Comment>  In the above line you may want = to consider removing “file transfer”, FW to inspect files has t= o act as a L7 proxy and it is not possible to remove itself from the path a= fter the file transfer is initiated.

 

Ramki: Firewalls do= not examine every byte of content. Examining every byte of content is perf= ormed by virus scanner, content scanner etc.

 

[TR] Firewalls do h= ave the capability to inspect files to block viruses, malware etc.. FW acts= as a proxy, fetches the complete file from the server and scans the file.<= o:p>

 

2.

 

        a.&nbs= p; The packets which are encrypted at the application layer

        &= nbsp; using protocols such as HTTPS [RFC 2660] cannot be decrypted

        &= nbsp; and examined further.

 

Comment> Enterprise Firewalls do act as HTTPS = proxy. If HTTPS is used for file transfer and Firewall acts as HTTPS proxy = then it cannot by-pass the flow. HTTP/2.0 mandates TLS.

 

Ramki: HTTPS does n= ot encrypt Layer 2/3/4 headers. As described in the event sequence, SFC man= ipulation happens at the Layer 2/3/4 level.

 

[TR] I may have mis= sed, but did not see any mention in the draft that the service functions do= not modify L7 and only manipulate 2/3/4 level. If will be good to explicit= ly mention that to avoid confusion and also discuss the implication of L4 manipulations with TCP authentication i= n Security considerations section.

 

3.

 

        b.&nbs= p; The packets are from a trusted source.

 

        c.&nbs= p; The packets are from a trusted application.

 

Comment> If firewall is white-listing based on= destination IP address then the by-pass decision can be made on the SYN pa= cket itself.

 

Ramki: Agree that t= his is a good criterion. As we described in the draft, the list of criteria= is not exhaustive – it is hard to include every possible case.<= /o:p>

 

[TR] Okay.

 

4. 

     A monitoring elemen= t such as a DPI appliance analyzes the new

     flows arriving at the de= fault SecGW device used by a given eNodeB

     device according to crit= eria such as:

 

Comment> DPI with HTTP/2.0 will require the IS= P to deploy a HTTPS proxy and will result in privacy problems. It may also = conflict with the work in other WG like tcpinc with proposals to automatica= lly use TLS without modifying the application layer protocol.

 

Ramki: HTTP/2.0 doe= s not mandate encryption -- http:= //http2.github.io/faq/#does-http2-require-encryption. We are addressing= only the non-encrypted case.

 

[TR] It may be good= to explicitly mention that the use cases deal with only plain text traffic= .

 

-Tiru

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ramki Krishnan
Sent: Thursday, January 22, 2015 10:39 AM
To: Jim Guichard (jguichar); sfc@iet= f.org
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-case= s-01

 

Many thanks for the comments so far; = please find an updated version of the draft addressing them.

 

http://datatracker.ietf.or= g/doc/draft-ietf-sfc-long-lived-flow-use-cases/

 

Thanks,

Ramki

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, December 15, 2014 7:15 AM
To: sfc@ietf.org
Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01=

 

Dear WG:

 

This note begins a 2-week WG LC on draf= t-ietf-sfc-long-lived-flow-use-cases.01.txt.

 

The document authors have indicated tha= t they have addressed all known comments and that there are no open issues = with the current version of the document. 

 

Substantive comments to the list please= , editorial comments can go directly to the document editors.

 

Jim & Thomas

--_000_7bb48de0db22413fb6a8dd73158aca13BRMWPEXMB11corpbrocadec_-- From nobody Sun Jan 25 08:57:46 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8873D1A7018 for ; Sun, 25 Jan 2015 08:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpe_AO-QIDJW for ; Sun, 25 Jan 2015 08:57:41 -0800 (PST) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8585D1A700D for ; Sun, 25 Jan 2015 08:57:40 -0800 (PST) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7AE4888076; Sun, 25 Jan 2015 17:57:37 +0100 (CET) Received: from ESTGVMSP112.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 6028E8806E; Sun, 25 Jan 2015 17:57:37 +0100 (CET) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.54) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 25 Jan 2015 17:57:33 +0100 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) with Microsoft SMTP Server (TLS) id 15.1.65.19; Sun, 25 Jan 2015 16:57:35 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0065.013; Sun, 25 Jan 2015 16:57:34 +0000 From: DIEGO LOPEZ GARCIA To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQgAFlkJCAACcfAIAADCYwgAC2rACAABEMgIAABDaAgAAQLYCAAwixAA== Date: Sun, 25 Jan 2015 16:57:34 +0000 Message-ID: <34F216F9-9C07-4F0C-83AF-F9CF1F947FB2@telefonica.com> References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> <54C27592.2050507@joelhalpern.com> <913383AAA69FF945B8F946018B75898A35530207@xmb-rcd-x10.cisco.com> <54C28767.20305@joelhalpern.com> <913383AAA69FF945B8F946018B75898A35530301@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A35530301@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [176.84.211.145] authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=telefonica.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB4PR06MB0624; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0624; x-forefront-prvs: 046753C63C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(66654002)(377454003)(479174004)(252514010)(13464003)(164054003)(24454002)(51914003)(93886004)(230783001)(83716003)(92566002)(82746002)(87936001)(110136001)(122556002)(1720100001)(2950100001)(2900100001)(77156002)(102836002)(86362001)(33656002)(15975445007)(2656002)(62966003)(66066001)(46102003)(50986999)(54356999)(19580405001)(19580395003)(76176999)(106116001)(36756003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0624; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <0319C78802C49F4A9DAA149EFB2CB13A@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2015 16:57:34.8553 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0624 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: Ramki Krishnan , "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 16:57:45 -0000 If I remember well, I suggested to avoid the precise mention to a "DPI" (wh= ich is the kind of word that has become taboo in certain circles) in the te= xt of the draft. A simple mention to "a monitoring device", without going b= eyond in its particular nature or name, should be enough. Be goode, On 23 Jan 2015, at 19:37 , Tirumaleswar Reddy (tireddy) = wrote: > I don't know if the below comment is already discussed (Please ignore if = it is not a concern) > The use case in section 4 of http://tools.ietf.org/html/draft-ietf-sfc-lo= ng-lived-flow-use-cases-02#section-4 explains having a DPI appliance in ISP= may hit a road block in ISEG review because of privacy problem, there are = other possible approaches to solve the problem like Application server info= rming the mobile network that the flow is critical, this way the use case d= oes not have to depend on DPI or limit to just HTTP and can handle HTTPS tr= affic. > > -Tiru > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Friday, January 23, 2015 11:10 PM >> To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard (jguichar= ); >> sfc@ietf.org >> Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 >> >> I can live with a parenthetical or sentence indicating that the >> firewalls we are referring to are those operating at layer 3 or 4. If >> you think it is helpful, we could put in an informative reference to the >> OPSAWG document. I had not seen that before myself. Thank you for the >> pointer. >> >> Yours, >> Joel >> >> On 1/23/15 12:24 PM, Tirumaleswar Reddy (tireddy) wrote: >>> Hi Joel, >>> >>> Please see inline >>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Friday, January 23, 2015 9:54 PM >>>> To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard >> (jguichar); >>>> sfc@ietf.org >>>> Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-= 01 >>>> >>>> Tiru, with regard to the ter firewall, I think the problem is what we = mean >> by >>>> the word. >>>> >>>> Unfortunately, there is no industry or IETF standard definition. >>>> In my experience, people differentiate between firewall functionality, >>>> intrusion detection functionality, and various forms of malware detect= ion >> / >>>> protection functionality. >>>> Some firewall products offer combinations of these features. >>>> >>>> In our terms, we are discussing functionality, not product. Firewall = is the >>>> term that I am familiar with for a device that does statefull or state= less >>>> filtering based on the L2, L3, and L4-header portions of the message. >>> >>> Firewalls also operate at Layer 7, you may refer to the terminology >> explained in https://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01 >>> >>>> >>>> Is there another term you would like us to use instead of firewall for= this >> kind >>>> of functionality? >>> >>> I guess a note in the draft that the firewall discussed does not operat= e at >> Layer 7 would avoid the confusion. >>> >>> Cheers, >>> -Tiru >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 1/23/15 1:01 AM, Tirumaleswar Reddy (tireddy) wrote: >>>>> Inline [TR] >>>>> >>>>> *From:*Ramki Krishnan [mailto:ramk@Brocade.com] >>>>> *Sent:* Friday, January 23, 2015 10:41 AM >>>>> *To:* Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); >>>>> sfc@ietf.org >>>>> *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 >>>>> >>>>> Hi Tiru, >>>>> >>>>> Thanks, please find inline. >>>>> >>>>> Thanks, >>>>> >>>>> Ramki >>>>> >>>>> *From:*Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >>>>> *Sent:* Thursday, January 22, 2015 8:27 PM >>>>> *To:* Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org >>>>> >>>>> *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 >>>>> >>>>> Hi Ramki, >>>>> >>>>> Comments: >>>>> >>>>> 1. >>>>> >>>>> A transparent firewall may be able to determine that a long-lived >>>>> >>>>> flow (e.g. video stream, file transfer) has no security issues. >>>>> >>>>> Comment> In the above line you may want to consider removing "file >>>>> transfer", FW to inspect files has to act as a L7 proxy and it is not >>>>> possible to remove itself from the path after the file transfer is >>>>> initiated. >>>>> >>>>> Ramki: Firewalls do not examine every byte of content. Examining ever= y >>>>> byte of content is performed by virus scanner, content scanner etc. >>>>> >>>>> [TR] Firewalls do have the capability to inspect files to block >>>>> viruses, malware etc.. FW acts as a proxy, fetches the complete file >>>>> from the server and scans the file. >>>>> >>>>> 2. >>>>> >>>>> a. The packets which are encrypted at the application layer >>>>> >>>>> using protocols such as HTTPS [RFC 2660] cannot be >>>>> decrypted >>>>> >>>>> and examined further. >>>>> >>>>> Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used >>>>> for file transfer and Firewall acts as HTTPS proxy then it cannot >>>>> by-pass the flow. HTTP/2.0 mandates TLS. >>>>> >>>>> Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in th= e >>>>> event sequence, SFC manipulation happens at the Layer 2/3/4 level. >>>>> >>>>> [TR] I may have missed, but did not see any mention in the draft that >>>>> the service functions do not modify L7 and only manipulate 2/3/4 leve= l. >>>>> If will be good to explicitly mention that to avoid confusion and als= o >>>>> discuss the implication of L4 manipulations with TCP authentication i= n >>>>> Security considerations section. >>>>> >>>>> 3. >>>>> >>>>> b. The packets are from a trusted source. >>>>> >>>>> c. The packets are from a trusted application. >>>>> >>>>> Comment> If firewall is white-listing based on destination IP address >>>>> then the by-pass decision can be made on the SYN packet itself. >>>>> >>>>> Ramki: Agree that this is a good criterion. As we described in the >>>>> draft, the list of criteria is not exhaustive - it is hard to include >>>>> every possible case. >>>>> >>>>> [TR] Okay. >>>>> >>>>> 4. >>>>> >>>>> A monitoring element such as a DPI appliance analyzes the new >>>>> >>>>> flows arriving at the default SecGW device used by a given >>>>> eNodeB >>>>> >>>>> device according to criteria such as: >>>>> >>>>> Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS >>>>> Comment> proxy >>>>> and will result in privacy problems. It may also conflict with the >>>>> work in other WG like tcpinc with proposals to automatically use TLS >>>>> without modifying the application layer protocol. >>>>> >>>>> Ramki: HTTP/2.0 does not mandate encryption -- >>>>> http://http2.github.io/faq/#does-http2-require-encryption. We are >>>>> addressing only the non-encrypted case. >>>>> >>>>> [TR] It may be good to explicitly mention that the use cases deal wit= h >>>>> only plain text traffic. >>>>> >>>>> -Tiru >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ramki >> Krishnan >>>>> *Sent:* Thursday, January 22, 2015 10:39 AM >>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org >>>>> *Subject:* Re: [sfc] WG LC for >>>>> draft-ietf-sfc-long-lived-flow-use-cases-01 >>>>> >>>>> Many thanks for the comments so far; please find an updated version o= f >>>>> the draft addressing them. >>>>> >>>>> http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-ca= s >>>>> es/ >>>>> >>>>> Thanks, >>>>> >>>>> Ramki >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >>>>> (jguichar) >>>>> *Sent:* Monday, December 15, 2014 7:15 AM >>>>> *To:* sfc@ietf.org >>>>> *Subject:* [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-0= 1 >>>>> >>>>> Dear WG: >>>>> >>>>> This note begins a 2-week WG LC on >>>>> draft-ietf-sfc-long-lived-flow-use-cases.01.txt. >>>>> >>>>> The document authors have indicated that they have addressed all >> known >>>>> comments and that there are no open issues with the current version o= f >>>>> the document. >>>>> >>>>> Substantive comments to the list please, editorial comments can go >>>>> directly to the document editors. >>>>> >>>>> Jim & Thomas >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc -- PLEASE NOTE MY NEW EMAIL ADDRESS "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o From nobody Sun Jan 25 11:19:11 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838F81A0389 for ; Sun, 25 Jan 2015 11:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gfWxT6Q9x98 for ; Sun, 25 Jan 2015 11:19:04 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA481A037C for ; Sun, 25 Jan 2015 11:19:04 -0800 (PST) Received: from pps.filterd (m0048193.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t0PJ1WKd019083; Sun, 25 Jan 2015 11:19:02 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1s4nk11823-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 25 Jan 2015 11:19:02 -0800 Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by HQ1WP-EXCHUB02.corp.brocade.com (10.70.38.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 25 Jan 2015 11:19:01 -0800 Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 25 Jan 2015 12:19:01 -0700 Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Sun, 25 Jan 2015 12:19:00 -0700 Received: from BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9]) by BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9%23]) with mapi id 15.00.1044.021; Sun, 25 Jan 2015 12:19:00 -0700 From: Ramki Krishnan To: DIEGO LOPEZ GARCIA , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQgAFlkJCAACcfAIAADCYwgAEsBQCAABEMgIAABDaAgAAQLYCAAwisAP//sJ+w Date: Sun, 25 Jan 2015 19:19:00 +0000 Message-ID: <4c34c549564e4a538510a8a0d3e96acb@BRMWP-EXMB11.corp.brocade.com> References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> <54C27592.2050507@joelhalpern.com> <913383AAA69FF945B8F946018B75898A35530207@xmb-rcd-x10.cisco.com> <54C28767.20305@joelhalpern.com> <913383AAA69FF945B8F946018B75898A35530301@xmb-rcd-x10.cisco.com> <34F216F9-9C07-4F0C-83AF-F9CF1F947FB2@telefonica.com> In-Reply-To: <34F216F9-9C07-4F0C-83AF-F9CF1F947FB2@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.181.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-25_03:2015-01-24,2015-01-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-1402240000 definitions=main-1501250211 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 19:19:08 -0000 VGhlIGN1cnJlbnQgdGV4dCBmb2N1c3NlcyBvbiBhIG1vbml0b3JpbmcgZGV2aWNlIGFuZCBEUEkg aXMgY2l0ZWQgYXMgYW4gZXhhbXBsZSBvZiBzdWNoIGEgZGV2aWNlLiBXZSBjb3VsZCBjb25zaWRl ciByZW1vdmluZyB0aGUgRFBJIGV4YW1wbGUgdG8gYXZvaWQgdGhpcyBjb25mdXNpb24uDQoNClRo YW5rcywNClJhbWtpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBESUVHTyBM T1BFWiBHQVJDSUEgW21haWx0bzpkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tXSANClNlbnQ6 IFN1bmRheSwgSmFudWFyeSAyNSwgMjAxNSA4OjU4IEFNDQpUbzogVGlydW1hbGVzd2FyIFJlZGR5 ICh0aXJlZGR5KQ0KQ2M6IEpvZWwgTS4gSGFscGVybjsgUmFta2kgS3Jpc2huYW47IEppbSBHdWlj aGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBMQyBm b3IgZHJhZnQtaWV0Zi1zZmMtbG9uZy1saXZlZC1mbG93LXVzZS1jYXNlcy0wMQ0KDQpJZiBJIHJl bWVtYmVyIHdlbGwsIEkgc3VnZ2VzdGVkIHRvIGF2b2lkIHRoZSBwcmVjaXNlIG1lbnRpb24gdG8g YSAiRFBJIiAod2hpY2ggaXMgdGhlIGtpbmQgb2Ygd29yZCB0aGF0IGhhcyBiZWNvbWUgdGFib28g aW4gY2VydGFpbiBjaXJjbGVzKSBpbiB0aGUgdGV4dCBvZiB0aGUgZHJhZnQuIEEgc2ltcGxlIG1l bnRpb24gdG8gImEgbW9uaXRvcmluZyBkZXZpY2UiLCB3aXRob3V0IGdvaW5nIGJleW9uZCBpbiBp dHMgcGFydGljdWxhciBuYXR1cmUgb3IgbmFtZSwgc2hvdWxkIGJlIGVub3VnaC4NCg0KQmUgZ29v ZGUsDQoNCk9uIDIzIEphbiAyMDE1LCBhdCAxOTozNyAsIFRpcnVtYWxlc3dhciBSZWRkeSAodGly ZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPiB3cm90ZToNCg0KPiBJIGRvbid0IGtub3cgaWYgdGhl IGJlbG93IGNvbW1lbnQgaXMgYWxyZWFkeSBkaXNjdXNzZWQgKFBsZWFzZSBpZ25vcmUgDQo+IGlm IGl0IGlzIG5vdCBhIGNvbmNlcm4pIFRoZSB1c2UgY2FzZSBpbiBzZWN0aW9uIDQgb2YgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMtbG9uZy1saXZlZC1mbG93LXVzZS1j YXNlcy0wMiNzZWN0aW9uLTQgZXhwbGFpbnMgaGF2aW5nIGEgRFBJIGFwcGxpYW5jZSBpbiBJU1Ag bWF5IGhpdCBhIHJvYWQgYmxvY2sgaW4gSVNFRyByZXZpZXcgYmVjYXVzZSBvZiBwcml2YWN5IHBy b2JsZW0sIHRoZXJlIGFyZSBvdGhlciBwb3NzaWJsZSBhcHByb2FjaGVzIHRvIHNvbHZlIHRoZSBw cm9ibGVtIGxpa2UgQXBwbGljYXRpb24gc2VydmVyIGluZm9ybWluZyB0aGUgbW9iaWxlIG5ldHdv cmsgdGhhdCB0aGUgZmxvdyBpcyBjcml0aWNhbCwgdGhpcyB3YXkgdGhlIHVzZSBjYXNlIGRvZXMg bm90IGhhdmUgdG8gZGVwZW5kIG9uIERQSSBvciBsaW1pdCB0byBqdXN0IEhUVFAgYW5kIGNhbiBo YW5kbGUgSFRUUFMgdHJhZmZpYy4NCj4NCj4gLVRpcnUNCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tXQ0KPj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDIzLCAyMDE1IDExOjEwIFBNDQo+PiBU bzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgUmFta2kgS3Jpc2huYW47IEppbSBHdWlj aGFyZCANCj4+IChqZ3VpY2hhcik7IHNmY0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzZmNd IFdHIExDIGZvciANCj4+IGRyYWZ0LWlldGYtc2ZjLWxvbmctbGl2ZWQtZmxvdy11c2UtY2FzZXMt MDENCj4+DQo+PiBJIGNhbiBsaXZlIHdpdGggYSBwYXJlbnRoZXRpY2FsIG9yIHNlbnRlbmNlIGlu ZGljYXRpbmcgdGhhdCB0aGUgDQo+PiBmaXJld2FsbHMgd2UgYXJlIHJlZmVycmluZyB0byBhcmUg dGhvc2Ugb3BlcmF0aW5nIGF0IGxheWVyIDMgb3IgNC4gIA0KPj4gSWYgeW91IHRoaW5rIGl0IGlz IGhlbHBmdWwsIHdlIGNvdWxkIHB1dCBpbiBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgDQo+PiB0 byB0aGUgT1BTQVdHIGRvY3VtZW50LiAgSSBoYWQgbm90IHNlZW4gdGhhdCBiZWZvcmUgbXlzZWxm LiAgVGhhbmsgDQo+PiB5b3UgZm9yIHRoZSBwb2ludGVyLg0KPj4NCj4+IFlvdXJzLA0KPj4gSm9l bA0KPj4NCj4+IE9uIDEvMjMvMTUgMTI6MjQgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRk eSkgd3JvdGU6DQo+Pj4gSGkgSm9lbCwNCj4+Pg0KPj4+IFBsZWFzZSBzZWUgaW5saW5lDQo+Pj4N Cj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogSm9lbCBNLiBIYWxw ZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+Pj4gU2VudDogRnJpZGF5LCBKYW51 YXJ5IDIzLCAyMDE1IDk6NTQgUE0NCj4+Pj4gVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRk eSk7IFJhbWtpIEtyaXNobmFuOyBKaW0gR3VpY2hhcmQNCj4+IChqZ3VpY2hhcik7DQo+Pj4+IHNm Y0BpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogW3NmY10gV0cgTEMgZm9yIA0KPj4+PiBkcmFm dC1pZXRmLXNmYy1sb25nLWxpdmVkLWZsb3ctdXNlLWNhc2VzLTAxDQo+Pj4+DQo+Pj4+IFRpcnUs IHdpdGggcmVnYXJkIHRvIHRoZSB0ZXIgZmlyZXdhbGwsIEkgdGhpbmsgdGhlIHByb2JsZW0gaXMg d2hhdCANCj4+Pj4gd2UgbWVhbg0KPj4gYnkNCj4+Pj4gdGhlIHdvcmQuDQo+Pj4+DQo+Pj4+IFVu Zm9ydHVuYXRlbHksIHRoZXJlIGlzIG5vIGluZHVzdHJ5IG9yIElFVEYgc3RhbmRhcmQgZGVmaW5p dGlvbi4NCj4+Pj4gSW4gbXkgZXhwZXJpZW5jZSwgcGVvcGxlIGRpZmZlcmVudGlhdGUgYmV0d2Vl biBmaXJld2FsbCANCj4+Pj4gZnVuY3Rpb25hbGl0eSwgaW50cnVzaW9uIGRldGVjdGlvbiBmdW5j dGlvbmFsaXR5LCBhbmQgdmFyaW91cyBmb3JtcyANCj4+Pj4gb2YgbWFsd2FyZSBkZXRlY3Rpb24N Cj4+IC8NCj4+Pj4gcHJvdGVjdGlvbiBmdW5jdGlvbmFsaXR5Lg0KPj4+PiBTb21lIGZpcmV3YWxs IHByb2R1Y3RzIG9mZmVyIGNvbWJpbmF0aW9ucyBvZiB0aGVzZSBmZWF0dXJlcy4NCj4+Pj4NCj4+ Pj4gSW4gb3VyIHRlcm1zLCB3ZSBhcmUgZGlzY3Vzc2luZyBmdW5jdGlvbmFsaXR5LCBub3QgcHJv ZHVjdC4gIA0KPj4+PiBGaXJld2FsbCBpcyB0aGUgdGVybSB0aGF0IEkgYW0gZmFtaWxpYXIgd2l0 aCBmb3IgYSBkZXZpY2UgdGhhdCBkb2VzIA0KPj4+PiBzdGF0ZWZ1bGwgb3Igc3RhdGVsZXNzIGZp bHRlcmluZyBiYXNlZCBvbiB0aGUgTDIsIEwzLCBhbmQgTDQtaGVhZGVyIHBvcnRpb25zIG9mIHRo ZSBtZXNzYWdlLg0KPj4+DQo+Pj4gRmlyZXdhbGxzIGFsc28gb3BlcmF0ZSBhdCBMYXllciA3LCB5 b3UgbWF5IHJlZmVyIHRvIHRoZSB0ZXJtaW5vbG9neQ0KPj4gZXhwbGFpbmVkIGluIA0KPj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWZpcmV3YWxscy0wMQ0K Pj4+DQo+Pj4+DQo+Pj4+IElzIHRoZXJlIGFub3RoZXIgdGVybSB5b3Ugd291bGQgbGlrZSB1cyB0 byB1c2UgaW5zdGVhZCBvZiBmaXJld2FsbCANCj4+Pj4gZm9yIHRoaXMNCj4+IGtpbmQNCj4+Pj4g b2YgZnVuY3Rpb25hbGl0eT8NCj4+Pg0KPj4+IEkgZ3Vlc3MgYSBub3RlIGluIHRoZSBkcmFmdCB0 aGF0IHRoZSBmaXJld2FsbCBkaXNjdXNzZWQgZG9lcyBub3QgDQo+Pj4gb3BlcmF0ZSBhdA0KPj4g TGF5ZXIgNyB3b3VsZCBhdm9pZCB0aGUgY29uZnVzaW9uLg0KPj4+DQo+Pj4gQ2hlZXJzLA0KPj4+ IC1UaXJ1DQo+Pj4NCj4+Pj4NCj4+Pj4gWW91cnMsDQo+Pj4+IEpvZWwNCj4+Pj4NCj4+Pj4gT24g MS8yMy8xNSAxOjAxIEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIHdyb3RlOg0KPj4+ Pj4gSW5saW5lIFtUUl0NCj4+Pj4+DQo+Pj4+PiAqRnJvbToqUmFta2kgS3Jpc2huYW4gW21haWx0 bzpyYW1rQEJyb2NhZGUuY29tXQ0KPj4+Pj4gKlNlbnQ6KiBGcmlkYXksIEphbnVhcnkgMjMsIDIw MTUgMTA6NDEgQU0NCj4+Pj4+ICpUbzoqIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IEpp bSBHdWljaGFyZCAoamd1aWNoYXIpOyANCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4gKlN1Ympl Y3Q6KiBSRTogV0cgTEMgZm9yIA0KPj4+Pj4gZHJhZnQtaWV0Zi1zZmMtbG9uZy1saXZlZC1mbG93 LXVzZS1jYXNlcy0wMQ0KPj4+Pj4NCj4+Pj4+IEhpIFRpcnUsDQo+Pj4+Pg0KPj4+Pj4gVGhhbmtz LCBwbGVhc2UgZmluZCBpbmxpbmUuDQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzLA0KPj4+Pj4NCj4+Pj4+ IFJhbWtpDQo+Pj4+Pg0KPj4+Pj4gKkZyb206KlRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkg W21haWx0bzp0aXJlZGR5QGNpc2NvLmNvbV0NCj4+Pj4+ICpTZW50OiogVGh1cnNkYXksIEphbnVh cnkgMjIsIDIwMTUgODoyNyBQTQ0KPj4+Pj4gKlRvOiogUmFta2kgS3Jpc2huYW47IEppbSBHdWlj aGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcgDQo+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9y Zz4NCj4+Pj4+ICpTdWJqZWN0OiogUkU6IFdHIExDIGZvciANCj4+Pj4+IGRyYWZ0LWlldGYtc2Zj LWxvbmctbGl2ZWQtZmxvdy11c2UtY2FzZXMtMDENCj4+Pj4+DQo+Pj4+PiBIaSBSYW1raSwNCj4+ Pj4+DQo+Pj4+PiBDb21tZW50czoNCj4+Pj4+DQo+Pj4+PiAxLg0KPj4+Pj4NCj4+Pj4+ICAgICBB IHRyYW5zcGFyZW50IGZpcmV3YWxsIG1heSBiZSBhYmxlIHRvIGRldGVybWluZSB0aGF0IGEgDQo+ Pj4+PiBsb25nLWxpdmVkDQo+Pj4+Pg0KPj4+Pj4gICAgIGZsb3cgKGUuZy4gdmlkZW8gc3RyZWFt LCBmaWxlIHRyYW5zZmVyKSBoYXMgbm8gc2VjdXJpdHkgaXNzdWVzLg0KPj4+Pj4NCj4+Pj4+IENv bW1lbnQ+ICBJbiB0aGUgYWJvdmUgbGluZSB5b3UgbWF5IHdhbnQgdG8gY29uc2lkZXIgcmVtb3Zp bmcgDQo+Pj4+PiBDb21tZW50PiAiZmlsZQ0KPj4+Pj4gdHJhbnNmZXIiLCBGVyB0byBpbnNwZWN0 IGZpbGVzIGhhcyB0byBhY3QgYXMgYSBMNyBwcm94eSBhbmQgaXQgaXMgDQo+Pj4+PiBub3QgcG9z c2libGUgdG8gcmVtb3ZlIGl0c2VsZiBmcm9tIHRoZSBwYXRoIGFmdGVyIHRoZSBmaWxlIA0KPj4+ Pj4gdHJhbnNmZXIgaXMgaW5pdGlhdGVkLg0KPj4+Pj4NCj4+Pj4+IFJhbWtpOiBGaXJld2FsbHMg ZG8gbm90IGV4YW1pbmUgZXZlcnkgYnl0ZSBvZiBjb250ZW50LiBFeGFtaW5pbmcgDQo+Pj4+PiBl dmVyeSBieXRlIG9mIGNvbnRlbnQgaXMgcGVyZm9ybWVkIGJ5IHZpcnVzIHNjYW5uZXIsIGNvbnRl bnQgc2Nhbm5lciBldGMuDQo+Pj4+Pg0KPj4+Pj4gW1RSXSBGaXJld2FsbHMgZG8gaGF2ZSB0aGUg Y2FwYWJpbGl0eSB0byBpbnNwZWN0IGZpbGVzIHRvIGJsb2NrIA0KPj4+Pj4gdmlydXNlcywgbWFs d2FyZSBldGMuLiBGVyBhY3RzIGFzIGEgcHJveHksIGZldGNoZXMgdGhlIGNvbXBsZXRlIA0KPj4+ Pj4gZmlsZSBmcm9tIHRoZSBzZXJ2ZXIgYW5kIHNjYW5zIHRoZSBmaWxlLg0KPj4+Pj4NCj4+Pj4+ IDIuDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgYS4gIFRoZSBwYWNrZXRzIHdoaWNoIGFyZSBlbmNy eXB0ZWQgYXQgdGhlIGFwcGxpY2F0aW9uIA0KPj4+Pj4gbGF5ZXINCj4+Pj4+DQo+Pj4+PiAgICAg ICAgICAgIHVzaW5nIHByb3RvY29scyBzdWNoIGFzIEhUVFBTIFtSRkMgMjY2MF0gY2Fubm90IGJl IA0KPj4+Pj4gZGVjcnlwdGVkDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgICBhbmQgZXhhbWluZWQg ZnVydGhlci4NCj4+Pj4+DQo+Pj4+PiBDb21tZW50PiBFbnRlcnByaXNlIEZpcmV3YWxscyBkbyBh Y3QgYXMgSFRUUFMgcHJveHkuIElmIEhUVFBTIGlzIA0KPj4+Pj4gQ29tbWVudD4gdXNlZA0KPj4+ Pj4gZm9yIGZpbGUgdHJhbnNmZXIgYW5kIEZpcmV3YWxsIGFjdHMgYXMgSFRUUFMgcHJveHkgdGhl biBpdCBjYW5ub3QgDQo+Pj4+PiBieS1wYXNzIHRoZSBmbG93LiBIVFRQLzIuMCBtYW5kYXRlcyBU TFMuDQo+Pj4+Pg0KPj4+Pj4gUmFta2k6IEhUVFBTIGRvZXMgbm90IGVuY3J5cHQgTGF5ZXIgMi8z LzQgaGVhZGVycy4gQXMgZGVzY3JpYmVkIGluIA0KPj4+Pj4gdGhlIGV2ZW50IHNlcXVlbmNlLCBT RkMgbWFuaXB1bGF0aW9uIGhhcHBlbnMgYXQgdGhlIExheWVyIDIvMy80IGxldmVsLg0KPj4+Pj4N Cj4+Pj4+IFtUUl0gSSBtYXkgaGF2ZSBtaXNzZWQsIGJ1dCBkaWQgbm90IHNlZSBhbnkgbWVudGlv biBpbiB0aGUgZHJhZnQgDQo+Pj4+PiB0aGF0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBkbyBub3Qg bW9kaWZ5IEw3IGFuZCBvbmx5IG1hbmlwdWxhdGUgMi8zLzQgbGV2ZWwuDQo+Pj4+PiBJZiB3aWxs IGJlIGdvb2QgdG8gZXhwbGljaXRseSBtZW50aW9uIHRoYXQgdG8gYXZvaWQgY29uZnVzaW9uIGFu ZCANCj4+Pj4+IGFsc28gZGlzY3VzcyB0aGUgaW1wbGljYXRpb24gb2YgTDQgbWFuaXB1bGF0aW9u cyB3aXRoIFRDUCANCj4+Pj4+IGF1dGhlbnRpY2F0aW9uIGluIFNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIHNlY3Rpb24uDQo+Pj4+Pg0KPj4+Pj4gMy4NCj4+Pj4+DQo+Pj4+PiAgICAgICAgICBiLiAg VGhlIHBhY2tldHMgYXJlIGZyb20gYSB0cnVzdGVkIHNvdXJjZS4NCj4+Pj4+DQo+Pj4+PiAgICAg ICAgICBjLiAgVGhlIHBhY2tldHMgYXJlIGZyb20gYSB0cnVzdGVkIGFwcGxpY2F0aW9uLg0KPj4+ Pj4NCj4+Pj4+IENvbW1lbnQ+IElmIGZpcmV3YWxsIGlzIHdoaXRlLWxpc3RpbmcgYmFzZWQgb24g ZGVzdGluYXRpb24gSVAgDQo+Pj4+PiBDb21tZW50PiBhZGRyZXNzDQo+Pj4+PiB0aGVuIHRoZSBi eS1wYXNzIGRlY2lzaW9uIGNhbiBiZSBtYWRlIG9uIHRoZSBTWU4gcGFja2V0IGl0c2VsZi4NCj4+ Pj4+DQo+Pj4+PiBSYW1raTogQWdyZWUgdGhhdCB0aGlzIGlzIGEgZ29vZCBjcml0ZXJpb24uIEFz IHdlIGRlc2NyaWJlZCBpbiB0aGUgDQo+Pj4+PiBkcmFmdCwgdGhlIGxpc3Qgb2YgY3JpdGVyaWEg aXMgbm90IGV4aGF1c3RpdmUgLSBpdCBpcyBoYXJkIHRvIA0KPj4+Pj4gaW5jbHVkZSBldmVyeSBw b3NzaWJsZSBjYXNlLg0KPj4+Pj4NCj4+Pj4+IFtUUl0gT2theS4NCj4+Pj4+DQo+Pj4+PiA0Lg0K Pj4+Pj4NCj4+Pj4+ICAgICAgIEEgbW9uaXRvcmluZyBlbGVtZW50IHN1Y2ggYXMgYSBEUEkgYXBw bGlhbmNlIGFuYWx5emVzIHRoZSANCj4+Pj4+IG5ldw0KPj4+Pj4NCj4+Pj4+ICAgICAgIGZsb3dz IGFycml2aW5nIGF0IHRoZSBkZWZhdWx0IFNlY0dXIGRldmljZSB1c2VkIGJ5IGEgZ2l2ZW4gDQo+ Pj4+PiBlTm9kZUINCj4+Pj4+DQo+Pj4+PiAgICAgICBkZXZpY2UgYWNjb3JkaW5nIHRvIGNyaXRl cmlhIHN1Y2ggYXM6DQo+Pj4+Pg0KPj4+Pj4gQ29tbWVudD4gRFBJIHdpdGggSFRUUC8yLjAgd2ls bCByZXF1aXJlIHRoZSBJU1AgdG8gZGVwbG95IGEgSFRUUFMgDQo+Pj4+PiBDb21tZW50PiBwcm94 eQ0KPj4+Pj4gYW5kIHdpbGwgcmVzdWx0IGluIHByaXZhY3kgcHJvYmxlbXMuIEl0IG1heSBhbHNv IGNvbmZsaWN0IHdpdGggdGhlIA0KPj4+Pj4gd29yayBpbiBvdGhlciBXRyBsaWtlIHRjcGluYyB3 aXRoIHByb3Bvc2FscyB0byBhdXRvbWF0aWNhbGx5IHVzZSANCj4+Pj4+IFRMUyB3aXRob3V0IG1v ZGlmeWluZyB0aGUgYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2wuDQo+Pj4+Pg0KPj4+Pj4gUmFt a2k6IEhUVFAvMi4wIGRvZXMgbm90IG1hbmRhdGUgZW5jcnlwdGlvbiAtLSANCj4+Pj4+IGh0dHA6 Ly9odHRwMi5naXRodWIuaW8vZmFxLyNkb2VzLWh0dHAyLXJlcXVpcmUtZW5jcnlwdGlvbi4gV2Ug YXJlIA0KPj4+Pj4gYWRkcmVzc2luZyBvbmx5IHRoZSBub24tZW5jcnlwdGVkIGNhc2UuDQo+Pj4+ Pg0KPj4+Pj4gW1RSXSBJdCBtYXkgYmUgZ29vZCB0byBleHBsaWNpdGx5IG1lbnRpb24gdGhhdCB0 aGUgdXNlIGNhc2VzIGRlYWwgDQo+Pj4+PiB3aXRoIG9ubHkgcGxhaW4gdGV4dCB0cmFmZmljLg0K Pj4+Pj4NCj4+Pj4+IC1UaXJ1DQo+Pj4+Pg0KPj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpSYW1raQ0KPj4gS3Jpc2huYW4NCj4+Pj4+ ICpTZW50OiogVGh1cnNkYXksIEphbnVhcnkgMjIsIDIwMTUgMTA6MzkgQU0NCj4+Pj4+ICpUbzoq IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQo+Pj4+PiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBXRyBMQyBmb3INCj4+Pj4+IGRyYWZ0LWll dGYtc2ZjLWxvbmctbGl2ZWQtZmxvdy11c2UtY2FzZXMtMDENCj4+Pj4+DQo+Pj4+PiBNYW55IHRo YW5rcyBmb3IgdGhlIGNvbW1lbnRzIHNvIGZhcjsgcGxlYXNlIGZpbmQgYW4gdXBkYXRlZCANCj4+ Pj4+IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGFkZHJlc3NpbmcgdGhlbS4NCj4+Pj4+DQo+Pj4+PiBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLWxvbmctbGl2ZWQt Zmxvdy11c2UNCj4+Pj4+IC1jYXMNCj4+Pj4+IGVzLw0KPj4+Pj4NCj4+Pj4+IFRoYW5rcywNCj4+ Pj4+DQo+Pj4+PiBSYW1raQ0KPj4+Pj4NCj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqSmltIA0KPj4+Pj4gR3VpY2hhcmQNCj4+Pj4+ IChqZ3VpY2hhcikNCj4+Pj4+ICpTZW50OiogTW9uZGF5LCBEZWNlbWJlciAxNSwgMjAxNCA3OjE1 IEFNDQo+Pj4+PiAqVG86KiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+ PiAqU3ViamVjdDoqIFtzZmNdIFdHIExDIGZvciANCj4+Pj4+IGRyYWZ0LWlldGYtc2ZjLWxvbmct bGl2ZWQtZmxvdy11c2UtY2FzZXMtMDENCj4+Pj4+DQo+Pj4+PiBEZWFyIFdHOg0KPj4+Pj4NCj4+ Pj4+IFRoaXMgbm90ZSBiZWdpbnMgYSAyLXdlZWsgV0cgTEMgb24gDQo+Pj4+PiBkcmFmdC1pZXRm LXNmYy1sb25nLWxpdmVkLWZsb3ctdXNlLWNhc2VzLjAxLnR4dC4NCj4+Pj4+DQo+Pj4+PiBUaGUg ZG9jdW1lbnQgYXV0aG9ycyBoYXZlIGluZGljYXRlZCB0aGF0IHRoZXkgaGF2ZSBhZGRyZXNzZWQg YWxsDQo+PiBrbm93bg0KPj4+Pj4gY29tbWVudHMgYW5kIHRoYXQgdGhlcmUgYXJlIG5vIG9wZW4g aXNzdWVzIHdpdGggdGhlIGN1cnJlbnQgDQo+Pj4+PiB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4N Cj4+Pj4+DQo+Pj4+PiBTdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUgbGlzdCBwbGVhc2UsIGVk aXRvcmlhbCBjb21tZW50cyBjYW4gZ28gDQo+Pj4+PiBkaXJlY3RseSB0byB0aGUgZG9jdW1lbnQg ZWRpdG9ycy4NCj4+Pj4+DQo+Pj4+PiBKaW0gJiBUaG9tYXMNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4N Cj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pg0KPj4+DQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5n IGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQoNCi0tDQpQTEVBU0UgTk9URSBNWSBORVcgRU1BSUwgQUREUkVTUw0KIkVzdGEg dmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoN ClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1t YWlsOiBkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0 MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNh amUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0 YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVu Y2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBk ZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBu b3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5 L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1 ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWpl IHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50 ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi4NCg0KVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2Vk IGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2Yg dGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVi eSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWlu ZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQ bGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuDQoNCkVz dGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNl dSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91 IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRh ZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8g aW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYSBsZWl0dXJhLCB1dGlsaXphw6fDo28s IGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHBy b2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0 YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVk aWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6Nv DQo= From nobody Sun Jan 25 19:05:21 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FF31A1BC3; Sun, 25 Jan 2015 19:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wraqs3Tpdci; Sun, 25 Jan 2015 19:05:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35A01A1BCF; Sun, 25 Jan 2015 19:05:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRS61099; Mon, 26 Jan 2015 03:05:14 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 Jan 2015 03:05:13 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 26 Jan 2015 11:05:06 +0800 From: Xuxiaohu To: "huubatwork@gmail.com" , "sfc@ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfA= Date: Mon, 26 Jan 2015 03:05:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com> In-Reply-To: <54C2223A.3080605@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 03:05:19 -0000 SGkgSHV1YiwNCg0KVGhlIGFsdGVyIGxhYmVsIGl0c2VsZiBjb3VsZG7igJl0IG1ha2UgdGhlIHJl Y2VpdmluZyBMU1IgdG8gZGV0ZXJtaW5lIHRoZSBNUExTIHBheWxvYWQgdHlwZSBieSBleGFtaW5p bmcgdGhlIE1QTFMgcGF5bG9hZC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSHV1YiB2YW4gSGVsdm9vcnQgW21haWx0bzpo dXViYXR3b3JrQGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDIzLCAyMDE1IDY6 MjggUE0NCj4gVG86IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBh biBNUExTIHBhY2tldD8NCj4gDQo+IFh1eGlhb2h1IOaCqOWlve+8gQ0KPiANCj4gUGxlYXNlIGNv cnJlY3QgbWUgaWYgSSBhbSB3cm9uZzoNCj4gDQo+IEl0IGhhcyBhbHdheXMgYmVlbiBteSB1bmRl cnN0YW5kaW5nIHRoYXQgdGhlIE1QTFMgaGVhZGVyL2xhYmVsIHdhcw0KPiBpbmRlcGVuZGVudCBv ZiB0aGUgcHJvdG9jb2wvcGF5bG9hZC4NCj4gU28gbm8gaW5kaWNhdGlvbiBvZiB0aGUgYWN0dWFs IHBheWxvYWQgY29udGVudCB3YXMgbmVjZXNzYXJ5Lg0KPiANCj4gSU1ITyB5b3UgY291bGQgdXNl IHRoZSBhbGVydCBsYWJlbCAxIHRvIGluZGljYXRlIHRvIHRoZSBMU1IgdGhhdCBpdCBoYXMgdG8g ZnVydGhlcg0KPiBleGFtaW5lIHRoZSBjb250ZW50IG9mIGEgcGFja2V0Lg0KPiANCj4gUmVnYXJk cywgSHV1Yi4NCj4gDQo+ID09PT09PT09DQo+IA0KPiA+IEl0IHNhaWQgaW4gKGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1zZmMtbnNoLTA0KToNCj4gPg0KPiA+ICAgICBU aGUgc2VydmljZSBoZWFkZXIgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIGVuY2Fwc3VsYXRpb24gdXNl ZCBhbmQgaXMNCj4gPiAgICAgZW5jYXBzdWxhdGVkIGluIGV4aXN0aW5nIHRyYW5zcG9ydHMuICBU aGUgcHJlc2VuY2Ugb2YgTlNIIGlzDQo+ID4gICAgIGluZGljYXRlZCB2aWEgcHJvdG9jb2wgdHlw ZSBvciBvdGhlciBpbmRpY2F0b3IgaW4gdGhlIG91dGVyDQo+ID4gICAgIGVuY2Fwc3VsYXRpb24u DQo+ID4NCj4gPiBJbiB0aGUgY2FzZSB3aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBpcyBh biBNUExTIExTUCwgaG93IHRvIGluZGljYXRlIHRoZQ0KPiBwcmVzZW5jZSBvZiBOU0ggc2luY2Ug dGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBoYXMgbm8gZXhwbGljaXQgcHJvdG9jb2wgaWRlbnRpZmll cg0KPiBmaWVsZCB0byBpbmRpY2F0ZSB0aGUgcHJvdG9jb2wgdHlwZSBvZiB0aGUgTVBMUyBwYXls b2FkPyBTaG91bGQgd2UgbWFrZSBlYWNoDQo+IFNGRiB0byBhbGxvY2F0ZSBhIHVuaXF1ZSBsYWJl bCBmb3IgaW5kaWNhdGluZyB0aGUgcHJlc2VuY2Ugb2YgTlNIPyBPciBzaG91bGQgd2UNCj4gdXNl IHRoZSBjb250cm9sIHdvcmQgdG8gaW5kaWNhdGUgaXQ/IE9yIHNob3VsZCB3ZSByZWNvbnNpZGVy IHRoZSBwb3NzaWJpbGl0eSBvZg0KPiBhZGRpbmcgYW4gZXhwbGljaXQgcHJvdG9jb2wgaWRlbnRp ZmllciBmaWVsZCB0byB0aGUgTVBMUyBlbmNhcHN1bGF0aW9uIHNvIGFzIHRvDQo+IHNvbHZlIHN1 Y2gga2luZCBvZiBpc3N1ZXMgb25jZSBhbmQgZm9yIGFsbD8NCj4gPg0KPiA+IEJlc3QgcmVnYXJk cywNCj4gPiBYaWFvaHUNCj4gPg0KPiANCj4gDQo+IC0tDQo+ICoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gKioqKg0KPiAgICAg ICAgICAgICAgICDor7forrDkvY/vvIzkvaDmmK/ni6zkuIDml6DkuoznmoTvvIzlsLHlg4/lhbbk u5bmr4/kuIDkuKrkurrkuIDmoLcNCg== From nobody Sun Jan 25 22:15:19 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9201A6EEC for ; Sun, 25 Jan 2015 22:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hafZ5JNkY_xB for ; Sun, 25 Jan 2015 22:15:10 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE0B1A1A3C for ; Sun, 25 Jan 2015 22:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27586; q=dns/txt; s=iport; t=1422252910; x=1423462510; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=R4aY9BkEHEqiiC9nQiIRDBPy91m/baOFVtVdePh8Qws=; b=anVi9obqx8lgs7ZLWwYp8KidoPzZtjyxPoiHPGSznIZbrhAUxi/cJdgH +Hz6J6AfG5uT6+0i28RrkpnPP+3gDO3NL1wlnrploTQVmZzpCn0p5qKXu UV00UEsP/+KFjXHZ8yUExO/0QfWt6Irv6oDkQ2+Ko0pmE6aVzMgjjlkjD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3CACI2sVU/49dJa1agkNDUlkEtxmMezyBa4VvAoEPQwEBAQEBfYQMAQEBBC1cAgEIDgMEAQELFgcHMhQJCAIEAQkJCIgkDdIJAQEBAQEBAQEBAQEBAQEBAQEBAQEBF49HNwGDFoETBY0NgWGDS4ZrNoJJjigig25vgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,466,1418083200"; d="scan'208,217";a="390645218" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 26 Jan 2015 06:15:09 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t0Q6F9Ps001857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Jan 2015 06:15:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 26 Jan 2015 00:15:08 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Ramki Krishnan , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Thread-Index: AQHQGHndXfJYaVE90UWBGYMY0p5HlJzL0XeQgAFlkJCAACcfAIAADCYwgAF6TWCAA0by4A== Date: Mon, 26 Jan 2015 06:15:05 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35531C63@xmb-rcd-x10.cisco.com> References: <6db19ce9c26c435d86de16352557c7b2@BRMWP-EXMB11.corp.brocade.com> <913383AAA69FF945B8F946018B75898A3552F98B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552FA60@xmb-rcd-x10.cisco.com> <7bb48de0db22413fb6a8dd73158aca13@BRMWP-EXMB11.corp.brocade.com> In-Reply-To: <7bb48de0db22413fb6a8dd73158aca13@BRMWP-EXMB11.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.57.69] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35531C63xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 06:15:15 -0000 --_000_913383AAA69FF945B8F946018B75898A35531C63xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline [TR] From: Ramki Krishnan [mailto:ramk@Brocade.com] Sent: Saturday, January 24, 2015 9:41 AM To: Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); sfc@ietf.org Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 We will add some clarifying text to address 2) and 4). Can you please elaborate on "implication of L4 manipulations with TCP authe= ntication"? [TR] TCP authentication is used to protect the TCP segment metadata http://= tools.ietf.org/html/rfc5925 (There are discussions going on TCPINC to provi= de transparent security for TCP connections). -Tiru 1) has been addressed in the other thread with Joel. Thanks, Ramki From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Thursday, January 22, 2015 10:02 PM To: Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Inline [TR] From: Ramki Krishnan [mailto:ramk@Brocade.com] Sent: Friday, January 23, 2015 10:41 AM To: Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); sfc@ietf.org Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Hi Tiru, Thanks, please find inline. Thanks, Ramki From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Thursday, January 22, 2015 8:27 PM To: Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Hi Ramki, Comments: 1. A transparent firewall may be able to determine that a long-lived flow (e.g. video stream, file transfer) has no security issues. Comment> In the above line you may want to consider removing "file transfe= r", FW to inspect files has to act as a L7 proxy and it is not possible to = remove itself from the path after the file transfer is initiated. Ramki: Firewalls do not examine every byte of content. Examining every byte= of content is performed by virus scanner, content scanner etc. [TR] Firewalls do have the capability to inspect files to block viruses, ma= lware etc.. FW acts as a proxy, fetches the complete file from the server a= nd scans the file. 2. a. The packets which are encrypted at the application layer using protocols such as HTTPS [RFC 2660] cannot be decrypted and examined further. Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used for f= ile transfer and Firewall acts as HTTPS proxy then it cannot by-pass the fl= ow. HTTP/2.0 mandates TLS. Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in the even= t sequence, SFC manipulation happens at the Layer 2/3/4 level. [TR] I may have missed, but did not see any mention in the draft that the s= ervice functions do not modify L7 and only manipulate 2/3/4 level. If will = be good to explicitly mention that to avoid confusion and also discuss the = implication of L4 manipulations with TCP authentication in Security conside= rations section. 3. b. The packets are from a trusted source. c. The packets are from a trusted application. Comment> If firewall is white-listing based on destination IP address then = the by-pass decision can be made on the SYN packet itself. Ramki: Agree that this is a good criterion. As we described in the draft, t= he list of criteria is not exhaustive - it is hard to include every possibl= e case. [TR] Okay. 4. A monitoring element such as a DPI appliance analyzes the new flows arriving at the default SecGW device used by a given eNodeB device according to criteria such as: Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS proxy and= will result in privacy problems. It may also conflict with the work in oth= er WG like tcpinc with proposals to automatically use TLS without modifying= the application layer protocol. Ramki: HTTP/2.0 does not mandate encryption -- http://http2.github.io/faq/#= does-http2-require-encryption. We are addressing only the non-encrypted cas= e. [TR] It may be good to explicitly mention that the use cases deal with only= plain text traffic. -Tiru From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ramki Krishnan Sent: Thursday, January 22, 2015 10:39 AM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Many thanks for the comments so far; please find an updated version of the = draft addressing them. http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/ Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, December 15, 2014 7:15 AM To: sfc@ietf.org Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01 Dear WG: This note begins a 2-week WG LC on draft-ietf-sfc-long-lived-flow-use-cases= .01.txt. The document authors have indicated that they have addressed all known comm= ents and that there are no open issues with the current version of the docu= ment. Substantive comments to the list please, editorial comments can go directly= to the document editors. Jim & Thomas --_000_913383AAA69FF945B8F946018B75898A35531C63xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Inline [TR]

 <= /p>

From: Ramki Kr= ishnan [mailto:ramk@Brocade.com]
Sent: Saturday, January 24, 2015 9:41 AM
To: Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); sfc@ietf.= org
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

 

We will add some clarifyi= ng text to address 2) and 4).

 <= /p>

Can you please elaborate = on “implication of L4 manipulations with TCP authentication”?

 <= /p>

[TR] TCP authentication i= s used to protect the TCP segment metadata http://tools.ietf.org/html/r= fc5925 (There are discussions going on TCPINC to provide transparent se= curity for TCP connections).

 <= /p>

-Tiru

 <= /p>

1) has been addressed in = the other thread with Joel.

 <= /p>

Thanks,=

Ramki

 <= /p>

From: Tiruma= leswar Reddy (tireddy) [mailto:tireddy= @cisco.com]
Sent: Thursday, January 22, 2015 10:02 PM
To: Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

 

Inline [TR]

 <= /p>

From: Ramki Kr= ishnan [mailto:ramk@Brocade.com]
Sent: Friday, January 23, 2015 10:41 AM
To: Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); sfc@ietf.org
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

 

Hi Tiru,

 <= /p>

Thanks, please find inlin= e.

 <= /p>

Thanks,=

Ramki

 <= /p>

From: Tiruma= leswar Reddy (tireddy) [mailto:tireddy= @cisco.com]
Sent: Thursday, January 22, 2015 8:27 PM
To: Ramki Krishnan; Jim Guichard (jguichar); sfc@ietf.org
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

 

Hi Ramki,

 

Comments:

 

1.

 

   A transparent firewall may be able t= o determine that a long-lived

   flow (e.g. video stream, file transf= er) has no security issues.

 

Comment>  In the above line you may want = to consider removing “file transfer”, FW to inspect files has t= o act as a L7 proxy and it is not possible to remove itself from the path a= fter the file transfer is initiated.

 

Ramki: Firewalls do= not examine every byte of content. Examining every byte of content is perf= ormed by virus scanner, content scanner etc.

 

[TR] Firewalls do h= ave the capability to inspect files to block viruses, malware etc.. FW acts= as a proxy, fetches the complete file from the server and scans the file.<= o:p>

 

2.

 

        a.&nbs= p; The packets which are encrypted at the application layer

        &= nbsp; using protocols such as HTTPS [RFC 2660] cannot be decrypted

        &= nbsp; and examined further.

 

Comment> Enterprise Firewalls do act as HTTPS = proxy. If HTTPS is used for file transfer and Firewall acts as HTTPS proxy = then it cannot by-pass the flow. HTTP/2.0 mandates TLS.

 

Ramki: HTTPS does n= ot encrypt Layer 2/3/4 headers. As described in the event sequence, SFC man= ipulation happens at the Layer 2/3/4 level.

 

[TR] I may have mis= sed, but did not see any mention in the draft that the service functions do= not modify L7 and only manipulate 2/3/4 level. If will be good to explicit= ly mention that to avoid confusion and also discuss the implication of L4 manipulations with TCP authentication i= n Security considerations section.

 

3.

 

        b.&nbs= p; The packets are from a trusted source.

 

        c.&nbs= p; The packets are from a trusted application.

 

Comment> If firewall is white-listing based on= destination IP address then the by-pass decision can be made on the SYN pa= cket itself.

 

Ramki: Agree that t= his is a good criterion. As we described in the draft, the list of criteria= is not exhaustive – it is hard to include every possible case.<= /o:p>

 

[TR] Okay.

 

4. 

     A monitoring elemen= t such as a DPI appliance analyzes the new

     flows arriving at the de= fault SecGW device used by a given eNodeB

     device according to crit= eria such as:

 

Comment> DPI with HTTP/2.0 will require the IS= P to deploy a HTTPS proxy and will result in privacy problems. It may also = conflict with the work in other WG like tcpinc with proposals to automatica= lly use TLS without modifying the application layer protocol.

 

Ramki: HTTP/2.0 doe= s not mandate encryption -- http:= //http2.github.io/faq/#does-http2-require-encryption. We are addressing= only the non-encrypted case.

 

[TR] It may be good= to explicitly mention that the use cases deal with only plain text traffic= .

 

-Tiru

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ramki Krishnan
Sent: Thursday, January 22, 2015 10:39 AM
To: Jim Guichard (jguichar); sfc@iet= f.org
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-case= s-01

 

Many thanks for the comme= nts so far; please find an updated version of the draft addressing them.

 <= /p>

http://datatra= cker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/<= /span>

 <= /p>

Thanks,=

Ramki

 <= /p>

From: sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, December 15, 2014 7:15 AM
To: sfc@ietf.org
Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01=

 

Dear WG:<= /p>

 

This note begins a 2-week W= G LC on draft-ietf-sfc-long-lived-flow-use-cases.01.txt.<= /p>

 

The document authors have i= ndicated that they have addressed all known comments and that there are no = open issues with the current version of the document. 

 

Substantive comments to the= list please, editorial comments can go directly to the document editors.

 

Jim & Thomas=

--_000_913383AAA69FF945B8F946018B75898A35531C63xmbrcdx10ciscoc_-- From nobody Mon Jan 26 00:50:54 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEB71A87E1 for ; Mon, 26 Jan 2015 00:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkHkWT7vP0Lq for ; Mon, 26 Jan 2015 00:50:48 -0800 (PST) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AB31A87DB for ; Mon, 26 Jan 2015 00:50:47 -0800 (PST) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 74F8188127 for ; Mon, 26 Jan 2015 09:50:45 +0100 (CET) Received: from ESTGVMSP104.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 55F9988125 for ; Mon, 26 Jan 2015 09:50:45 +0100 (CET) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.50) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 26 Jan 2015 09:50:40 +0100 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0623.eurprd06.prod.outlook.com (25.161.13.141) with Microsoft SMTP Server (TLS) id 15.1.65.19; Mon, 26 Jan 2015 08:50:42 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0065.013; Mon, 26 Jan 2015 08:50:42 +0000 From: DIEGO LOPEZ GARCIA To: "sfc@ietf.org" Thread-Topic: [sfc] SFC Requirement draft Thread-Index: AQHQNu8fMJC/9p8Bx0qDA84K/aE5aZzSHHdk Date: Mon, 26 Jan 2015 08:50:42 +0000 Message-ID: <27631560-E85F-41B4-9354-3EFDF280157A@telefonica.com> References: <54C21423.1080309@lab.ntt.co.jp> In-Reply-To: <54C21423.1080309@lab.ntt.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [176.83.94.35] authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=telefonica.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB4PR06MB0623; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0623; x-forefront-prvs: 0468FE4A2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(53754006)(24454002)(2501002)(83716003)(92566002)(2656002)(87936001)(106116001)(122556002)(19580405001)(46102003)(66066001)(36756003)(82746002)(50986999)(19580395003)(40100003)(102836002)(15975445007)(76176999)(54356999)(2900100001)(2950100001)(33656002)(86362001)(450100001)(62966003)(77156002)(110136001)(107886001)(2351001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0623; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2015 08:50:42.8059 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0623 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Subject: Re: [sfc] SFC Requirement draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 08:50:52 -0000 I tend to agree with Kengo on this and would like to see this work on requi= rements continuing Be goode, -- Likely to be brief and not very elaborate as sent from my mobile Diego R. Lopez Telefonica I+D > On 23 Jan 2015, at 10:29, Kengo Naito wrote: > > Hi all, > > Draft-boucadair-sfc-requirements-05 has been expired, but I would like to= ask WG again, that do we really should leave this expired or not. > > http://www.ietf.org/archive/id/draft-boucadair-sfc-requirements-05.txt > > I believe the documentation of requirements is helpful to keep useful dis= cussion about sfc, as we can refer at anytime "what we really require". > Please send any opinion to the mailing list. > > Best regards, > Kengo > > -- > ---------------------------------------- > NTT Network Technology Laboratories > Kengo Naito > E-Mail:naito.kengo@lab.ntt.co.jp > TEL: +81 422-59-4949 > ---------------------------------------- > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o From nobody Mon Jan 26 02:21:12 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E340E1A88B8 for ; Mon, 26 Jan 2015 02:21:10 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WddUGb9gv3yB for ; Mon, 26 Jan 2015 02:21:06 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F631A88B2 for ; Mon, 26 Jan 2015 02:21:06 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id l15so8784978wiw.4 for ; Mon, 26 Jan 2015 02:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SUI21cPT92rQU9osf0/IHXhSblAZbqFZ8YQdqjPSpqY=; b=iEcn36FdDWZW5pLj2K4QbI/fiJlGlTMPi0jp9JuCR/rDwRVI5/rmWfuWPRSKNFwLz0 AwMEslGHvOOtAamn0yAlDyhUChftn4Rm8kGGjCczCDtjguFDT/9pvq+zjbszCSfF0Hfg TY16qg1prt5odnJJICGrfQS2eU3VmjZkkfFh2nbw35LR/3784xn1Zq7vPT3fnk5lMrQS FSH4+Jdt3tFQIAxBYsdhwN23+TNSKUNdEcT/+xuvCppSjQ0T4W4Qp+RnnpJv7QRhsRZR 1q0T1441rEOilp95yJzGhz5ys51jqtSDfRlGAjFGbJyqF1n0rni0k94LG82zrhHPdyxN mV4w== MIME-Version: 1.0 X-Received: by 10.180.212.113 with SMTP id nj17mr25762643wic.54.1422267664753; Mon, 26 Jan 2015 02:21:04 -0800 (PST) Received: by 10.194.236.106 with HTTP; Mon, 26 Jan 2015 02:21:04 -0800 (PST) In-Reply-To: <27631560-E85F-41B4-9354-3EFDF280157A@telefonica.com> References: <54C21423.1080309@lab.ntt.co.jp> <27631560-E85F-41B4-9354-3EFDF280157A@telefonica.com> Date: Mon, 26 Jan 2015 11:21:04 +0100 Message-ID: From: Daniel Migault To: DIEGO LOPEZ GARCIA Content-Type: multipart/alternative; boundary=001a11c24054eee8ce050d8b7ee9 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC Requirement draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 10:21:11 -0000 --001a11c24054eee8ce050d8b7ee9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi I agree with Diego. The document is helpful for discussions. I would to elaborate on the security requirements (when time permits). BR, Daniel On Mon, Jan 26, 2015 at 9:50 AM, DIEGO LOPEZ GARCIA < diego.r.lopez@telefonica.com> wrote: > I tend to agree with Kengo on this and would like to see this work on > requirements continuing > > Be goode, > > -- > Likely to be brief and not very > elaborate as sent from my mobile > Diego R. Lopez > Telefonica I+D > > > > On 23 Jan 2015, at 10:29, Kengo Naito wrote= : > > > > Hi all, > > > > Draft-boucadair-sfc-requirements-05 has been expired, but I would like > to ask WG again, that do we really should leave this expired or not. > > > > http://www.ietf.org/archive/id/draft-boucadair-sfc-requirements-05.txt > > > > I believe the documentation of requirements is helpful to keep useful > discussion about sfc, as we can refer at anytime "what we really require= ". > > Please send any opinion to the mailing list. > > > > Best regards, > > Kengo > > > > -- > > ---------------------------------------- > > NTT Network Technology Laboratories > > Kengo Naito > > E-Mail:naito.kengo@lab.ntt.co.jp > > TEL: +81 422-59-4949 > > ---------------------------------------- > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener informaci=C3=B3n privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilizaci=C3= =B3n, > divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en= virtud de > la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le ro= gamos > que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a s= u > destrucci=C3=B3n. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution o= r > copying of this communication is strictly prohibited. If you have receive= d > this transmission in error, do not read it. Please immediately reply to t= he > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3= =A1rio, > pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 pa= ra uso exclusivo > da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa senhoria o des= tinat=C3=A1rio > indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga= =C3=A7=C3=A3o e/ou > c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da le= gisla=C3=A7=C3=A3o vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --=20 Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --001a11c24054eee8ce050d8b7ee9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

I agree with Diego. The document is helpfu= l for discussions. I would to elaborate on the security requirements (when = time permits).

BR,
Daniel

On Mon, Jan 26, 2015 at 9:50 AM, DIEGO = LOPEZ GARCIA <diego.r.lopez@telefonica.com> wrote= :
I tend to agree with Kengo on this and = would like to see this work on requirements continuing

Be goode,

--
Likely to be brief and not very
elaborate as sent from my mobile
Diego R. Lopez
Telefonica I+D


> On 23 Jan 2015, at 10:29, Kengo Naito <naito.kengo@lab.ntt.co.jp> wrote:
>
> Hi all,
>
> Draft-boucadair-sfc-requirements-05 has been expired, but I would like= to ask WG again, that do we really should leave this expired or not.
>
> http://www.ietf.org/archive/id/draft-boucada= ir-sfc-requirements-05.txt
>
> I believe the documentation of requirements is helpful to keep useful = discussion about sfc, as we can refer=C2=A0 at anytime "what we really= require".
> Please send any opinion to the mailing list.
>
> Best regards,
> Kengo
>
> --
> ----------------------------------------
> NTT Network Technology Laboratories
> Kengo Naito
> E-Mail:naito.ken= go@lab.ntt.co.jp
> TEL: +81 42= 2-59-4949
> ----------------------------------------
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o

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



--
Daniel Migault
Orange Labs -- Security
+33 6 70 = 72 69 58
--001a11c24054eee8ce050d8b7ee9-- From nobody Mon Jan 26 08:02:21 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62031A1EFF; Sun, 25 Jan 2015 22:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.491 X-Spam-Level: *** X-Spam-Status: No, score=3.491 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 874g-nPuy0NF; Sun, 25 Jan 2015 22:34:26 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232B61A1BD7; Sun, 25 Jan 2015 22:34:26 -0800 (PST) Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0809.eurprd03.prod.outlook.com (25.161.55.141) with Microsoft SMTP Server (TLS) id 15.1.59.20; Mon, 26 Jan 2015 06:21:33 +0000 Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0065.013; Mon, 26 Jan 2015 06:21:32 +0000 From: Alexander Vainshtein To: Xuxiaohu , "huubatwork@gmail.com" Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegARJH4AAIdmfAAABiq6Fg== Date: Mon, 26 Jan 2015 06:21:32 +0000 Message-ID: <1422253291241.41262@ecitele.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [5.153.9.206] authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ecitele.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR03MB0809; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0809; x-forefront-prvs: 0468FE4A2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(46102003)(76176999)(40100003)(62966003)(2501002)(77156002)(2950100001)(2900100001)(50986999)(92566002)(87936001)(122556002)(86362001)(2656002)(117636001)(102836002)(19580405001)(19580395003)(54356999)(36756003)(66066001)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0809; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2015 06:21:32.4767 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0809 Archived-At: X-Mailman-Approved-At: Mon, 26 Jan 2015 08:02:19 -0800 Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 06:34:28 -0000 WGlhb2h1LCBIdXViLApJIGRvIG5vdCBmb2xsb3cgdGhlIFNGQyB3b3JrIGNsb3NlbHksIHNvIEkg d291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHdoZXRoZXIgdGhlIE5TSCBzaG91bGQgYmUgY2FwdHVy ZWQgYnkgIHRyYW5zaXQgTFNScyBvbiB0aGUgTFNQIC0gb3IganVzdCBieSB0aGUgTEVSIGFjdGlu ZyBhcyB0aGUgTFNQIHRhaWwtZW5kPwoKSWYgdGhlIGxhdHRlciBpcyBjb3JyZWN0LCB0aGUgc2lt cGxlc3Qgd2F5IHRvIGluZGljYXRlIHByZXNlbmNlIG9mIHRoZSBOU0ggaW4gdGhlIE1QTFMgcGF5 bG9hZCB3b3VsZCBiZSBieSBhbGxvY2F0aW5nIGFuICJhcHBsaWNhdGlvbiBsYWJlbCIgaW5kaWNh dGluZyBpdHMgcHJlc2VuY2UgYnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5zZXJ0aW5nIGl0 IGF0IHRoZSBib3R0b20gb2YgdGhlIGxhYmVsIHN0YWNrIGJ5IHRoZSBoZWFkLWVuZCBMRVIgLSBz aW1pbGFyIHRvIHdoYXQgaXMgZG9uZSBmb3IgTDIvTDNWUE4uICBXaXRoaW4gdGhpcyBhcHByb2Fj aCwgaWYgbGFiZWwtYmFzZWQgZGVtdWx0aXBsZXhpbmcgb2YgIHBhY2tldHMgd2l0aCBOU0ggaW4g dGhlIE1QTFMgcGF5bG9hZCBpcyBub3QgcmVxdWlyZWQsIHlvdSBjb3VsZCByZXF1ZXN0IGFsbG9j YXRpb24gb2YgYSBuZXcgc3BlY2lhbCBwdXJwb3NlIGxhYmVsIGZyb20gdGhlIGV4dGVuZGVkIHNw ZWNpYWwgcHVycG9zZXMgbGFiZWwgc3BhY2UgYXMgcGVyIFJGQyA3Mjc0LCBhbmQgdG8gaW5zZXJ0 IHN1Y2ggYSBsYWJlbCAocHJlY2VkZWQgYnkgdGhlIEV4dGVuc2lvbiBMYWJlbCApIGF0IHRoZSBC b1MuCgpJZiB0aGUgZm9ybWVyIGlzIGNvcnJlY3QsIHRoZSBwcm9jZXNzIGFib3ZlIHN0aWxsIGhh cyB0byBiZSB1c2VkIGJ1dCBpdCBoYXMgdG8gYmUgYXVnbWVudGVkIGJ5IGFkZGluZyB0aGUgUm91 dGVyIEFsZXJ0IExhYmVsICAgYXQgdGhlIHRvcCBvZiB0aGUgbGFiZWwgc3RhY2suCgpGcm9tIG15 IFBPViB0aGVzZSBzdWdnZXN0aW9ucyBhcmUgaW4gbGluZSB3aXRoIHRoZSBwcm92aXNpb25zIG9m IFNlY3Rpb24gMi4yIG9mIFJGQyAzMDMyICJEZXRlcm1pbmluZyB0aGUgTmV0d29yayBMYXllciBQ cm90b2NvbCIgdGhhdCBzdGF0ZXM6Cgo8cXVvdGU+CiAgIFdoZW4gdGhlIGxhc3QgbGFiZWwgaXMg cG9wcGVkIGZyb20gYSBwYWNrZXQncyBsYWJlbCBzdGFjayAocmVzdWx0aW5nCiAgIGluIHRoZSBz dGFjayBiZWluZyBlbXB0aWVkKSwgZnVydGhlciBwcm9jZXNzaW5nIG9mIHRoZSBwYWNrZXQgaXMK ICAgYmFzZWQgb24gdGhlIHBhY2tldCdzIG5ldHdvcmsgbGF5ZXIgaGVhZGVyLiAgVGhlIExTUiB3 aGljaCBwb3BzIHRoZQogICBsYXN0IGxhYmVsIG9mZiB0aGUgc3RhY2sgbXVzdCB0aGVyZWZvcmUg YmUgYWJsZSB0byBpZGVudGlmeSB0aGUKICAgcGFja2V0J3MgbmV0d29yayBsYXllciBwcm90b2Nv bC4gIEhvd2V2ZXIsIHRoZSBsYWJlbCBzdGFjayBkb2VzIG5vdAogICBjb250YWluIGFueSBmaWVs ZCB3aGljaCBleHBsaWNpdGx5IGlkZW50aWZpZXMgdGhlIG5ldHdvcmsgbGF5ZXIKICAgcHJvdG9j b2wuICBUaGlzIG1lYW5zIHRoYXQgdGhlIGlkZW50aXR5IG9mIHRoZSBuZXR3b3JrIGxheWVyIHBy b3RvY29sCiAgIG11c3QgYmUgaW5mZXJhYmxlIGZyb20gdGhlIHZhbHVlIG9mIHRoZSBsYWJlbCB3 aGljaCBpcyBwb3BwZWQgZnJvbQogICB0aGUgYm90dG9tIG9mIHRoZSBzdGFjaywgcG9zc2libHkg YWxvbmcgd2l0aCB0aGUgY29udGVudHMgb2YgdGhlCiAgIG5ldHdvcmsgbGF5ZXIgaGVhZGVyIGl0 c2VsZi4KPGVuZCBxdW90ZT4KCk15IDJjLApTYXNoYQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCkZyb206IG1wbHMgPG1wbHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVo YWxmIG9mIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPgpTZW50OiBNb25kYXksIEphbnVh cnkgMjYsIDIwMTUgNTowNSBBTQpUbzogaHV1YmF0d29ya0BnbWFpbC5jb207IHNmY0BpZXRmLm9y ZzsgbXBsc0BpZXRmLm9yZwpTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0ZSB0aGUg cHJlc2VuY2Ugb2YgTlNIIGluIGFuIE1QTFMgcGFja2V0PwoKSGkgSHV1YiwKClRoZSBhbHRlciBs YWJlbCBpdHNlbGYgY291bGRuoa90IG1ha2UgdGhlIHJlY2VpdmluZyBMU1IgdG8gZGV0ZXJtaW5l IHRoZSBNUExTIHBheWxvYWQgdHlwZSBieSBleGFtaW5pbmcgdGhlIE1QTFMgcGF5bG9hZC4KCkJl c3QgcmVnYXJkcywKWGlhb2h1Cgo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTog SHV1YiB2YW4gSGVsdm9vcnQgW21haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbV0KPiBTZW50OiBG cmlkYXksIEphbnVhcnkgMjMsIDIwMTUgNjoyOCBQTQo+IFRvOiBYdXhpYW9odTsgc2ZjQGlldGYu b3JnOyBtcGxzQGlldGYub3JnCj4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUg dGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTIHBhY2tldD8KPgo+IFh1eGlhb2h1IMT6usOj oQo+Cj4gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZzoKPgo+IEl0IGhhcyBhbHdheXMg YmVlbiBteSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIE1QTFMgaGVhZGVyL2xhYmVsIHdhcwo+IGlu ZGVwZW5kZW50IG9mIHRoZSBwcm90b2NvbC9wYXlsb2FkLgo+IFNvIG5vIGluZGljYXRpb24gb2Yg dGhlIGFjdHVhbCBwYXlsb2FkIGNvbnRlbnQgd2FzIG5lY2Vzc2FyeS4KPgo+IElNSE8geW91IGNv dWxkIHVzZSB0aGUgYWxlcnQgbGFiZWwgMSB0byBpbmRpY2F0ZSB0byB0aGUgTFNSIHRoYXQgaXQg aGFzIHRvIGZ1cnRoZXIKPiBleGFtaW5lIHRoZSBjb250ZW50IG9mIGEgcGFja2V0Lgo+Cj4gUmVn YXJkcywgSHV1Yi4KPgo+ID09PT09PT09Cj4KPiA+IEl0IHNhaWQgaW4gKGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1zZmMtbnNoLTA0KToKPiA+Cj4gPiAgICAgVGhlIHNl cnZpY2UgaGVhZGVyIGlzIGluZGVwZW5kZW50IG9mIHRoZSBlbmNhcHN1bGF0aW9uIHVzZWQgYW5k IGlzCj4gPiAgICAgZW5jYXBzdWxhdGVkIGluIGV4aXN0aW5nIHRyYW5zcG9ydHMuICBUaGUgcHJl c2VuY2Ugb2YgTlNIIGlzCj4gPiAgICAgaW5kaWNhdGVkIHZpYSBwcm90b2NvbCB0eXBlIG9yIG90 aGVyIGluZGljYXRvciBpbiB0aGUgb3V0ZXIKPiA+ICAgICBlbmNhcHN1bGF0aW9uLgo+ID4KPiA+ IEluIHRoZSBjYXNlIHdoZXJlIHRoZSBvdXRlciBlbmNhcHN1bGF0aW9uIGlzIGFuIE1QTFMgTFNQ LCBob3cgdG8gaW5kaWNhdGUgdGhlCj4gcHJlc2VuY2Ugb2YgTlNIIHNpbmNlIHRoZSBNUExTIGVu Y2Fwc3VsYXRpb24gaGFzIG5vIGV4cGxpY2l0IHByb3RvY29sIGlkZW50aWZpZXIKPiBmaWVsZCB0 byBpbmRpY2F0ZSB0aGUgcHJvdG9jb2wgdHlwZSBvZiB0aGUgTVBMUyBwYXlsb2FkPyBTaG91bGQg d2UgbWFrZSBlYWNoCj4gU0ZGIHRvIGFsbG9jYXRlIGEgdW5pcXVlIGxhYmVsIGZvciBpbmRpY2F0 aW5nIHRoZSBwcmVzZW5jZSBvZiBOU0g/IE9yIHNob3VsZCB3ZQo+IHVzZSB0aGUgY29udHJvbCB3 b3JkIHRvIGluZGljYXRlIGl0PyBPciBzaG91bGQgd2UgcmVjb25zaWRlciB0aGUgcG9zc2liaWxp dHkgb2YKPiBhZGRpbmcgYW4gZXhwbGljaXQgcHJvdG9jb2wgaWRlbnRpZmllciBmaWVsZCB0byB0 aGUgTVBMUyBlbmNhcHN1bGF0aW9uIHNvIGFzIHRvCj4gc29sdmUgc3VjaCBraW5kIG9mIGlzc3Vl cyBvbmNlIGFuZCBmb3IgYWxsPwo+ID4KPiA+IEJlc3QgcmVnYXJkcywKPiA+IFhpYW9odQo+ID4K Pgo+Cj4gLS0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqCj4gKioqKgo+ICAgICAgICAgICAgICAgIMfrvMfXoaOsxOPKx7bA0rvO 3rb+tcSjrL7Nz/HG5Mv7w7/Su7j2yMvSu9H5Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCm1wbHMgbWFpbGluZyBsaXN0Cm1wbHNAaWV0Zi5vcmcKaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzCg== From nobody Mon Jan 26 09:16:48 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11341ACD07 for ; Mon, 26 Jan 2015 09:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdO7XnM2sfGH for ; Mon, 26 Jan 2015 09:16:41 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id B4DE61ACCFA for ; Mon, 26 Jan 2015 09:16:33 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Mon, 26 Jan 2015 12:16:32 -0500 From: Dave Dolson To: "'sfc@ietf.org'" , "walter.haeffner@vodafone.com" , "jenapper@cisco.com" , "mls.ietf@gmail.com" , "diego@tid.es" , "uttaro@att.com" Thread-Topic: Mobile use cases draft-ietf-sfc-use-case-mobility-03 Thread-Index: AdA5i9PHaEFtXImRQvatdBwSl/7IsA== Date: Mon, 26 Jan 2015 17:16:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sfc] Mobile use cases draft-ietf-sfc-use-case-mobility-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 17:16:44 -0000 Authors of draft-ietf-sfc-use-case-mobility, You make explicit reference (in section 2.2) to the care to be taken=20 with bidirectional flows, which I agree with. So, referring to your figure 5: +-------------------------+ | PCRF | +----+--------------+-----+ | | Gx-IF Sd-IF | | +----+-----+ +----+-----+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO [PCEF] | | O--------[SFC 1]= ---- [Appl. 1] | | | O--------[SFC 2] ---- [Appl. 2] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO P-GW O---O [TDF] O--------[SFC 3]= ---- [Appl. 3] | | | O--------[SFC 4] ---- [Appl. 4] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO | | O--------[SFC n]= ---- [Appl. n] +----------+ +----------+ * * 3GPP Bearer SGi SGi It isn't clear what device is selecting the chains for down-link traffic. Given that the TDF is making application-specific decisions, how would=20 one ensure the down-link traffic is classified to the same service=20 functions as the up-link traffic, something very critical for many of=20 the use cases? * a TDF can classify traffic using a wide variety of methods,=20 including signature-matching that uses fields only available at=20 the start of a flow, likely only appearing in one direction; (classification based solely on port number is rather weak).=20 So in the general case, decisions are made for TCP connections,=20 not for packets. I propose that the picture is more like the following, with the TDF=20 book-ending the service chains to ensure consistent classification of=20 both up-link and down-link traffic for a given transport connection. +-------------------------+ | PCRF | +----+--------------+-----+ | | Gx-IF Sd-IF | | | +----+------------------------------------+ | | [TDF] | | | +----------------------------+ | +----+-----+ | | | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO [PCEF] | | O---[SFC 1] ---- [A= ppl. 1]---O | | | | O---[SFC 2] ---- [Appl. 2]---O |--- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO P-GW O---O O---[SFC 3] ---- [A= ppl. 3]---O | | | | O---[SFC 4] ---- [Appl. 4]---O | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO | | O---[SFC n] ---- [A= ppl. n]---O | +----------+ +-------+ +----+ * * 3GPP Bearer SGi SGi Perhaps this is what you intended. Is this what you had in mind? David Dolson Senior Software Architect, Sandvine Inc. From nobody Mon Jan 26 19:00:33 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962271A1B91 for ; Mon, 26 Jan 2015 19:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiflCbD-zIO3 for ; Mon, 26 Jan 2015 19:00:29 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id A8BC71A008B for ; Mon, 26 Jan 2015 19:00:28 -0800 (PST) Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t0R30Ppp020540; Tue, 27 Jan 2015 12:00:25 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 15D1F5F594; Tue, 27 Jan 2015 12:00:25 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 0886D5F593; Tue, 27 Jan 2015 12:00:25 +0900 (JST) Received: from [127.0.0.1] ([129.60.20.75]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t0R30O6C016654; Tue, 27 Jan 2015 12:00:24 +0900 Message-ID: <54C6FEF7.4050008@lab.ntt.co.jp> Date: Tue, 27 Jan 2015 11:59:03 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Migault , DIEGO LOPEZ GARCIA References: <54C21423.1080309@lab.ntt.co.jp> <27631560-E85F-41B4-9354-3EFDF280157A@telefonica.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070908070504000604010505" X-TM-AS-MML: disable Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC Requirement draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 03:00:31 -0000 This is a multi-part message in MIME format. --------------070908070504000604010505 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Diego, Daniel, Thank you for your comments. I will always welcome and be thankful to any comments or contribution about security requirements! Cheers, Kengo On 2015/01/26 19:21, Daniel Migault wrote: > Hi > > I agree with Diego. The document is helpful for discussions. I would > to elaborate on the security requirements (when time permits). > > BR, > Daniel > > On Mon, Jan 26, 2015 at 9:50 AM, DIEGO LOPEZ GARCIA > > > wrote: > > I tend to agree with Kengo on this and would like to see this work > on requirements continuing > > Be goode, > > -- > Likely to be brief and not very > elaborate as sent from my mobile > Diego R. Lopez > Telefonica I+D > > > > On 23 Jan 2015, at 10:29, Kengo Naito > wrote: > > > > Hi all, > > > > Draft-boucadair-sfc-requirements-05 has been expired, but I > would like to ask WG again, that do we really should leave this > expired or not. > > > > > http://www.ietf.org/archive/id/draft-boucadair-sfc-requirements-05.txt > > > > I believe the documentation of requirements is helpful to keep > useful discussion about sfc, as we can refer at anytime "what we > really require". > > Please send any opinion to the mailing list. > > > > Best regards, > > Kengo > > > > -- > > ---------------------------------------- > > NTT Network Technology Laboratories > > Kengo Naito > > E-Mail:naito.kengo@lab.ntt.co.jp > > > TEL: +81 422-59-4949 > > ---------------------------------------- > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su > destinatario, puede contener información privilegiada o > confidencial y es para uso exclusivo de la persona o entidad de > destino. Si no es usted. el destinatario indicado, queda > notificado de que la lectura, utilización, divulgación y/o copia > sin autorización puede estar prohibida en virtud de la legislación > vigente. Si ha recibido este mensaje por error, le rogamos que nos > lo comunique inmediatamente por esta misma vía y proceda a su > destrucción. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the > individual or entity named above. If the reader of this message is > not the intended recipient, you are hereby notified that any > dissemination, distribution or copying of this communication is > strictly prohibited. If you have received this transmission in > error, do not read it. Please immediately reply to the sender that > you have received this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > destinatário, pode conter informação privilegiada ou confidencial > e é para uso exclusivo da pessoa ou entidade de destino. Se não é > vossa senhoria o destinatário indicado, fica notificado de que a > leitura, utilização, divulgação e/ou cópia sem autorização pode > estar proibida em virtude da legislação vigente. Se recebeu esta > mensagem por erro, rogamos-lhe que nos o comunique imediatamente > por esta mesma via e proceda a sua destruição > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc -- ---------------------------------------- NTT Network Technology Laboratories Kengo Naito E-Mail: naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- --------------070908070504000604010505 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Diego, Daniel,

Thank you for your comments.
I will always welcome and be thankful to any comments or contribution about security requirements!

Cheers,
Kengo

On 2015/01/26 19:21, Daniel Migault wrote:
Hi

I agree with Diego. The document is helpful for discussions. I would to elaborate on the security requirements (when time permits).

BR,
Daniel

On Mon, Jan 26, 2015 at 9:50 AM, DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com> wrote:
I tend to agree with Kengo on this and would like to see this work on requirements continuing

Be goode,

--
Likely to be brief and not very
elaborate as sent from my mobile
Diego R. Lopez
Telefonica I+D


> On 23 Jan 2015, at 10:29, Kengo Naito <naito.kengo@lab.ntt.co.jp> wrote:
>
> Hi all,
>
> Draft-boucadair-sfc-requirements-05 has been expired, but I would like to ask WG again, that do we really should leave this expired or not.
>
> http://www.ietf.org/archive/id/draft-boucadair-sfc-requirements-05.txt
>
> I believe the documentation of requirements is helpful to keep useful discussion about sfc, as we can refer  at anytime "what we really require".
> Please send any opinion to the mailing list.
>
> Best regards,
> Kengo
>
> --
> ----------------------------------------
> NTT Network Technology Laboratories
> Kengo Naito
> E-Mail:naito.kengo@lab.ntt.co.jp
> TEL: +81 422-59-4949
> ----------------------------------------
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

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



--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58


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


-- 
----------------------------------------
NTT Network Technology Laboratories
Kengo Naito
E-Mail: naito.kengo@lab.ntt.co.jp
TEL: +81 422-59-4949
----------------------------------------
--------------070908070504000604010505-- From nobody Mon Jan 26 22:28:01 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B103C1B2BA7; Mon, 26 Jan 2015 22:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.783 X-Spam-Level: X-Spam-Status: No, score=0.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmoU0Lnj53rh; Mon, 26 Jan 2015 22:27:55 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2300C1A008C; Mon, 26 Jan 2015 22:27:55 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BEC80180155B; Tue, 27 Jan 2015 07:27:51 +0100 (CET) Message-ID: <54C72FE0.40502@pi.nu> Date: Tue, 27 Jan 2015 14:27:44 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alexander Vainshtein , Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> In-Reply-To: <1422253291241.41262@ecitele.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 06:27:56 -0000 Sasha, On 2015-01-26 14:21, Alexander Vainshtein wrote: > Xiaohu, Huub, > I do not follow the SFC work closely, so I would like to understand whether the NSH should be captured by transit LSRs on the LSP - or just by the LER acting as the LSP tail-end? > > If the latter is correct, the simplest way to indicate presence of the NSH in the MPLS payload would be by allocating an "application label" indicating its presence by the tail-end LER and by inserting it at the bottom of the label stack by the head-end LER - similar to what is done for L2/L3VPN. Within this approach, if label-based demultiplexing of packets with NSH in the MPLS payload is not required, you could request allocation of a new special purpose label from the extended special purposes label space as per RFC 7274, and to insert such a label (preceded by the Extension Label ) at the BoS. > I think "the latter" is correct, the only issue I see is adding one more label stack entry to the label stack. /Loa > If the former is correct, the process above still has to be used but it has to be augmented by adding the Router Alert Label at the top of the label stack. > > From my POV these suggestions are in line with the provisions of Section 2.2 of RFC 3032 "Determining the Network Layer Protocol" that states: > > > When the last label is popped from a packet's label stack (resulting > in the stack being emptied), further processing of the packet is > based on the packet's network layer header. The LSR which pops the > last label off the stack must therefore be able to identify the > packet's network layer protocol. However, the label stack does not > contain any field which explicitly identifies the network layer > protocol. This means that the identity of the network layer protocol > must be inferable from the value of the label which is popped from > the bottom of the stack, possibly along with the contents of the > network layer header itself. > > > My 2c, > Sasha > ________________________________________ > From: mpls on behalf of Xuxiaohu > Sent: Monday, January 26, 2015 5:05 AM > To: huubatwork@gmail.com; sfc@ietf.org; mpls@ietf.org > Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? > > Hi Huub, > > The alter label itself couldn¡¯t make the receiving LSR to determine the MPLS payload type by examining the MPLS payload. > > Best regards, > Xiaohu > >> -----Original Message----- >> From: Huub van Helvoort [mailto:huubatwork@gmail.com] >> Sent: Friday, January 23, 2015 6:28 PM >> To: Xuxiaohu; sfc@ietf.org; mpls@ietf.org >> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >> >> Xuxiaohu ÄúºÃ£¡ >> >> Please correct me if I am wrong: >> >> It has always been my understanding that the MPLS header/label was >> independent of the protocol/payload. >> So no indication of the actual payload content was necessary. >> >> IMHO you could use the alert label 1 to indicate to the LSR that it has to further >> examine the content of a packet. >> >> Regards, Huub. >> >> ======== >> >>> It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04): >>> >>> The service header is independent of the encapsulation used and is >>> encapsulated in existing transports. The presence of NSH is >>> indicated via protocol type or other indicator in the outer >>> encapsulation. >>> >>> In the case where the outer encapsulation is an MPLS LSP, how to indicate the >> presence of NSH since the MPLS encapsulation has no explicit protocol identifier >> field to indicate the protocol type of the MPLS payload? Should we make each >> SFF to allocate a unique label for indicating the presence of NSH? Or should we >> use the control word to indicate it? Or should we reconsider the possibility of >> adding an explicit protocol identifier field to the MPLS encapsulation so as to >> solve such kind of issues once and for all? >>> >>> Best regards, >>> Xiaohu >>> >> >> >> -- >> ************************************************************* >> **** >> Çë¼Çס£¬ÄãÊǶÀÒ»ÎÞ¶þµÄ£¬¾ÍÏñÆäËûÿһ¸öÈËÒ»Ñù > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Jan 26 22:45:37 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958161A1A19; Mon, 26 Jan 2015 22:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGZnmeJx1-iK; Mon, 26 Jan 2015 22:45:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE6B1A1A0F; Mon, 26 Jan 2015 22:45:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT82744; Tue, 27 Jan 2015 06:45:24 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 06:45:23 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 14:45:18 +0800 From: Xuxiaohu To: Alexander Vainshtein , "huubatwork@gmail.com" Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfD//7JaAP/94nYA Date: Tue, 27 Jan 2015 06:45:18 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> In-Reply-To: <1422253291241.41262@ecitele.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 06:45:29 -0000 SGkgU2FzaGEsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleGFu ZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0N Cj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDI6MjIgUE0NCj4gVG86IFh1eGlhb2h1 OyBodXViYXR3b3JrQGdtYWlsLmNvbQ0KPiBDYzogc2ZjQGlldGYub3JnOyBtcGxzQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBO U0ggaW4gYW4gTVBMUyBwYWNrZXQ/DQo+IA0KPiBYaWFvaHUsIEh1dWIsDQo+IEkgZG8gbm90IGZv bGxvdyB0aGUgU0ZDIHdvcmsgY2xvc2VseSwgc28gSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQg d2hldGhlciB0aGUNCj4gTlNIIHNob3VsZCBiZSBjYXB0dXJlZCBieSAgdHJhbnNpdCBMU1JzIG9u IHRoZSBMU1AgLSBvciBqdXN0IGJ5IHRoZSBMRVIgYWN0aW5nIGFzDQo+IHRoZSBMU1AgdGFpbC1l bmQ/DQo+IA0KPiBJZiB0aGUgbGF0dGVyIGlzIGNvcnJlY3QsIHRoZSBzaW1wbGVzdCB3YXkgdG8g aW5kaWNhdGUgcHJlc2VuY2Ugb2YgdGhlIE5TSCBpbiB0aGUNCj4gTVBMUyBwYXlsb2FkIHdvdWxk IGJlIGJ5IGFsbG9jYXRpbmcgYW4gImFwcGxpY2F0aW9uIGxhYmVsIiBpbmRpY2F0aW5nIGl0cw0K PiBwcmVzZW5jZSBieSB0aGUgdGFpbC1lbmQgTEVSIGFuZCBieSBpbnNlcnRpbmcgaXQgYXQgdGhl IGJvdHRvbSBvZiB0aGUgbGFiZWwgc3RhY2sNCj4gYnkgdGhlIGhlYWQtZW5kIExFUiAtIHNpbWls YXIgdG8gd2hhdCBpcyBkb25lIGZvciBMMi9MM1ZQTi4gIFdpdGhpbiB0aGlzDQoNCklmIEkgdW5k ZXJzdGFuZCBpdCBjb3JyZWN0LCB0aGUgYWJvdmUgYXBwcm9hY2ggaXMgdGhlIHNhbWUgYXMgb3B0 aW9uIDEgYXMgSSBtZW50aW9uZWQgaW4gdGhlIGVhcmxpZXIgZW1haWwgKGkuZS4sIG1ha2luZyBl YWNoIFNGRiB0byBhbGxvY2F0ZSBhIHVuaXF1ZSBsYWJlbCBmb3IgaW5kaWNhdGluZyB0aGUNCnBy ZXNlbmNlIG9mIE5TSCkuDQoNCj4gYXBwcm9hY2gsIGlmIGxhYmVsLWJhc2VkIGRlbXVsdGlwbGV4 aW5nIG9mICBwYWNrZXRzIHdpdGggTlNIIGluIHRoZSBNUExTDQo+IHBheWxvYWQgaXMgbm90IHJl cXVpcmVkLCB5b3UgY291bGQgcmVxdWVzdCBhbGxvY2F0aW9uIG9mIGEgbmV3IHNwZWNpYWwgcHVy cG9zZQ0KPiBsYWJlbCBmcm9tIHRoZSBleHRlbmRlZCBzcGVjaWFsIHB1cnBvc2VzIGxhYmVsIHNw YWNlIGFzIHBlciBSRkMgNzI3NCwgYW5kIHRvDQo+IGluc2VydCBzdWNoIGEgbGFiZWwgKHByZWNl ZGVkIGJ5IHRoZSBFeHRlbnNpb24gTGFiZWwgKSBhdCB0aGUgQm9TLg0KDQpXaGF0J3MgdGhlIHB1 cnBvc2Ugb2YgaW5zZXJ0aW5nIGEgcGFydGljdWxhciBFU1AgbGFiZWwgYXQgdGhlIEJvUz8NCg0K QmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gSWYgdGhlIGZvcm1lciBpcyBjb3JyZWN0LCB0aGUg cHJvY2VzcyBhYm92ZSBzdGlsbCBoYXMgdG8gYmUgdXNlZCBidXQgaXQgaGFzIHRvIGJlDQo+IGF1 Z21lbnRlZCBieSBhZGRpbmcgdGhlIFJvdXRlciBBbGVydCBMYWJlbCAgIGF0IHRoZSB0b3Agb2Yg dGhlIGxhYmVsIHN0YWNrLg0KPiANCj4gRnJvbSBteSBQT1YgdGhlc2Ugc3VnZ2VzdGlvbnMgYXJl IGluIGxpbmUgd2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDIuMiBvZg0KPiBSRkMgMzAz MiAiRGV0ZXJtaW5pbmcgdGhlIE5ldHdvcmsgTGF5ZXIgUHJvdG9jb2wiIHRoYXQgc3RhdGVzOg0K PiANCj4gPHF1b3RlPg0KPiAgICBXaGVuIHRoZSBsYXN0IGxhYmVsIGlzIHBvcHBlZCBmcm9tIGEg cGFja2V0J3MgbGFiZWwgc3RhY2sgKHJlc3VsdGluZw0KPiAgICBpbiB0aGUgc3RhY2sgYmVpbmcg ZW1wdGllZCksIGZ1cnRoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0IGlzDQo+ICAgIGJhc2Vk IG9uIHRoZSBwYWNrZXQncyBuZXR3b3JrIGxheWVyIGhlYWRlci4gIFRoZSBMU1Igd2hpY2ggcG9w cyB0aGUNCj4gICAgbGFzdCBsYWJlbCBvZmYgdGhlIHN0YWNrIG11c3QgdGhlcmVmb3JlIGJlIGFi bGUgdG8gaWRlbnRpZnkgdGhlDQo+ICAgIHBhY2tldCdzIG5ldHdvcmsgbGF5ZXIgcHJvdG9jb2wu ICBIb3dldmVyLCB0aGUgbGFiZWwgc3RhY2sgZG9lcyBub3QNCj4gICAgY29udGFpbiBhbnkgZmll bGQgd2hpY2ggZXhwbGljaXRseSBpZGVudGlmaWVzIHRoZSBuZXR3b3JrIGxheWVyDQo+ICAgIHBy b3RvY29sLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBpZGVudGl0eSBvZiB0aGUgbmV0d29yayBsYXll ciBwcm90b2NvbA0KPiAgICBtdXN0IGJlIGluZmVyYWJsZSBmcm9tIHRoZSB2YWx1ZSBvZiB0aGUg bGFiZWwgd2hpY2ggaXMgcG9wcGVkIGZyb20NCj4gICAgdGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ss IHBvc3NpYmx5IGFsb25nIHdpdGggdGhlIGNvbnRlbnRzIG9mIHRoZQ0KPiAgICBuZXR3b3JrIGxh eWVyIGhlYWRlciBpdHNlbGYuDQo+IDxlbmQgcXVvdGU+DQo+IA0KPiBNeSAyYywNCj4gU2FzaGEN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBtcGxz IDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBYdXhpYW9odQ0KPiA8eHV4aWFv aHVAaHVhd2VpLmNvbT4NCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDU6MDUgQU0N Cj4gVG86IGh1dWJhdHdvcmtAZ21haWwuY29tOyBzZmNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5T SCBpbiBhbiBNUExTIHBhY2tldD8NCj4gDQo+IEhpIEh1dWIsDQo+IA0KPiBUaGUgYWx0ZXIgbGFi ZWwgaXRzZWxmIGNvdWxkbqGvdCBtYWtlIHRoZSByZWNlaXZpbmcgTFNSIHRvIGRldGVybWluZSB0 aGUgTVBMUw0KPiBwYXlsb2FkIHR5cGUgYnkgZXhhbWluaW5nIHRoZSBNUExTIHBheWxvYWQuDQo+ IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFttYWlsdG86aHV1YmF0d29ya0Bn bWFpbC5jb21dDQo+ID4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDIzLCAyMDE1IDY6MjggUE0NCj4g PiBUbzogWHV4aWFvaHU7IHNmY0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6 IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBM UyBwYWNrZXQ/DQo+ID4NCj4gPiBYdXhpYW9odSDE+rrDo6ENCj4gPg0KPiA+IFBsZWFzZSBjb3Jy ZWN0IG1lIGlmIEkgYW0gd3Jvbmc6DQo+ID4NCj4gPiBJdCBoYXMgYWx3YXlzIGJlZW4gbXkgdW5k ZXJzdGFuZGluZyB0aGF0IHRoZSBNUExTIGhlYWRlci9sYWJlbCB3YXMNCj4gPiBpbmRlcGVuZGVu dCBvZiB0aGUgcHJvdG9jb2wvcGF5bG9hZC4NCj4gPiBTbyBubyBpbmRpY2F0aW9uIG9mIHRoZSBh Y3R1YWwgcGF5bG9hZCBjb250ZW50IHdhcyBuZWNlc3NhcnkuDQo+ID4NCj4gPiBJTUhPIHlvdSBj b3VsZCB1c2UgdGhlIGFsZXJ0IGxhYmVsIDEgdG8gaW5kaWNhdGUgdG8gdGhlIExTUiB0aGF0IGl0 DQo+ID4gaGFzIHRvIGZ1cnRoZXIgZXhhbWluZSB0aGUgY29udGVudCBvZiBhIHBhY2tldC4NCj4g Pg0KPiA+IFJlZ2FyZHMsIEh1dWIuDQo+ID4NCj4gPiA9PT09PT09PQ0KPiA+DQo+ID4gPiBJdCBz YWlkIGluIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tc2ZjLW5zaC0w NCk6DQo+ID4gPg0KPiA+ID4gICAgIFRoZSBzZXJ2aWNlIGhlYWRlciBpcyBpbmRlcGVuZGVudCBv ZiB0aGUgZW5jYXBzdWxhdGlvbiB1c2VkIGFuZCBpcw0KPiA+ID4gICAgIGVuY2Fwc3VsYXRlZCBp biBleGlzdGluZyB0cmFuc3BvcnRzLiAgVGhlIHByZXNlbmNlIG9mIE5TSCBpcw0KPiA+ID4gICAg IGluZGljYXRlZCB2aWEgcHJvdG9jb2wgdHlwZSBvciBvdGhlciBpbmRpY2F0b3IgaW4gdGhlIG91 dGVyDQo+ID4gPiAgICAgZW5jYXBzdWxhdGlvbi4NCj4gPiA+DQo+ID4gPiBJbiB0aGUgY2FzZSB3 aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBpcyBhbiBNUExTIExTUCwgaG93IHRvDQo+ID4g PiBpbmRpY2F0ZSB0aGUNCj4gPiBwcmVzZW5jZSBvZiBOU0ggc2luY2UgdGhlIE1QTFMgZW5jYXBz dWxhdGlvbiBoYXMgbm8gZXhwbGljaXQgcHJvdG9jb2wNCj4gPiBpZGVudGlmaWVyIGZpZWxkIHRv IGluZGljYXRlIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBNUExTIHBheWxvYWQ/DQo+ID4gU2hv dWxkIHdlIG1ha2UgZWFjaCBTRkYgdG8gYWxsb2NhdGUgYSB1bmlxdWUgbGFiZWwgZm9yIGluZGlj YXRpbmcgdGhlDQo+ID4gcHJlc2VuY2Ugb2YgTlNIPyBPciBzaG91bGQgd2UgdXNlIHRoZSBjb250 cm9sIHdvcmQgdG8gaW5kaWNhdGUgaXQ/IE9yDQo+ID4gc2hvdWxkIHdlIHJlY29uc2lkZXIgdGhl IHBvc3NpYmlsaXR5IG9mIGFkZGluZyBhbiBleHBsaWNpdCBwcm90b2NvbA0KPiA+IGlkZW50aWZp ZXIgZmllbGQgdG8gdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBzbyBhcyB0byBzb2x2ZSBzdWNoIGtp bmQgb2YgaXNzdWVzDQo+IG9uY2UgYW5kIGZvciBhbGw/DQo+ID4gPg0KPiA+ID4gQmVzdCByZWdh cmRzLA0KPiA+ID4gWGlhb2h1DQo+ID4gPg0KPiA+DQo+ID4NCj4gPiAtLQ0KPiA+DQo+ICoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cj4gPiAqKioqDQo+ID4gICAgICAgICAgICAgICAgx+u8x9eho6zE48rHtsDSu87etv61xKOsvs3P 8cbky/vDv9K7uPbIy9K70fkNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From nobody Mon Jan 26 23:46:39 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F3C1B2BB9; Mon, 26 Jan 2015 23:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObjTugY7D6WQ; Mon, 26 Jan 2015 23:46:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDEE81B2BCB; Mon, 26 Jan 2015 23:46:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOL71401; Tue, 27 Jan 2015 07:46:09 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 07:46:09 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 15:46:00 +0800 From: Xuxiaohu To: Loa Andersson , Alexander Vainshtein Thread-Topic: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfD//7JaAIABlBAA//9rmmA= Date: Tue, 27 Jan 2015 07:46:00 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> In-Reply-To: <54C72FE0.40502@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 07:46:32 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG9hIEFuZGVyc3NvbiBb bWFpbHRvOmxvYUBwaS5udV0NCj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNywgMjAxNSAyOjI4 IFBNDQo+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgWHV4aWFvaHUNCj4gQ2M6IG1wbHNAaWV0 Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gW21wbHNdIEhvdyB0byBp bmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2YgTlNIIGluIGFuIE1QTFMgcGFja2V0Pw0KPiANCj4gU2Fz aGEsDQo+IA0KPiANCj4gDQo+IE9uIDIwMTUtMDEtMjYgMTQ6MjEsIEFsZXhhbmRlciBWYWluc2h0 ZWluIHdyb3RlOg0KPiA+IFhpYW9odSwgSHV1YiwNCj4gPiBJIGRvIG5vdCBmb2xsb3cgdGhlIFNG QyB3b3JrIGNsb3NlbHksIHNvIEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHdoZXRoZXIgdGhl DQo+IE5TSCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRyYW5zaXQgTFNScyBvbiB0aGUgTFNQIC0g b3IganVzdCBieSB0aGUgTEVSIGFjdGluZyBhcw0KPiB0aGUgTFNQIHRhaWwtZW5kPw0KPiA+DQo+ ID4gSWYgdGhlIGxhdHRlciBpcyBjb3JyZWN0LCB0aGUgc2ltcGxlc3Qgd2F5IHRvIGluZGljYXRl IHByZXNlbmNlIG9mIHRoZSBOU0ggaW4gdGhlDQo+IE1QTFMgcGF5bG9hZCB3b3VsZCBiZSBieSBh bGxvY2F0aW5nIGFuICJhcHBsaWNhdGlvbiBsYWJlbCIgaW5kaWNhdGluZyBpdHMNCj4gcHJlc2Vu Y2UgYnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5zZXJ0aW5nIGl0IGF0IHRoZSBib3R0b20g b2YgdGhlIGxhYmVsIHN0YWNrDQo+IGJ5IHRoZSBoZWFkLWVuZCBMRVIgLSBzaW1pbGFyIHRvIHdo YXQgaXMgZG9uZSBmb3IgTDIvTDNWUE4uICBXaXRoaW4gdGhpcw0KPiBhcHByb2FjaCwgaWYgbGFi ZWwtYmFzZWQgZGVtdWx0aXBsZXhpbmcgb2YgIHBhY2tldHMgd2l0aCBOU0ggaW4gdGhlIE1QTFMN Cj4gcGF5bG9hZCBpcyBub3QgcmVxdWlyZWQsIHlvdSBjb3VsZCByZXF1ZXN0IGFsbG9jYXRpb24g b2YgYSBuZXcgc3BlY2lhbCBwdXJwb3NlDQo+IGxhYmVsIGZyb20gdGhlIGV4dGVuZGVkIHNwZWNp YWwgcHVycG9zZXMgbGFiZWwgc3BhY2UgYXMgcGVyIFJGQyA3Mjc0LCBhbmQgdG8NCj4gaW5zZXJ0 IHN1Y2ggYSBsYWJlbCAocHJlY2VkZWQgYnkgdGhlIEV4dGVuc2lvbiBMYWJlbCApIGF0IHRoZSBC b1MuDQo+ID4NCj4gSSB0aGluayAidGhlIGxhdHRlciIgaXMgY29ycmVjdCwgdGhlIG9ubHkgaXNz dWUgSSBzZWUgaXMgYWRkaW5nIG9uZSBtb3JlIGxhYmVsIHN0YWNrDQo+IGVudHJ5IHRvIHRoZSBs YWJlbCBzdGFjay4NCg0KWWVzLCB0aGUgbGF0dGVyIGlzIGNvcnJlY3QuIFRoZSBpc3N1ZSBvZiBh ZGRpbmcgb25lIG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8gdGhlIGxhYmVsIHN0YWNrIG1heSBi ZWNvbWUgdW5hY2NlcHRhYmxlIGluIHRoZSBjYXNlIHdoZXJlIHRoZSBTZXJ2aWNlIEZ1bmN0aW9u IFBhdGggKFNGUCkgaXMgcmVwcmVzZW50ZWQgYnkgYW4gbGFiZWwgc3RhY2sgd2hpbGUgdGhlIE5T SCBpcyBub3cgb25seSB1c2VkIGFzIGEgbWV0YWRhdGEgY29udGFpbmVyLiBGb3IgZXhhbXBsZSwg Zm9yIGFuIFNGUCBjb25zaXN0IG9mIG4gU0ZzLCBuICJhcHBsaWNhdGlvbiBsYWJlbHMiIHdvdWxk IGhhdmUgdG8gYmUgaW5zZXJ0ZWQgaW50byB0aGUgbGFiZWwgc3RhY2suDQoNCkJlc3QgcmVnYXJk cywNClhpYW9odQ0KDQo+IC9Mb2ENCj4gPiBJZiB0aGUgZm9ybWVyIGlzIGNvcnJlY3QsIHRoZSBw cm9jZXNzIGFib3ZlIHN0aWxsIGhhcyB0byBiZSB1c2VkIGJ1dCBpdCBoYXMgdG8gYmUNCj4gYXVn bWVudGVkIGJ5IGFkZGluZyB0aGUgUm91dGVyIEFsZXJ0IExhYmVsICAgYXQgdGhlIHRvcCBvZiB0 aGUgbGFiZWwgc3RhY2suDQo+ID4NCj4gPiAgRnJvbSBteSBQT1YgdGhlc2Ugc3VnZ2VzdGlvbnMg YXJlIGluIGxpbmUgd2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDIuMg0KPiBvZiBSRkMg MzAzMiAiRGV0ZXJtaW5pbmcgdGhlIE5ldHdvcmsgTGF5ZXIgUHJvdG9jb2wiIHRoYXQgc3RhdGVz Og0KPiA+DQo+ID4gPHF1b3RlPg0KPiA+ICAgICBXaGVuIHRoZSBsYXN0IGxhYmVsIGlzIHBvcHBl ZCBmcm9tIGEgcGFja2V0J3MgbGFiZWwgc3RhY2sgKHJlc3VsdGluZw0KPiA+ICAgICBpbiB0aGUg c3RhY2sgYmVpbmcgZW1wdGllZCksIGZ1cnRoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0IGlz DQo+ID4gICAgIGJhc2VkIG9uIHRoZSBwYWNrZXQncyBuZXR3b3JrIGxheWVyIGhlYWRlci4gIFRo ZSBMU1Igd2hpY2ggcG9wcyB0aGUNCj4gPiAgICAgbGFzdCBsYWJlbCBvZmYgdGhlIHN0YWNrIG11 c3QgdGhlcmVmb3JlIGJlIGFibGUgdG8gaWRlbnRpZnkgdGhlDQo+ID4gICAgIHBhY2tldCdzIG5l dHdvcmsgbGF5ZXIgcHJvdG9jb2wuICBIb3dldmVyLCB0aGUgbGFiZWwgc3RhY2sgZG9lcyBub3QN Cj4gPiAgICAgY29udGFpbiBhbnkgZmllbGQgd2hpY2ggZXhwbGljaXRseSBpZGVudGlmaWVzIHRo ZSBuZXR3b3JrIGxheWVyDQo+ID4gICAgIHByb3RvY29sLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBp ZGVudGl0eSBvZiB0aGUgbmV0d29yayBsYXllciBwcm90b2NvbA0KPiA+ICAgICBtdXN0IGJlIGlu ZmVyYWJsZSBmcm9tIHRoZSB2YWx1ZSBvZiB0aGUgbGFiZWwgd2hpY2ggaXMgcG9wcGVkIGZyb20N Cj4gPiAgICAgdGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ssIHBvc3NpYmx5IGFsb25nIHdpdGggdGhl IGNvbnRlbnRzIG9mIHRoZQ0KPiA+ICAgICBuZXR3b3JrIGxheWVyIGhlYWRlciBpdHNlbGYuDQo+ ID4gPGVuZCBxdW90ZT4NCj4gPg0KPiA+IE15IDJjLA0KPiA+IFNhc2hhDQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEZyb206IG1wbHMgPG1wbHMtYm91 bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFh1eGlhb2h1DQo+ID4gPHh1eGlhb2h1QGh1YXdl aS5jb20+DQo+ID4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDU6MDUgQU0NCj4gPiBU bzogaHV1YmF0d29ya0BnbWFpbC5jb207IHNmY0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0KPiA+ IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0gg aW4gYW4gTVBMUyBwYWNrZXQ/DQo+ID4NCj4gPiBIaSBIdXViLA0KPiA+DQo+ID4gVGhlIGFsdGVy IGxhYmVsIGl0c2VsZiBjb3VsZG6hr3QgbWFrZSB0aGUgcmVjZWl2aW5nIExTUiB0byBkZXRlcm1p bmUgdGhlIE1QTFMNCj4gcGF5bG9hZCB0eXBlIGJ5IGV4YW1pbmluZyB0aGUgTVBMUyBwYXlsb2Fk Lg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IFhpYW9odQ0KPiA+DQo+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFttYWlsdG86 aHV1YmF0d29ya0BnbWFpbC5jb21dDQo+ID4+IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAyMywgMjAx NSA2OjI4IFBNDQo+ID4+IFRvOiBYdXhpYW9odTsgc2ZjQGlldGYub3JnOyBtcGxzQGlldGYub3Jn DQo+ID4+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBv ZiBOU0ggaW4gYW4gTVBMUyBwYWNrZXQ/DQo+ID4+DQo+ID4+IFh1eGlhb2h1IMT6usOjoQ0KPiA+ Pg0KPiA+PiBQbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nOg0KPiA+Pg0KPiA+PiBJdCBo YXMgYWx3YXlzIGJlZW4gbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSBNUExTIGhlYWRlci9sYWJl bCB3YXMNCj4gPj4gaW5kZXBlbmRlbnQgb2YgdGhlIHByb3RvY29sL3BheWxvYWQuDQo+ID4+IFNv IG5vIGluZGljYXRpb24gb2YgdGhlIGFjdHVhbCBwYXlsb2FkIGNvbnRlbnQgd2FzIG5lY2Vzc2Fy eS4NCj4gPj4NCj4gPj4gSU1ITyB5b3UgY291bGQgdXNlIHRoZSBhbGVydCBsYWJlbCAxIHRvIGlu ZGljYXRlIHRvIHRoZSBMU1IgdGhhdCBpdA0KPiA+PiBoYXMgdG8gZnVydGhlciBleGFtaW5lIHRo ZSBjb250ZW50IG9mIGEgcGFja2V0Lg0KPiA+Pg0KPiA+PiBSZWdhcmRzLCBIdXViLg0KPiA+Pg0K PiA+PiA9PT09PT09PQ0KPiA+Pg0KPiA+Pj4gSXQgc2FpZCBpbiAoaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXF1aW5uLXNmYy1uc2gtMDQpOg0KPiA+Pj4NCj4gPj4+ICAgICAgVGhl IHNlcnZpY2UgaGVhZGVyIGlzIGluZGVwZW5kZW50IG9mIHRoZSBlbmNhcHN1bGF0aW9uIHVzZWQg YW5kIGlzDQo+ID4+PiAgICAgIGVuY2Fwc3VsYXRlZCBpbiBleGlzdGluZyB0cmFuc3BvcnRzLiAg VGhlIHByZXNlbmNlIG9mIE5TSCBpcw0KPiA+Pj4gICAgICBpbmRpY2F0ZWQgdmlhIHByb3RvY29s IHR5cGUgb3Igb3RoZXIgaW5kaWNhdG9yIGluIHRoZSBvdXRlcg0KPiA+Pj4gICAgICBlbmNhcHN1 bGF0aW9uLg0KPiA+Pj4NCj4gPj4+IEluIHRoZSBjYXNlIHdoZXJlIHRoZSBvdXRlciBlbmNhcHN1 bGF0aW9uIGlzIGFuIE1QTFMgTFNQLCBob3cgdG8NCj4gPj4+IGluZGljYXRlIHRoZQ0KPiA+PiBw cmVzZW5jZSBvZiBOU0ggc2luY2UgdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBoYXMgbm8gZXhwbGlj aXQgcHJvdG9jb2wNCj4gPj4gaWRlbnRpZmllciBmaWVsZCB0byBpbmRpY2F0ZSB0aGUgcHJvdG9j b2wgdHlwZSBvZiB0aGUgTVBMUyBwYXlsb2FkPw0KPiA+PiBTaG91bGQgd2UgbWFrZSBlYWNoIFNG RiB0byBhbGxvY2F0ZSBhIHVuaXF1ZSBsYWJlbCBmb3IgaW5kaWNhdGluZyB0aGUNCj4gPj4gcHJl c2VuY2Ugb2YgTlNIPyBPciBzaG91bGQgd2UgdXNlIHRoZSBjb250cm9sIHdvcmQgdG8gaW5kaWNh dGUgaXQ/IE9yDQo+ID4+IHNob3VsZCB3ZSByZWNvbnNpZGVyIHRoZSBwb3NzaWJpbGl0eSBvZiBh ZGRpbmcgYW4gZXhwbGljaXQgcHJvdG9jb2wNCj4gPj4gaWRlbnRpZmllciBmaWVsZCB0byB0aGUg TVBMUyBlbmNhcHN1bGF0aW9uIHNvIGFzIHRvIHNvbHZlIHN1Y2gga2luZCBvZiBpc3N1ZXMNCj4g b25jZSBhbmQgZm9yIGFsbD8NCj4gPj4+DQo+ID4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+PiBYaWFv aHUNCj4gPj4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tDQo+ID4+DQo+ICoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gPj4gKioqKg0K PiA+PiAgICAgICAgICAgICAgICAgx+u8x9eho6zE48rHtsDSu87etv61xKOsvs3P8cbky/vDv9K7 uPbIy9K70fkNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gc2ZjIG1haWxpbmcgbGlzdA0K PiA+IHNmY0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+ID4NCj4gDQo+IC0tDQo+IA0KPiANCj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAg ICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gU2VuaW9yIE1QTFMg RXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj4gSHVhd2VpIFRlY2hu b2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo= From nobody Mon Jan 26 23:49:33 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034161B2BB6; Mon, 26 Jan 2015 23:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ19xl6ATiHB; Mon, 26 Jan 2015 23:49:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE871B2BBA; Mon, 26 Jan 2015 23:49:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT88802; Tue, 27 Jan 2015 07:49:26 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 07:49:25 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 15:49:20 +0800 From: Xuxiaohu To: Alexander Vainshtein Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfD//7JaAP/94nYAgAPCVgD//3Rm4A== Date: Tue, 27 Jan 2015 07:49:19 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08302093@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> <1422343655626.35892@ecitele.com> In-Reply-To: <1422343655626.35892@ecitele.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" , "huubatwork@gmail.com" Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 07:49:31 -0000 SGkgU2FzaGEsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleGFu ZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0N Cj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNywgMjAxNSAzOjI4IFBNDQo+IFRvOiBYdXhpYW9o dQ0KPiBDYzogc2ZjQGlldGYub3JnOyBtcGxzQGlldGYub3JnOyBodXViYXR3b3JrQGdtYWlsLmNv bQ0KPiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2Yg TlNIIGluIGFuIE1QTFMgcGFja2V0Pw0KPiANCj4gWGlhb2h1LA0KPiBSZWdhcmRpbmcgeW91ciBx dWVzdGlvbjogIldoYXQncyB0aGUgcHVycG9zZSBvZiBpbnNlcnRpbmcgYSBwYXJ0aWN1bGFyIEVT UCBsYWJlbA0KPiBhdCB0aGUgQm9TPyINCj4gDQo+IFRoaXMgaXMgYW4gYWx0ZXJuYXRpdmUgdG8g ZWFjaCBTRkYgYWxsb2NhdGluZyBhIHVuaXF1ZSBhcHBsaWNhdGlvbiBsYWJlbC4NCj4gVGhpcyBh bHRlcm5hdGl2ZSB3b3VsZCB3b3JrIGlmIGRlbXVsdGlwbGV4aW5nIG9mIGEgcmVjZWl2ZWQgbGFi ZWxlZCBwYWNrZXQgd2l0aA0KPiBOU0ggaGVhZGVyIHRvIGEgc3BlY2lmaWMgU1NGIHdpdGhpbiB0 aGUgcHJvY2Vzc2luZyBub2RlIGNhbiBiZSBkb25lIGJhc2VkIG9uDQo+IHRoZSBOU0ggb25seS4N Cj4gU2F2ZXMgeW91IHRoZSBuZWVkIHRvIGFsbG9jYXRlIGFuZCBkaXN0cmlidXRlIHBlciBTU0Yg bGFiZWxzLg0KDQpEaWQgeW91IG1lYW4gdG8gdXNlIGEgcGFydGljdWxhciBFU1AgbGFiZWwgdG8g aW5kaWNhdGUgYSBnaXZlbiBNUExTIHBheWxvYWQgdHlwZSAoZS5nLiwgTlNIKT8NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCj4gSG9wZWZ1bGx5IHRoaXMgYW5zd2VycyB5b3VyIHF1ZXN0aW9u Lg0KPiANCj4gUmVnYXJkcywNCj4gU2FzaGENCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gRnJvbTogWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+ DQo+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjcsIDIwMTUgODo0NSBBTQ0KPiBUbzogQWxleGFu ZGVyIFZhaW5zaHRlaW47IGh1dWJhdHdvcmtAZ21haWwuY29tDQo+IENjOiBzZmNAaWV0Zi5vcmc7 IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhl IHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTIHBhY2tldD8NCj4gDQo+IEhpIFNhc2hhLA0KPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEFsZXhhbmRlciBWYWlu c2h0ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dDQo+ID4gU2Vu dDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDI6MjIgUE0NCj4gPiBUbzogWHV4aWFvaHU7IGh1 dWJhdHdvcmtAZ21haWwuY29tDQo+ID4gQ2M6IHNmY0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0K PiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBO U0ggaW4gYW4gTVBMUyBwYWNrZXQ/DQo+ID4NCj4gPiBYaWFvaHUsIEh1dWIsDQo+ID4gSSBkbyBu b3QgZm9sbG93IHRoZSBTRkMgd29yayBjbG9zZWx5LCBzbyBJIHdvdWxkIGxpa2UgdG8gdW5kZXJz dGFuZA0KPiA+IHdoZXRoZXIgdGhlIE5TSCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRyYW5zaXQg TFNScyBvbiB0aGUgTFNQIC0gb3INCj4gPiBqdXN0IGJ5IHRoZSBMRVIgYWN0aW5nIGFzIHRoZSBM U1AgdGFpbC1lbmQ/DQo+ID4NCj4gPiBJZiB0aGUgbGF0dGVyIGlzIGNvcnJlY3QsIHRoZSBzaW1w bGVzdCB3YXkgdG8gaW5kaWNhdGUgcHJlc2VuY2Ugb2YgdGhlDQo+ID4gTlNIIGluIHRoZSBNUExT IHBheWxvYWQgd291bGQgYmUgYnkgYWxsb2NhdGluZyBhbiAiYXBwbGljYXRpb24gbGFiZWwiDQo+ ID4gaW5kaWNhdGluZyBpdHMgcHJlc2VuY2UgYnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5z ZXJ0aW5nIGl0IGF0IHRoZQ0KPiA+IGJvdHRvbSBvZiB0aGUgbGFiZWwgc3RhY2sgYnkgdGhlIGhl YWQtZW5kIExFUiAtIHNpbWlsYXIgdG8gd2hhdCBpcw0KPiA+IGRvbmUgZm9yIEwyL0wzVlBOLiAg V2l0aGluIHRoaXMNCj4gDQo+IElmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0LCB0aGUgYWJvdmUg YXBwcm9hY2ggaXMgdGhlIHNhbWUgYXMgb3B0aW9uIDEgYXMgSQ0KPiBtZW50aW9uZWQgaW4gdGhl IGVhcmxpZXIgZW1haWwgKGkuZS4sIG1ha2luZyBlYWNoIFNGRiB0byBhbGxvY2F0ZSBhIHVuaXF1 ZSBsYWJlbA0KPiBmb3IgaW5kaWNhdGluZyB0aGUgcHJlc2VuY2Ugb2YgTlNIKS4NCj4gDQo+ID4g YXBwcm9hY2gsIGlmIGxhYmVsLWJhc2VkIGRlbXVsdGlwbGV4aW5nIG9mICBwYWNrZXRzIHdpdGgg TlNIIGluIHRoZQ0KPiA+IE1QTFMgcGF5bG9hZCBpcyBub3QgcmVxdWlyZWQsIHlvdSBjb3VsZCBy ZXF1ZXN0IGFsbG9jYXRpb24gb2YgYSBuZXcNCj4gPiBzcGVjaWFsIHB1cnBvc2UgbGFiZWwgZnJv bSB0aGUgZXh0ZW5kZWQgc3BlY2lhbCBwdXJwb3NlcyBsYWJlbCBzcGFjZQ0KPiA+IGFzIHBlciBS RkMgNzI3NCwgYW5kIHRvIGluc2VydCBzdWNoIGEgbGFiZWwgKHByZWNlZGVkIGJ5IHRoZSBFeHRl bnNpb24gTGFiZWwgKQ0KPiBhdCB0aGUgQm9TLg0KPiANCj4gV2hhdCdzIHRoZSBwdXJwb3NlIG9m IGluc2VydGluZyBhIHBhcnRpY3VsYXIgRVNQIGxhYmVsIGF0IHRoZSBCb1M/DQo+IA0KPiBCZXN0 IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiBJZiB0aGUgZm9ybWVyIGlzIGNvcnJlY3QsIHRo ZSBwcm9jZXNzIGFib3ZlIHN0aWxsIGhhcyB0byBiZSB1c2VkIGJ1dCBpdCBoYXMgdG8gYmUNCj4g PiBhdWdtZW50ZWQgYnkgYWRkaW5nIHRoZSBSb3V0ZXIgQWxlcnQgTGFiZWwgICBhdCB0aGUgdG9w IG9mIHRoZSBsYWJlbCBzdGFjay4NCj4gPg0KPiA+IEZyb20gbXkgUE9WIHRoZXNlIHN1Z2dlc3Rp b25zIGFyZSBpbiBsaW5lIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YNCj4gPiBTZWN0aW9uIDIuMiBv ZiBSRkMgMzAzMiAiRGV0ZXJtaW5pbmcgdGhlIE5ldHdvcmsgTGF5ZXIgUHJvdG9jb2wiIHRoYXQN Cj4gc3RhdGVzOg0KPiA+DQo+ID4gPHF1b3RlPg0KPiA+ICAgIFdoZW4gdGhlIGxhc3QgbGFiZWwg aXMgcG9wcGVkIGZyb20gYSBwYWNrZXQncyBsYWJlbCBzdGFjayAocmVzdWx0aW5nDQo+ID4gICAg aW4gdGhlIHN0YWNrIGJlaW5nIGVtcHRpZWQpLCBmdXJ0aGVyIHByb2Nlc3Npbmcgb2YgdGhlIHBh Y2tldCBpcw0KPiA+ICAgIGJhc2VkIG9uIHRoZSBwYWNrZXQncyBuZXR3b3JrIGxheWVyIGhlYWRl ci4gIFRoZSBMU1Igd2hpY2ggcG9wcyB0aGUNCj4gPiAgICBsYXN0IGxhYmVsIG9mZiB0aGUgc3Rh Y2sgbXVzdCB0aGVyZWZvcmUgYmUgYWJsZSB0byBpZGVudGlmeSB0aGUNCj4gPiAgICBwYWNrZXQn cyBuZXR3b3JrIGxheWVyIHByb3RvY29sLiAgSG93ZXZlciwgdGhlIGxhYmVsIHN0YWNrIGRvZXMg bm90DQo+ID4gICAgY29udGFpbiBhbnkgZmllbGQgd2hpY2ggZXhwbGljaXRseSBpZGVudGlmaWVz IHRoZSBuZXR3b3JrIGxheWVyDQo+ID4gICAgcHJvdG9jb2wuICBUaGlzIG1lYW5zIHRoYXQgdGhl IGlkZW50aXR5IG9mIHRoZSBuZXR3b3JrIGxheWVyIHByb3RvY29sDQo+ID4gICAgbXVzdCBiZSBp bmZlcmFibGUgZnJvbSB0aGUgdmFsdWUgb2YgdGhlIGxhYmVsIHdoaWNoIGlzIHBvcHBlZCBmcm9t DQo+ID4gICAgdGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ssIHBvc3NpYmx5IGFsb25nIHdpdGggdGhl IGNvbnRlbnRzIG9mIHRoZQ0KPiA+ICAgIG5ldHdvcmsgbGF5ZXIgaGVhZGVyIGl0c2VsZi4NCj4g PiA8ZW5kIHF1b3RlPg0KPiA+DQo+ID4gTXkgMmMsDQo+ID4gU2FzaGENCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRnJvbTogbXBscyA8bXBscy1ib3Vu Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgWHV4aWFvaHUNCj4gPiA8eHV4aWFvaHVAaHVhd2Vp LmNvbT4NCj4gPiBTZW50OiBNb25kYXksIEphbnVhcnkgMjYsIDIwMTUgNTowNSBBTQ0KPiA+IFRv OiBodXViYXR3b3JrQGdtYWlsLmNvbTsgc2ZjQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQo+ID4g U3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBp biBhbiBNUExTIHBhY2tldD8NCj4gPg0KPiA+IEhpIEh1dWIsDQo+ID4NCj4gPiBUaGUgYWx0ZXIg bGFiZWwgaXRzZWxmIGNvdWxkbqGvdCBtYWtlIHRoZSByZWNlaXZpbmcgTFNSIHRvIGRldGVybWlu ZQ0KPiA+IHRoZSBNUExTIHBheWxvYWQgdHlwZSBieSBleGFtaW5pbmcgdGhlIE1QTFMgcGF5bG9h ZC4NCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFttYWls dG86aHV1YmF0d29ya0BnbWFpbC5jb21dDQo+ID4gPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMjMs IDIwMTUgNjoyOCBQTQ0KPiA+ID4gVG86IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmc7IG1wbHNAaWV0 Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVz ZW5jZSBvZiBOU0ggaW4gYW4gTVBMUyBwYWNrZXQ/DQo+ID4gPg0KPiA+ID4gWHV4aWFvaHUgxPq6 w6OhDQo+ID4gPg0KPiA+ID4gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZzoNCj4gPiA+ DQo+ID4gPiBJdCBoYXMgYWx3YXlzIGJlZW4gbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSBNUExT IGhlYWRlci9sYWJlbCB3YXMNCj4gPiA+IGluZGVwZW5kZW50IG9mIHRoZSBwcm90b2NvbC9wYXls b2FkLg0KPiA+ID4gU28gbm8gaW5kaWNhdGlvbiBvZiB0aGUgYWN0dWFsIHBheWxvYWQgY29udGVu dCB3YXMgbmVjZXNzYXJ5Lg0KPiA+ID4NCj4gPiA+IElNSE8geW91IGNvdWxkIHVzZSB0aGUgYWxl cnQgbGFiZWwgMSB0byBpbmRpY2F0ZSB0byB0aGUgTFNSIHRoYXQgaXQNCj4gPiA+IGhhcyB0byBm dXJ0aGVyIGV4YW1pbmUgdGhlIGNvbnRlbnQgb2YgYSBwYWNrZXQuDQo+ID4gPg0KPiA+ID4gUmVn YXJkcywgSHV1Yi4NCj4gPiA+DQo+ID4gPiA9PT09PT09PQ0KPiA+ID4NCj4gPiA+ID4gSXQgc2Fp ZCBpbiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXNmYy1uc2gtMDQp Og0KPiA+ID4gPg0KPiA+ID4gPiAgICAgVGhlIHNlcnZpY2UgaGVhZGVyIGlzIGluZGVwZW5kZW50 IG9mIHRoZSBlbmNhcHN1bGF0aW9uIHVzZWQgYW5kIGlzDQo+ID4gPiA+ICAgICBlbmNhcHN1bGF0 ZWQgaW4gZXhpc3RpbmcgdHJhbnNwb3J0cy4gIFRoZSBwcmVzZW5jZSBvZiBOU0ggaXMNCj4gPiA+ ID4gICAgIGluZGljYXRlZCB2aWEgcHJvdG9jb2wgdHlwZSBvciBvdGhlciBpbmRpY2F0b3IgaW4g dGhlIG91dGVyDQo+ID4gPiA+ICAgICBlbmNhcHN1bGF0aW9uLg0KPiA+ID4gPg0KPiA+ID4gPiBJ biB0aGUgY2FzZSB3aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBpcyBhbiBNUExTIExTUCwg aG93IHRvDQo+ID4gPiA+IGluZGljYXRlIHRoZQ0KPiA+ID4gcHJlc2VuY2Ugb2YgTlNIIHNpbmNl IHRoZSBNUExTIGVuY2Fwc3VsYXRpb24gaGFzIG5vIGV4cGxpY2l0DQo+ID4gPiBwcm90b2NvbCBp ZGVudGlmaWVyIGZpZWxkIHRvIGluZGljYXRlIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBNUExT IHBheWxvYWQ/DQo+ID4gPiBTaG91bGQgd2UgbWFrZSBlYWNoIFNGRiB0byBhbGxvY2F0ZSBhIHVu aXF1ZSBsYWJlbCBmb3IgaW5kaWNhdGluZw0KPiA+ID4gdGhlIHByZXNlbmNlIG9mIE5TSD8gT3Ig c2hvdWxkIHdlIHVzZSB0aGUgY29udHJvbCB3b3JkIHRvIGluZGljYXRlDQo+ID4gPiBpdD8gT3Ig c2hvdWxkIHdlIHJlY29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IG9mIGFkZGluZyBhbiBleHBsaWNp dA0KPiA+ID4gcHJvdG9jb2wgaWRlbnRpZmllciBmaWVsZCB0byB0aGUgTVBMUyBlbmNhcHN1bGF0 aW9uIHNvIGFzIHRvIHNvbHZlDQo+ID4gPiBzdWNoIGtpbmQgb2YgaXNzdWVzDQo+ID4gb25jZSBh bmQgZm9yIGFsbD8NCj4gPiA+ID4NCj4gPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gPiBYaWFv aHUNCj4gPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gLS0NCj4gPiA+DQo+ID4NCj4gKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K PiA+ID4gKioqKg0KPiA+ID4gICAgICAgICAgICAgICAgx+u8x9eho6zE48rHtsDSu87etv61xKOs vs3P8cbky/vDv9K7uPbIy9K70fkNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9y Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From nobody Tue Jan 27 00:59:01 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AFF1A8A8D; Tue, 27 Jan 2015 00:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 268QUEapvkyX; Tue, 27 Jan 2015 00:58:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89BF1A8751; Tue, 27 Jan 2015 00:58:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOL79644; Tue, 27 Jan 2015 08:58:49 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 08:58:48 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 16:58:41 +0800 From: Xuxiaohu To: Alexander Vainshtein Thread-Topic: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfD//7JaAIABlBAA//9rmmCAALrkAP//d10Q Date: Tue, 27 Jan 2015 08:58:41 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 08:58:56 -0000 SGkgU2FzaGEsDQoNCklmIG9ubHkgb25lIGFwcGxpY2F0aW9uIGxhYmVsIGlzIHJlcXVpcmVkIHRv IGJlIGluc2VydGVkIGludG8gdGhlIGxhYmVsIHN0YWNrLCB3aGVyZSBzaG91bGQgaXQgYmUgaW5z ZXJ0ZWQ/IGF0IHRoZSBCb1M/IElmIHNvLCBpdCBzZWVtcyB0aGF0IHRoZSBhcHBsaWNhdGlvbiBs YWJlbCBtdXN0IGJlIGFuIEVTUCBsYWJlbC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4g W21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCj4gU2VudDogVHVlc2Rh eSwgSmFudWFyeSAyNywgMjAxNSA0OjQ2IFBNDQo+IFRvOiBYdXhpYW9odQ0KPiBDYzogbXBsc0Bp ZXRmLm9yZzsgc2ZjQGlldGYub3JnOyBMb2EgQW5kZXJzc29uDQo+IFN1YmplY3Q6IFJFOiBbc2Zj XSBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBMUyBw YWNrZXQ/DQo+IA0KPiBYaWFvaCBoaSENCj4gSSBkbyBub3QgdGhpbmsgeW91IG5lZWQgbXVsdGlw bGUgYXBwbGljYXRpb24gbGFiZWxzLg0KPiBSYXRoZXIsIHlvdSBjb3VsZCBzd2FwIHRoZXNlIGxh YmVscyBhcyB0aGUgcGFja2V0IHByb2dyZXNzZXMgYWxvbmcgdGhlIFNGUCwgc2FtZQ0KPiBhcyBp cyBkb25lIHdpdGggTVMtUFdzLg0KPiANCj4gUmVnYXJkcywNCj4gICAgICAgIFNhc2hhDQo+IEVt YWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPiBNb2JpbGU6IDA1NC05MjY2 MzAyDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFh1 eGlhb2h1IFttYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gPiBTZW50OiBUdWVzZGF5LCBK YW51YXJ5IDI3LCAyMDE1IDk6NDYgQU0NCj4gPiBUbzogTG9hIEFuZGVyc3NvbjsgQWxleGFuZGVy IFZhaW5zaHRlaW4NCj4gPiBDYzogbXBsc0BpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQo+ID4gU3Vi amVjdDogUkU6IFtzZmNdIFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5T SCBpbiBhbiBNUExTDQo+ID4gcGFja2V0Pw0KPiA+DQo+ID4NCj4gPg0KPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzpsb2FA cGkubnVdDQo+ID4gPiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1IDI6MjggUE0NCj4g PiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgWHV4aWFvaHUNCj4gPiA+IENjOiBtcGxzQGll dGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbc2ZjXSBbbXBsc10gSG93 IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBMUw0KPiA+IHBhY2tldD8N Cj4gPiA+DQo+ID4gPiBTYXNoYSwNCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IE9uIDIwMTUt MDEtMjYgMTQ6MjEsIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOg0KPiA+ID4gPiBYaWFvaHUs IEh1dWIsDQo+ID4gPiA+IEkgZG8gbm90IGZvbGxvdyB0aGUgU0ZDIHdvcmsgY2xvc2VseSwgc28g SSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQNCj4gPiA+ID4gd2hldGhlciB0aGUNCj4gPiA+IE5T SCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRyYW5zaXQgTFNScyBvbiB0aGUgTFNQIC0gb3IganVz dCBieSB0aGUNCj4gPiA+IExFUiBhY3RpbmcgYXMgdGhlIExTUCB0YWlsLWVuZD8NCj4gPiA+ID4N Cj4gPiA+ID4gSWYgdGhlIGxhdHRlciBpcyBjb3JyZWN0LCB0aGUgc2ltcGxlc3Qgd2F5IHRvIGlu ZGljYXRlIHByZXNlbmNlIG9mDQo+ID4gPiA+IHRoZSBOU0ggaW4gdGhlDQo+ID4gPiBNUExTIHBh eWxvYWQgd291bGQgYmUgYnkgYWxsb2NhdGluZyBhbiAiYXBwbGljYXRpb24gbGFiZWwiIGluZGlj YXRpbmcNCj4gPiA+IGl0cyBwcmVzZW5jZSBieSB0aGUgdGFpbC1lbmQgTEVSIGFuZCBieSBpbnNl cnRpbmcgaXQgYXQgdGhlIGJvdHRvbSBvZg0KPiA+ID4gdGhlIGxhYmVsIHN0YWNrIGJ5IHRoZSBo ZWFkLWVuZCBMRVIgLSBzaW1pbGFyIHRvIHdoYXQgaXMgZG9uZSBmb3INCj4gPiA+IEwyL0wzVlBO LiAgV2l0aGluIHRoaXMgYXBwcm9hY2gsIGlmIGxhYmVsLWJhc2VkIGRlbXVsdGlwbGV4aW5nIG9m DQo+ID4gPiBwYWNrZXRzIHdpdGggTlNIIGluIHRoZSBNUExTIHBheWxvYWQgaXMgbm90IHJlcXVp cmVkLCB5b3UgY291bGQNCj4gPiA+IHJlcXVlc3QgYWxsb2NhdGlvbiBvZiBhIG5ldyBzcGVjaWFs IHB1cnBvc2UgbGFiZWwgZnJvbSB0aGUgZXh0ZW5kZWQNCj4gPiA+IHNwZWNpYWwgcHVycG9zZXMg bGFiZWwgc3BhY2UgYXMgcGVyIFJGQyA3Mjc0LCBhbmQgdG8gaW5zZXJ0IHN1Y2ggYSBsYWJlbA0K PiA+IChwcmVjZWRlZCBieSB0aGUgRXh0ZW5zaW9uIExhYmVsICkgYXQgdGhlIEJvUy4NCj4gPiA+ ID4NCj4gPiA+IEkgdGhpbmsgInRoZSBsYXR0ZXIiIGlzIGNvcnJlY3QsIHRoZSBvbmx5IGlzc3Vl IEkgc2VlIGlzIGFkZGluZyBvbmUNCj4gPiA+IG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8gdGhl IGxhYmVsIHN0YWNrLg0KPiA+DQo+ID4gWWVzLCB0aGUgbGF0dGVyIGlzIGNvcnJlY3QuIFRoZSBp c3N1ZSBvZiBhZGRpbmcgb25lIG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8NCj4gPiB0aGUgbGFi ZWwgc3RhY2sgbWF5IGJlY29tZSB1bmFjY2VwdGFibGUgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIFNl cnZpY2UNCj4gPiBGdW5jdGlvbiBQYXRoIChTRlApIGlzIHJlcHJlc2VudGVkIGJ5IGFuIGxhYmVs IHN0YWNrIHdoaWxlIHRoZSBOU0ggaXMgbm93DQo+ID4gb25seSB1c2VkIGFzIGEgbWV0YWRhdGEg Y29udGFpbmVyLiBGb3IgZXhhbXBsZSwgZm9yIGFuIFNGUCBjb25zaXN0IG9mIG4gU0ZzLCBuDQo+ ID4gImFwcGxpY2F0aW9uIGxhYmVscyIgd291bGQgaGF2ZSB0byBiZSBpbnNlcnRlZCBpbnRvIHRo ZSBsYWJlbCBzdGFjay4NCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0K PiA+ID4gL0xvYQ0KPiA+ID4gPiBJZiB0aGUgZm9ybWVyIGlzIGNvcnJlY3QsIHRoZSBwcm9jZXNz IGFib3ZlIHN0aWxsIGhhcyB0byBiZSB1c2VkIGJ1dA0KPiA+ID4gPiBpdCBoYXMgdG8gYmUNCj4g PiA+IGF1Z21lbnRlZCBieSBhZGRpbmcgdGhlIFJvdXRlciBBbGVydCBMYWJlbCAgIGF0IHRoZSB0 b3Agb2YgdGhlIGxhYmVsIHN0YWNrLg0KPiA+ID4gPg0KPiA+ID4gPiAgRnJvbSBteSBQT1YgdGhl c2Ugc3VnZ2VzdGlvbnMgYXJlIGluIGxpbmUgd2l0aCB0aGUgcHJvdmlzaW9ucyBvZg0KPiA+ID4g PiBTZWN0aW9uIDIuMg0KPiA+ID4gb2YgUkZDIDMwMzIgIkRldGVybWluaW5nIHRoZSBOZXR3b3Jr IExheWVyIFByb3RvY29sIiB0aGF0IHN0YXRlczoNCj4gPiA+ID4NCj4gPiA+ID4gPHF1b3RlPg0K PiA+ID4gPiAgICAgV2hlbiB0aGUgbGFzdCBsYWJlbCBpcyBwb3BwZWQgZnJvbSBhIHBhY2tldCdz IGxhYmVsIHN0YWNrIChyZXN1bHRpbmcNCj4gPiA+ID4gICAgIGluIHRoZSBzdGFjayBiZWluZyBl bXB0aWVkKSwgZnVydGhlciBwcm9jZXNzaW5nIG9mIHRoZSBwYWNrZXQgaXMNCj4gPiA+ID4gICAg IGJhc2VkIG9uIHRoZSBwYWNrZXQncyBuZXR3b3JrIGxheWVyIGhlYWRlci4gIFRoZSBMU1Igd2hp Y2ggcG9wcw0KPiB0aGUNCj4gPiA+ID4gICAgIGxhc3QgbGFiZWwgb2ZmIHRoZSBzdGFjayBtdXN0 IHRoZXJlZm9yZSBiZSBhYmxlIHRvIGlkZW50aWZ5IHRoZQ0KPiA+ID4gPiAgICAgcGFja2V0J3Mg bmV0d29yayBsYXllciBwcm90b2NvbC4gIEhvd2V2ZXIsIHRoZSBsYWJlbCBzdGFjayBkb2VzIG5v dA0KPiA+ID4gPiAgICAgY29udGFpbiBhbnkgZmllbGQgd2hpY2ggZXhwbGljaXRseSBpZGVudGlm aWVzIHRoZSBuZXR3b3JrIGxheWVyDQo+ID4gPiA+ICAgICBwcm90b2NvbC4gIFRoaXMgbWVhbnMg dGhhdCB0aGUgaWRlbnRpdHkgb2YgdGhlIG5ldHdvcmsgbGF5ZXIgcHJvdG9jb2wNCj4gPiA+ID4g ICAgIG11c3QgYmUgaW5mZXJhYmxlIGZyb20gdGhlIHZhbHVlIG9mIHRoZSBsYWJlbCB3aGljaCBp cyBwb3BwZWQgZnJvbQ0KPiA+ID4gPiAgICAgdGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ssIHBvc3Np Ymx5IGFsb25nIHdpdGggdGhlIGNvbnRlbnRzIG9mIHRoZQ0KPiA+ID4gPiAgICAgbmV0d29yayBs YXllciBoZWFkZXIgaXRzZWxmLg0KPiA+ID4gPiA8ZW5kIHF1b3RlPg0KPiA+ID4gPg0KPiA+ID4g PiBNeSAyYywNCj4gPiA+ID4gU2FzaGENCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gPiBGcm9tOiBtcGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5v cmc+IG9uIGJlaGFsZiBvZiBYdXhpYW9odQ0KPiA+ID4gPiA8eHV4aWFvaHVAaHVhd2VpLmNvbT4N Cj4gPiA+ID4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDU6MDUgQU0NCj4gPiA+ID4g VG86IGh1dWJhdHdvcmtAZ21haWwuY29tOyBzZmNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcNCj4g PiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9m IE5TSCBpbiBhbiBNUExTDQo+ID4gcGFja2V0Pw0KPiA+ID4gPg0KPiA+ID4gPiBIaSBIdXViLA0K PiA+ID4gPg0KPiA+ID4gPiBUaGUgYWx0ZXIgbGFiZWwgaXRzZWxmIGNvdWxkbqGvdCBtYWtlIHRo ZSByZWNlaXZpbmcgTFNSIHRvIGRldGVybWluZQ0KPiA+ID4gPiB0aGUgTVBMUw0KPiA+ID4gcGF5 bG9hZCB0eXBlIGJ5IGV4YW1pbmluZyB0aGUgTVBMUyBwYXlsb2FkLg0KPiA+ID4gPg0KPiA+ID4g PiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiA+IFhpYW9odQ0KPiA+ID4gPg0KPiA+ID4gPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+IEZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFtt YWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb21dDQo+ID4gPiA+PiBTZW50OiBGcmlkYXksIEphbnVh cnkgMjMsIDIwMTUgNjoyOCBQTQ0KPiA+ID4gPj4gVG86IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmc7 IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGlj YXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBMUw0KPiA+IHBhY2tldD8NCj4gPiA+ID4+ DQo+ID4gPiA+PiBYdXhpYW9odSDE+rrDo6ENCj4gPiA+ID4+DQo+ID4gPiA+PiBQbGVhc2UgY29y cmVjdCBtZSBpZiBJIGFtIHdyb25nOg0KPiA+ID4gPj4NCj4gPiA+ID4+IEl0IGhhcyBhbHdheXMg YmVlbiBteSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIE1QTFMgaGVhZGVyL2xhYmVsIHdhcw0KPiA+ ID4gPj4gaW5kZXBlbmRlbnQgb2YgdGhlIHByb3RvY29sL3BheWxvYWQuDQo+ID4gPiA+PiBTbyBu byBpbmRpY2F0aW9uIG9mIHRoZSBhY3R1YWwgcGF5bG9hZCBjb250ZW50IHdhcyBuZWNlc3Nhcnku DQo+ID4gPiA+Pg0KPiA+ID4gPj4gSU1ITyB5b3UgY291bGQgdXNlIHRoZSBhbGVydCBsYWJlbCAx IHRvIGluZGljYXRlIHRvIHRoZSBMU1IgdGhhdCBpdA0KPiA+ID4gPj4gaGFzIHRvIGZ1cnRoZXIg ZXhhbWluZSB0aGUgY29udGVudCBvZiBhIHBhY2tldC4NCj4gPiA+ID4+DQo+ID4gPiA+PiBSZWdh cmRzLCBIdXViLg0KPiA+ID4gPj4NCj4gPiA+ID4+ID09PT09PT09DQo+ID4gPiA+Pg0KPiA+ID4g Pj4+IEl0IHNhaWQgaW4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1z ZmMtbnNoLTA0KToNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ICAgICAgVGhlIHNlcnZpY2UgaGVhZGVy IGlzIGluZGVwZW5kZW50IG9mIHRoZSBlbmNhcHN1bGF0aW9uIHVzZWQgYW5kDQo+IGlzDQo+ID4g PiA+Pj4gICAgICBlbmNhcHN1bGF0ZWQgaW4gZXhpc3RpbmcgdHJhbnNwb3J0cy4gIFRoZSBwcmVz ZW5jZSBvZiBOU0ggaXMNCj4gPiA+ID4+PiAgICAgIGluZGljYXRlZCB2aWEgcHJvdG9jb2wgdHlw ZSBvciBvdGhlciBpbmRpY2F0b3IgaW4gdGhlIG91dGVyDQo+ID4gPiA+Pj4gICAgICBlbmNhcHN1 bGF0aW9uLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gSW4gdGhlIGNhc2Ugd2hlcmUgdGhlIG91dGVy IGVuY2Fwc3VsYXRpb24gaXMgYW4gTVBMUyBMU1AsIGhvdyB0bw0KPiA+ID4gPj4+IGluZGljYXRl IHRoZQ0KPiA+ID4gPj4gcHJlc2VuY2Ugb2YgTlNIIHNpbmNlIHRoZSBNUExTIGVuY2Fwc3VsYXRp b24gaGFzIG5vIGV4cGxpY2l0DQo+ID4gPiA+PiBwcm90b2NvbCBpZGVudGlmaWVyIGZpZWxkIHRv IGluZGljYXRlIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBNUExTDQo+ID4gcGF5bG9hZD8NCj4g PiA+ID4+IFNob3VsZCB3ZSBtYWtlIGVhY2ggU0ZGIHRvIGFsbG9jYXRlIGEgdW5pcXVlIGxhYmVs IGZvciBpbmRpY2F0aW5nDQo+ID4gPiA+PiB0aGUgcHJlc2VuY2Ugb2YgTlNIPyBPciBzaG91bGQg d2UgdXNlIHRoZSBjb250cm9sIHdvcmQgdG8gaW5kaWNhdGUNCj4gPiA+ID4+IGl0PyBPciBzaG91 bGQgd2UgcmVjb25zaWRlciB0aGUgcG9zc2liaWxpdHkgb2YgYWRkaW5nIGFuIGV4cGxpY2l0DQo+ ID4gPiA+PiBwcm90b2NvbCBpZGVudGlmaWVyIGZpZWxkIHRvIHRoZSBNUExTIGVuY2Fwc3VsYXRp b24gc28gYXMgdG8gc29sdmUNCj4gPiA+ID4+IHN1Y2gga2luZCBvZiBpc3N1ZXMNCj4gPiA+IG9u Y2UgYW5kIGZvciBhbGw/DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4g PiA+Pj4gWGlhb2h1DQo+ID4gPiA+Pj4NCj4gPiA+ID4+DQo+ID4gPiA+Pg0KPiA+ID4gPj4gLS0N Cj4gPiA+ID4+DQo+ID4gPg0KPiA+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCj4gPiAqKioNCj4gPiA+ID4+ICoqKioNCj4gPiA+ID4+ ICAgICAgICAgICAgICAgICDH67zH16GjrMTjyse2wNK7zt62/rXEo6y+zc/xxuTL+8O/0ru49sjL 0rvR+Q0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+ID4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBtcGxzQGlldGYub3JnDQo+ ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ID4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4g PiBzZmMgbWFpbGluZyBsaXN0DQo+ID4gPiA+IHNmY0BpZXRmLm9yZw0KPiA+ID4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+ IC0tDQo+ID4gPg0KPiA+ID4NCj4gPiA+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAg ICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+ID4gPiBTZW5pb3IgTVBMUyBFeHBl cnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPiA+ID4gSHVhd2VpIFRlY2hu b2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo= From nobody Tue Jan 27 02:03:16 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0EC1A875C; Tue, 27 Jan 2015 02:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.783 X-Spam-Level: X-Spam-Status: No, score=0.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVh4ygmKBVob; Tue, 27 Jan 2015 02:03:03 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24D11A875A; Tue, 27 Jan 2015 02:03:01 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D49C4180155B; Tue, 27 Jan 2015 11:02:58 +0100 (CET) Message-ID: <54C7624B.3080309@pi.nu> Date: Tue, 27 Jan 2015 18:02:51 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Xuxiaohu , Alexander Vainshtein References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 10:03:09 -0000 Sasha, (correct me if I'm wrong) I thnk you say that there are tow cases - you can infer from the NSH everything you need to treat the SFC packet correct - you need more information than the NSH In the first case you can the label at the BoS just need to point out that the NSH is present and the rest is done based on the HSH There are two cases here also - you assign the label that points to the NSH tLDP style and it is signaled between the egress and ingress LSR - you assign a ESPL and you don't need the signaling. In the second case you need the application label to point out how the and the correct handling of the NSH should be done. In this case you need the signaling? /Loa On 2015-01-27 16:58, Xuxiaohu wrote: > Hi Sasha, > > If only one application label is required to be inserted into the label stack, where should it be inserted? at the BoS? If so, it seems that the application label must be an ESP label. > > Best regards, > Xiaohu > >> -----Original Message----- >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Tuesday, January 27, 2015 4:46 PM >> To: Xuxiaohu >> Cc: mpls@ietf.org; sfc@ietf.org; Loa Andersson >> Subject: RE: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? >> >> Xiaoh hi! >> I do not think you need multiple application labels. >> Rather, you could swap these labels as the packet progresses along the SFP, same >> as is done with MS-PWs. >> >> Regards, >> Sasha >> Email: Alexander.Vainshtein@ecitele.com >> Mobile: 054-9266302 >> >> >>> -----Original Message----- >>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >>> Sent: Tuesday, January 27, 2015 9:46 AM >>> To: Loa Andersson; Alexander Vainshtein >>> Cc: mpls@ietf.org; sfc@ietf.org >>> Subject: RE: [sfc] [mpls] How to indicate the presence of NSH in an MPLS >>> packet? >>> >>> >>> >>>> -----Original Message----- >>>> From: Loa Andersson [mailto:loa@pi.nu] >>>> Sent: Tuesday, January 27, 2015 2:28 PM >>>> To: Alexander Vainshtein; Xuxiaohu >>>> Cc: mpls@ietf.org; sfc@ietf.org >>>> Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS >>> packet? >>>> >>>> Sasha, >>>> >>>> >>>> >>>> On 2015-01-26 14:21, Alexander Vainshtein wrote: >>>>> Xiaohu, Huub, >>>>> I do not follow the SFC work closely, so I would like to understand >>>>> whether the >>>> NSH should be captured by transit LSRs on the LSP - or just by the >>>> LER acting as the LSP tail-end? >>>>> >>>>> If the latter is correct, the simplest way to indicate presence of >>>>> the NSH in the >>>> MPLS payload would be by allocating an "application label" indicating >>>> its presence by the tail-end LER and by inserting it at the bottom of >>>> the label stack by the head-end LER - similar to what is done for >>>> L2/L3VPN. Within this approach, if label-based demultiplexing of >>>> packets with NSH in the MPLS payload is not required, you could >>>> request allocation of a new special purpose label from the extended >>>> special purposes label space as per RFC 7274, and to insert such a label >>> (preceded by the Extension Label ) at the BoS. >>>>> >>>> I think "the latter" is correct, the only issue I see is adding one >>>> more label stack entry to the label stack. >>> >>> Yes, the latter is correct. The issue of adding one more label stack entry to >>> the label stack may become unacceptable in the case where the Service >>> Function Path (SFP) is represented by an label stack while the NSH is now >>> only used as a metadata container. For example, for an SFP consist of n SFs, n >>> "application labels" would have to be inserted into the label stack. >>> >>> Best regards, >>> Xiaohu >>> >>>> /Loa >>>>> If the former is correct, the process above still has to be used but >>>>> it has to be >>>> augmented by adding the Router Alert Label at the top of the label stack. >>>>> >>>>> From my POV these suggestions are in line with the provisions of >>>>> Section 2.2 >>>> of RFC 3032 "Determining the Network Layer Protocol" that states: >>>>> >>>>> >>>>> When the last label is popped from a packet's label stack (resulting >>>>> in the stack being emptied), further processing of the packet is >>>>> based on the packet's network layer header. The LSR which pops >> the >>>>> last label off the stack must therefore be able to identify the >>>>> packet's network layer protocol. However, the label stack does not >>>>> contain any field which explicitly identifies the network layer >>>>> protocol. This means that the identity of the network layer protocol >>>>> must be inferable from the value of the label which is popped from >>>>> the bottom of the stack, possibly along with the contents of the >>>>> network layer header itself. >>>>> >>>>> >>>>> My 2c, >>>>> Sasha >>>>> ________________________________________ >>>>> From: mpls on behalf of Xuxiaohu >>>>> >>>>> Sent: Monday, January 26, 2015 5:05 AM >>>>> To: huubatwork@gmail.com; sfc@ietf.org; mpls@ietf.org >>>>> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS >>> packet? >>>>> >>>>> Hi Huub, >>>>> >>>>> The alter label itself couldn¡¯t make the receiving LSR to determine >>>>> the MPLS >>>> payload type by examining the MPLS payload. >>>>> >>>>> Best regards, >>>>> Xiaohu >>>>> >>>>>> -----Original Message----- >>>>>> From: Huub van Helvoort [mailto:huubatwork@gmail.com] >>>>>> Sent: Friday, January 23, 2015 6:28 PM >>>>>> To: Xuxiaohu; sfc@ietf.org; mpls@ietf.org >>>>>> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS >>> packet? >>>>>> >>>>>> Xuxiaohu ÄúºÃ£¡ >>>>>> >>>>>> Please correct me if I am wrong: >>>>>> >>>>>> It has always been my understanding that the MPLS header/label was >>>>>> independent of the protocol/payload. >>>>>> So no indication of the actual payload content was necessary. >>>>>> >>>>>> IMHO you could use the alert label 1 to indicate to the LSR that it >>>>>> has to further examine the content of a packet. >>>>>> >>>>>> Regards, Huub. >>>>>> >>>>>> ======== >>>>>> >>>>>>> It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04): >>>>>>> >>>>>>> The service header is independent of the encapsulation used and >> is >>>>>>> encapsulated in existing transports. The presence of NSH is >>>>>>> indicated via protocol type or other indicator in the outer >>>>>>> encapsulation. >>>>>>> >>>>>>> In the case where the outer encapsulation is an MPLS LSP, how to >>>>>>> indicate the >>>>>> presence of NSH since the MPLS encapsulation has no explicit >>>>>> protocol identifier field to indicate the protocol type of the MPLS >>> payload? >>>>>> Should we make each SFF to allocate a unique label for indicating >>>>>> the presence of NSH? Or should we use the control word to indicate >>>>>> it? Or should we reconsider the possibility of adding an explicit >>>>>> protocol identifier field to the MPLS encapsulation so as to solve >>>>>> such kind of issues >>>> once and for all? >>>>>>> >>>>>>> Best regards, >>>>>>> Xiaohu >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>> >>> ********************************************************** >>> *** >>>>>> **** >>>>>> Çë¼Çס£¬ÄãÊǶÀÒ»ÎÞ¶þµÄ£¬¾ÍÏñÆäËûÿһ¸öÈËÒ»Ñù >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Jan 27 04:16:08 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8431B2BA8; Mon, 26 Jan 2015 23:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWnahzzuKYwE; Mon, 26 Jan 2015 23:29:44 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609991A88E2; Mon, 26 Jan 2015 23:29:43 -0800 (PST) Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0810.eurprd03.prod.outlook.com (25.161.55.142) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 07:27:38 +0000 Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 07:27:38 +0000 From: Alexander Vainshtein To: Xuxiaohu Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegARJH4AAIdmfAAABiq6FgAz0J4AAAFTF/U= Date: Tue, 27 Jan 2015 07:27:38 +0000 Message-ID: <1422343655626.35892@ecitele.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.40.145.154] authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ecitele.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR03MB0810; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0810; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(19580405001)(102836002)(15975445007)(2900100001)(2950100001)(19580395003)(117636001)(76176999)(54356999)(50986999)(77156002)(92566002)(62966003)(2656002)(87936001)(46102003)(93886004)(40100003)(66066001)(122556002)(36756003)(110136001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0810; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 07:27:38.1329 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0810 Archived-At: X-Mailman-Approved-At: Tue, 27 Jan 2015 04:16:06 -0800 Cc: "mpls@ietf.org" , "sfc@ietf.org" , "huubatwork@gmail.com" Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 07:29:46 -0000 WGlhb2h1LApSZWdhcmRpbmcgeW91ciBxdWVzdGlvbjogIldoYXQncyB0aGUgcHVycG9zZSBvZiBp bnNlcnRpbmcgYSBwYXJ0aWN1bGFyIEVTUCBsYWJlbCBhdCB0aGUgQm9TPyIgCgpUaGlzIGlzIGFu IGFsdGVybmF0aXZlIHRvIGVhY2ggU0ZGIGFsbG9jYXRpbmcgYSB1bmlxdWUgYXBwbGljYXRpb24g bGFiZWwuIApUaGlzIGFsdGVybmF0aXZlIHdvdWxkIHdvcmsgaWYgZGVtdWx0aXBsZXhpbmcgb2Yg YSByZWNlaXZlZCBsYWJlbGVkIHBhY2tldCB3aXRoIE5TSCBoZWFkZXIgdG8gYSBzcGVjaWZpYyBT U0Ygd2l0aGluIHRoZSBwcm9jZXNzaW5nIG5vZGUgY2FuIGJlIGRvbmUgYmFzZWQgb24gdGhlIE5T SCBvbmx5LgpTYXZlcyB5b3UgdGhlIG5lZWQgdG8gYWxsb2NhdGUgYW5kIGRpc3RyaWJ1dGUgcGVy IFNTRiBsYWJlbHMuCgpIb3BlZnVsbHkgdGhpcyBhbnN3ZXJzIHlvdXIgcXVlc3Rpb24uCgpSZWdh cmRzLApTYXNoYSAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJv bTogWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+ClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkg MjcsIDIwMTUgODo0NSBBTQpUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IGh1dWJhdHdvcmtAZ21h aWwuY29tCkNjOiBzZmNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcKU3ViamVjdDogUkU6IFttcGxz XSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTIHBhY2tldD8K CkhpIFNhc2hhLAoKPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IEFsZXhhbmRl ciBWYWluc2h0ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dCj4g U2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDI6MjIgUE0KPiBUbzogWHV4aWFvaHU7IGh1 dWJhdHdvcmtAZ21haWwuY29tCj4gQ2M6IHNmY0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZwo+IFN1 YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4g YW4gTVBMUyBwYWNrZXQ/Cj4KPiBYaWFvaHUsIEh1dWIsCj4gSSBkbyBub3QgZm9sbG93IHRoZSBT RkMgd29yayBjbG9zZWx5LCBzbyBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCB3aGV0aGVyIHRo ZQo+IE5TSCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRyYW5zaXQgTFNScyBvbiB0aGUgTFNQIC0g b3IganVzdCBieSB0aGUgTEVSIGFjdGluZyBhcwo+IHRoZSBMU1AgdGFpbC1lbmQ/Cj4KPiBJZiB0 aGUgbGF0dGVyIGlzIGNvcnJlY3QsIHRoZSBzaW1wbGVzdCB3YXkgdG8gaW5kaWNhdGUgcHJlc2Vu Y2Ugb2YgdGhlIE5TSCBpbiB0aGUKPiBNUExTIHBheWxvYWQgd291bGQgYmUgYnkgYWxsb2NhdGlu ZyBhbiAiYXBwbGljYXRpb24gbGFiZWwiIGluZGljYXRpbmcgaXRzCj4gcHJlc2VuY2UgYnkgdGhl IHRhaWwtZW5kIExFUiBhbmQgYnkgaW5zZXJ0aW5nIGl0IGF0IHRoZSBib3R0b20gb2YgdGhlIGxh YmVsIHN0YWNrCj4gYnkgdGhlIGhlYWQtZW5kIExFUiAtIHNpbWlsYXIgdG8gd2hhdCBpcyBkb25l IGZvciBMMi9MM1ZQTi4gIFdpdGhpbiB0aGlzCgpJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdCwg dGhlIGFib3ZlIGFwcHJvYWNoIGlzIHRoZSBzYW1lIGFzIG9wdGlvbiAxIGFzIEkgbWVudGlvbmVk IGluIHRoZSBlYXJsaWVyIGVtYWlsIChpLmUuLCBtYWtpbmcgZWFjaCBTRkYgdG8gYWxsb2NhdGUg YSB1bmlxdWUgbGFiZWwgZm9yIGluZGljYXRpbmcgdGhlCnByZXNlbmNlIG9mIE5TSCkuCgo+IGFw cHJvYWNoLCBpZiBsYWJlbC1iYXNlZCBkZW11bHRpcGxleGluZyBvZiAgcGFja2V0cyB3aXRoIE5T SCBpbiB0aGUgTVBMUwo+IHBheWxvYWQgaXMgbm90IHJlcXVpcmVkLCB5b3UgY291bGQgcmVxdWVz dCBhbGxvY2F0aW9uIG9mIGEgbmV3IHNwZWNpYWwgcHVycG9zZQo+IGxhYmVsIGZyb20gdGhlIGV4 dGVuZGVkIHNwZWNpYWwgcHVycG9zZXMgbGFiZWwgc3BhY2UgYXMgcGVyIFJGQyA3Mjc0LCBhbmQg dG8KPiBpbnNlcnQgc3VjaCBhIGxhYmVsIChwcmVjZWRlZCBieSB0aGUgRXh0ZW5zaW9uIExhYmVs ICkgYXQgdGhlIEJvUy4KCldoYXQncyB0aGUgcHVycG9zZSBvZiBpbnNlcnRpbmcgYSBwYXJ0aWN1 bGFyIEVTUCBsYWJlbCBhdCB0aGUgQm9TPwoKQmVzdCByZWdhcmRzLApYaWFvaHUKCj4gSWYgdGhl IGZvcm1lciBpcyBjb3JyZWN0LCB0aGUgcHJvY2VzcyBhYm92ZSBzdGlsbCBoYXMgdG8gYmUgdXNl ZCBidXQgaXQgaGFzIHRvIGJlCj4gYXVnbWVudGVkIGJ5IGFkZGluZyB0aGUgUm91dGVyIEFsZXJ0 IExhYmVsICAgYXQgdGhlIHRvcCBvZiB0aGUgbGFiZWwgc3RhY2suCj4KPiBGcm9tIG15IFBPViB0 aGVzZSBzdWdnZXN0aW9ucyBhcmUgaW4gbGluZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIFNlY3Rp b24gMi4yIG9mCj4gUkZDIDMwMzIgIkRldGVybWluaW5nIHRoZSBOZXR3b3JrIExheWVyIFByb3Rv Y29sIiB0aGF0IHN0YXRlczoKPgo+IDxxdW90ZT4KPiAgICBXaGVuIHRoZSBsYXN0IGxhYmVsIGlz IHBvcHBlZCBmcm9tIGEgcGFja2V0J3MgbGFiZWwgc3RhY2sgKHJlc3VsdGluZwo+ICAgIGluIHRo ZSBzdGFjayBiZWluZyBlbXB0aWVkKSwgZnVydGhlciBwcm9jZXNzaW5nIG9mIHRoZSBwYWNrZXQg aXMKPiAgICBiYXNlZCBvbiB0aGUgcGFja2V0J3MgbmV0d29yayBsYXllciBoZWFkZXIuICBUaGUg TFNSIHdoaWNoIHBvcHMgdGhlCj4gICAgbGFzdCBsYWJlbCBvZmYgdGhlIHN0YWNrIG11c3QgdGhl cmVmb3JlIGJlIGFibGUgdG8gaWRlbnRpZnkgdGhlCj4gICAgcGFja2V0J3MgbmV0d29yayBsYXll ciBwcm90b2NvbC4gIEhvd2V2ZXIsIHRoZSBsYWJlbCBzdGFjayBkb2VzIG5vdAo+ICAgIGNvbnRh aW4gYW55IGZpZWxkIHdoaWNoIGV4cGxpY2l0bHkgaWRlbnRpZmllcyB0aGUgbmV0d29yayBsYXll cgo+ICAgIHByb3RvY29sLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBpZGVudGl0eSBvZiB0aGUgbmV0 d29yayBsYXllciBwcm90b2NvbAo+ICAgIG11c3QgYmUgaW5mZXJhYmxlIGZyb20gdGhlIHZhbHVl IG9mIHRoZSBsYWJlbCB3aGljaCBpcyBwb3BwZWQgZnJvbQo+ICAgIHRoZSBib3R0b20gb2YgdGhl IHN0YWNrLCBwb3NzaWJseSBhbG9uZyB3aXRoIHRoZSBjb250ZW50cyBvZiB0aGUKPiAgICBuZXR3 b3JrIGxheWVyIGhlYWRlciBpdHNlbGYuCj4gPGVuZCBxdW90ZT4KPgo+IE15IDJjLAo+IFNhc2hh Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IEZyb206IG1wbHMg PG1wbHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFh1eGlhb2h1Cj4gPHh1eGlhb2h1 QGh1YXdlaS5jb20+Cj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDU6MDUgQU0KPiBU bzogaHV1YmF0d29ya0BnbWFpbC5jb207IHNmY0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZwo+IFN1 YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4g YW4gTVBMUyBwYWNrZXQ/Cj4KPiBIaSBIdXViLAo+Cj4gVGhlIGFsdGVyIGxhYmVsIGl0c2VsZiBj b3VsZG6hr3QgbWFrZSB0aGUgcmVjZWl2aW5nIExTUiB0byBkZXRlcm1pbmUgdGhlIE1QTFMKPiBw YXlsb2FkIHR5cGUgYnkgZXhhbWluaW5nIHRoZSBNUExTIHBheWxvYWQuCj4KPiBCZXN0IHJlZ2Fy ZHMsCj4gWGlhb2h1Cj4KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gPiBGcm9tOiBI dXViIHZhbiBIZWx2b29ydCBbbWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tXQo+ID4gU2VudDog RnJpZGF5LCBKYW51YXJ5IDIzLCAyMDE1IDY6MjggUE0KPiA+IFRvOiBYdXhpYW9odTsgc2ZjQGll dGYub3JnOyBtcGxzQGlldGYub3JnCj4gPiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRp Y2F0ZSB0aGUgcHJlc2VuY2Ugb2YgTlNIIGluIGFuIE1QTFMgcGFja2V0Pwo+ID4KPiA+IFh1eGlh b2h1IMT6usOjoQo+ID4KPiA+IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3Jvbmc6Cj4gPgo+ ID4gSXQgaGFzIGFsd2F5cyBiZWVuIG15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgTVBMUyBoZWFk ZXIvbGFiZWwgd2FzCj4gPiBpbmRlcGVuZGVudCBvZiB0aGUgcHJvdG9jb2wvcGF5bG9hZC4KPiA+ IFNvIG5vIGluZGljYXRpb24gb2YgdGhlIGFjdHVhbCBwYXlsb2FkIGNvbnRlbnQgd2FzIG5lY2Vz c2FyeS4KPiA+Cj4gPiBJTUhPIHlvdSBjb3VsZCB1c2UgdGhlIGFsZXJ0IGxhYmVsIDEgdG8gaW5k aWNhdGUgdG8gdGhlIExTUiB0aGF0IGl0Cj4gPiBoYXMgdG8gZnVydGhlciBleGFtaW5lIHRoZSBj b250ZW50IG9mIGEgcGFja2V0Lgo+ID4KPiA+IFJlZ2FyZHMsIEh1dWIuCj4gPgo+ID4gPT09PT09 PT0KPiA+Cj4gPiA+IEl0IHNhaWQgaW4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1xdWlubi1zZmMtbnNoLTA0KToKPiA+ID4KPiA+ID4gICAgIFRoZSBzZXJ2aWNlIGhlYWRlciBp cyBpbmRlcGVuZGVudCBvZiB0aGUgZW5jYXBzdWxhdGlvbiB1c2VkIGFuZCBpcwo+ID4gPiAgICAg ZW5jYXBzdWxhdGVkIGluIGV4aXN0aW5nIHRyYW5zcG9ydHMuICBUaGUgcHJlc2VuY2Ugb2YgTlNI IGlzCj4gPiA+ICAgICBpbmRpY2F0ZWQgdmlhIHByb3RvY29sIHR5cGUgb3Igb3RoZXIgaW5kaWNh dG9yIGluIHRoZSBvdXRlcgo+ID4gPiAgICAgZW5jYXBzdWxhdGlvbi4KPiA+ID4KPiA+ID4gSW4g dGhlIGNhc2Ugd2hlcmUgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24gaXMgYW4gTVBMUyBMU1AsIGhv dyB0bwo+ID4gPiBpbmRpY2F0ZSB0aGUKPiA+IHByZXNlbmNlIG9mIE5TSCBzaW5jZSB0aGUgTVBM UyBlbmNhcHN1bGF0aW9uIGhhcyBubyBleHBsaWNpdCBwcm90b2NvbAo+ID4gaWRlbnRpZmllciBm aWVsZCB0byBpbmRpY2F0ZSB0aGUgcHJvdG9jb2wgdHlwZSBvZiB0aGUgTVBMUyBwYXlsb2FkPwo+ ID4gU2hvdWxkIHdlIG1ha2UgZWFjaCBTRkYgdG8gYWxsb2NhdGUgYSB1bmlxdWUgbGFiZWwgZm9y IGluZGljYXRpbmcgdGhlCj4gPiBwcmVzZW5jZSBvZiBOU0g/IE9yIHNob3VsZCB3ZSB1c2UgdGhl IGNvbnRyb2wgd29yZCB0byBpbmRpY2F0ZSBpdD8gT3IKPiA+IHNob3VsZCB3ZSByZWNvbnNpZGVy IHRoZSBwb3NzaWJpbGl0eSBvZiBhZGRpbmcgYW4gZXhwbGljaXQgcHJvdG9jb2wKPiA+IGlkZW50 aWZpZXIgZmllbGQgdG8gdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBzbyBhcyB0byBzb2x2ZSBzdWNo IGtpbmQgb2YgaXNzdWVzCj4gb25jZSBhbmQgZm9yIGFsbD8KPiA+ID4KPiA+ID4gQmVzdCByZWdh cmRzLAo+ID4gPiBYaWFvaHUKPiA+ID4KPiA+Cj4gPgo+ID4gLS0KPiA+Cj4gKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo+ID4gKioq Kgo+ID4gICAgICAgICAgICAgICAgx+u8x9eho6zE48rHtsDSu87etv61xKOsvs3P8cbky/vDv9K7 uPbIy9K70fkKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+IG1wbHMgbWFpbGluZyBsaXN0Cj4gbXBsc0BpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscwo= From nobody Tue Jan 27 04:16:12 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C511A8750; Tue, 27 Jan 2015 00:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em8Aq9upfpWG; Tue, 27 Jan 2015 00:46:01 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8AD1A8A11; Tue, 27 Jan 2015 00:45:53 -0800 (PST) Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0810.eurprd03.prod.outlook.com (25.161.55.142) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 08:45:30 +0000 Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 08:45:30 +0000 From: Alexander Vainshtein To: Xuxiaohu Thread-Topic: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegARJH4AAIdmfAAABiq6FgAzM48AAAK7wgAAAgCbEA== Date: Tue, 27 Jan 2015 08:45:30 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ecitele.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR03MB0810; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0810; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377424004)(252514010)(377454003)(46102003)(74316001)(2656002)(87936001)(122556002)(86362001)(110136001)(40100003)(93886004)(76576001)(66066001)(19580395003)(2950100001)(19580405001)(15975445007)(102836002)(2900100001)(92566002)(54606007)(62966003)(54356999)(76176999)(33656002)(54206007)(77156002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0810; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 08:45:30.6177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0810 Archived-At: X-Mailman-Approved-At: Tue, 27 Jan 2015 04:16:06 -0800 Cc: "mpls@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 08:46:04 -0000 WGlhb2ggaGkhDQpJIGRvIG5vdCB0aGluayB5b3UgbmVlZCBtdWx0aXBsZSBhcHBsaWNhdGlvbiBs YWJlbHMuIA0KUmF0aGVyLCB5b3UgY291bGQgc3dhcCB0aGVzZSBsYWJlbHMgYXMgdGhlIHBhY2tl dCBwcm9ncmVzc2VzIGFsb25nIHRoZSBTRlAsIHNhbWUgYXMgaXMgZG9uZSB3aXRoIE1TLVBXcy4N Cg0KUmVnYXJkcywNCiAgICAgICBTYXNoYSANCkVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbQ0KTW9iaWxlOiAwNTQtOTI2NjMwMg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogWHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXQ0K PiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1IDk6NDYgQU0NCj4gVG86IExvYSBBbmRl cnNzb247IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+IENjOiBtcGxzQGlldGYub3JnOyBzZmNAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtzZmNdIFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHBy ZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTDQo+IHBhY2tldD8NCj4gDQo+IA0KPiANCj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzps b2FAcGkubnVdDQo+ID4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNywgMjAxNSAyOjI4IFBNDQo+ ID4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBYdXhpYW9odQ0KPiA+IENjOiBtcGxzQGlldGYu b3JnOyBzZmNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW3NmY10gW21wbHNdIEhvdyB0byBp bmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2YgTlNIIGluIGFuIE1QTFMNCj4gcGFja2V0Pw0KPiA+DQo+ ID4gU2FzaGEsDQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gMjAxNS0wMS0yNiAxNDoyMSwgQWxleGFu ZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQo+ID4gPiBYaWFvaHUsIEh1dWIsDQo+ID4gPiBJIGRvIG5v dCBmb2xsb3cgdGhlIFNGQyB3b3JrIGNsb3NlbHksIHNvIEkgd291bGQgbGlrZSB0byB1bmRlcnN0 YW5kDQo+ID4gPiB3aGV0aGVyIHRoZQ0KPiA+IE5TSCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRy YW5zaXQgTFNScyBvbiB0aGUgTFNQIC0gb3IganVzdCBieSB0aGUNCj4gPiBMRVIgYWN0aW5nIGFz IHRoZSBMU1AgdGFpbC1lbmQ/DQo+ID4gPg0KPiA+ID4gSWYgdGhlIGxhdHRlciBpcyBjb3JyZWN0 LCB0aGUgc2ltcGxlc3Qgd2F5IHRvIGluZGljYXRlIHByZXNlbmNlIG9mDQo+ID4gPiB0aGUgTlNI IGluIHRoZQ0KPiA+IE1QTFMgcGF5bG9hZCB3b3VsZCBiZSBieSBhbGxvY2F0aW5nIGFuICJhcHBs aWNhdGlvbiBsYWJlbCIgaW5kaWNhdGluZw0KPiA+IGl0cyBwcmVzZW5jZSBieSB0aGUgdGFpbC1l bmQgTEVSIGFuZCBieSBpbnNlcnRpbmcgaXQgYXQgdGhlIGJvdHRvbSBvZg0KPiA+IHRoZSBsYWJl bCBzdGFjayBieSB0aGUgaGVhZC1lbmQgTEVSIC0gc2ltaWxhciB0byB3aGF0IGlzIGRvbmUgZm9y DQo+ID4gTDIvTDNWUE4uICBXaXRoaW4gdGhpcyBhcHByb2FjaCwgaWYgbGFiZWwtYmFzZWQgZGVt dWx0aXBsZXhpbmcgb2YNCj4gPiBwYWNrZXRzIHdpdGggTlNIIGluIHRoZSBNUExTIHBheWxvYWQg aXMgbm90IHJlcXVpcmVkLCB5b3UgY291bGQNCj4gPiByZXF1ZXN0IGFsbG9jYXRpb24gb2YgYSBu ZXcgc3BlY2lhbCBwdXJwb3NlIGxhYmVsIGZyb20gdGhlIGV4dGVuZGVkDQo+ID4gc3BlY2lhbCBw dXJwb3NlcyBsYWJlbCBzcGFjZSBhcyBwZXIgUkZDIDcyNzQsIGFuZCB0byBpbnNlcnQgc3VjaCBh IGxhYmVsDQo+IChwcmVjZWRlZCBieSB0aGUgRXh0ZW5zaW9uIExhYmVsICkgYXQgdGhlIEJvUy4N Cj4gPiA+DQo+ID4gSSB0aGluayAidGhlIGxhdHRlciIgaXMgY29ycmVjdCwgdGhlIG9ubHkgaXNz dWUgSSBzZWUgaXMgYWRkaW5nIG9uZQ0KPiA+IG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8gdGhl IGxhYmVsIHN0YWNrLg0KPiANCj4gWWVzLCB0aGUgbGF0dGVyIGlzIGNvcnJlY3QuIFRoZSBpc3N1 ZSBvZiBhZGRpbmcgb25lIG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8NCj4gdGhlIGxhYmVsIHN0 YWNrIG1heSBiZWNvbWUgdW5hY2NlcHRhYmxlIGluIHRoZSBjYXNlIHdoZXJlIHRoZSBTZXJ2aWNl DQo+IEZ1bmN0aW9uIFBhdGggKFNGUCkgaXMgcmVwcmVzZW50ZWQgYnkgYW4gbGFiZWwgc3RhY2sg d2hpbGUgdGhlIE5TSCBpcyBub3cNCj4gb25seSB1c2VkIGFzIGEgbWV0YWRhdGEgY29udGFpbmVy LiBGb3IgZXhhbXBsZSwgZm9yIGFuIFNGUCBjb25zaXN0IG9mIG4gU0ZzLCBuDQo+ICJhcHBsaWNh dGlvbiBsYWJlbHMiIHdvdWxkIGhhdmUgdG8gYmUgaW5zZXJ0ZWQgaW50byB0aGUgbGFiZWwgc3Rh Y2suDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAvTG9hDQo+ID4gPiBJ ZiB0aGUgZm9ybWVyIGlzIGNvcnJlY3QsIHRoZSBwcm9jZXNzIGFib3ZlIHN0aWxsIGhhcyB0byBi ZSB1c2VkIGJ1dA0KPiA+ID4gaXQgaGFzIHRvIGJlDQo+ID4gYXVnbWVudGVkIGJ5IGFkZGluZyB0 aGUgUm91dGVyIEFsZXJ0IExhYmVsICAgYXQgdGhlIHRvcCBvZiB0aGUgbGFiZWwgc3RhY2suDQo+ ID4gPg0KPiA+ID4gIEZyb20gbXkgUE9WIHRoZXNlIHN1Z2dlc3Rpb25zIGFyZSBpbiBsaW5lIHdp dGggdGhlIHByb3Zpc2lvbnMgb2YNCj4gPiA+IFNlY3Rpb24gMi4yDQo+ID4gb2YgUkZDIDMwMzIg IkRldGVybWluaW5nIHRoZSBOZXR3b3JrIExheWVyIFByb3RvY29sIiB0aGF0IHN0YXRlczoNCj4g PiA+DQo+ID4gPiA8cXVvdGU+DQo+ID4gPiAgICAgV2hlbiB0aGUgbGFzdCBsYWJlbCBpcyBwb3Bw ZWQgZnJvbSBhIHBhY2tldCdzIGxhYmVsIHN0YWNrIChyZXN1bHRpbmcNCj4gPiA+ICAgICBpbiB0 aGUgc3RhY2sgYmVpbmcgZW1wdGllZCksIGZ1cnRoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0 IGlzDQo+ID4gPiAgICAgYmFzZWQgb24gdGhlIHBhY2tldCdzIG5ldHdvcmsgbGF5ZXIgaGVhZGVy LiAgVGhlIExTUiB3aGljaCBwb3BzIHRoZQ0KPiA+ID4gICAgIGxhc3QgbGFiZWwgb2ZmIHRoZSBz dGFjayBtdXN0IHRoZXJlZm9yZSBiZSBhYmxlIHRvIGlkZW50aWZ5IHRoZQ0KPiA+ID4gICAgIHBh Y2tldCdzIG5ldHdvcmsgbGF5ZXIgcHJvdG9jb2wuICBIb3dldmVyLCB0aGUgbGFiZWwgc3RhY2sg ZG9lcyBub3QNCj4gPiA+ICAgICBjb250YWluIGFueSBmaWVsZCB3aGljaCBleHBsaWNpdGx5IGlk ZW50aWZpZXMgdGhlIG5ldHdvcmsgbGF5ZXINCj4gPiA+ICAgICBwcm90b2NvbC4gIFRoaXMgbWVh bnMgdGhhdCB0aGUgaWRlbnRpdHkgb2YgdGhlIG5ldHdvcmsgbGF5ZXIgcHJvdG9jb2wNCj4gPiA+ ICAgICBtdXN0IGJlIGluZmVyYWJsZSBmcm9tIHRoZSB2YWx1ZSBvZiB0aGUgbGFiZWwgd2hpY2gg aXMgcG9wcGVkIGZyb20NCj4gPiA+ICAgICB0aGUgYm90dG9tIG9mIHRoZSBzdGFjaywgcG9zc2li bHkgYWxvbmcgd2l0aCB0aGUgY29udGVudHMgb2YgdGhlDQo+ID4gPiAgICAgbmV0d29yayBsYXll ciBoZWFkZXIgaXRzZWxmLg0KPiA+ID4gPGVuZCBxdW90ZT4NCj4gPiA+DQo+ID4gPiBNeSAyYywN Cj4gPiA+IFNhc2hhDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gPiBGcm9tOiBtcGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBYdXhpYW9odQ0KPiA+ID4gPHh1eGlhb2h1QGh1YXdlaS5jb20+DQo+ID4gPiBTZW50OiBNb25k YXksIEphbnVhcnkgMjYsIDIwMTUgNTowNSBBTQ0KPiA+ID4gVG86IGh1dWJhdHdvcmtAZ21haWwu Y29tOyBzZmNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbbXBs c10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBMUw0KPiBwYWNr ZXQ/DQo+ID4gPg0KPiA+ID4gSGkgSHV1YiwNCj4gPiA+DQo+ID4gPiBUaGUgYWx0ZXIgbGFiZWwg aXRzZWxmIGNvdWxkbqGvdCBtYWtlIHRoZSByZWNlaXZpbmcgTFNSIHRvIGRldGVybWluZQ0KPiA+ ID4gdGhlIE1QTFMNCj4gPiBwYXlsb2FkIHR5cGUgYnkgZXhhbWluaW5nIHRoZSBNUExTIHBheWxv YWQuDQo+ID4gPg0KPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gWGlhb2h1DQo+ID4gPg0KPiA+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPj4gRnJvbTogSHV1YiB2YW4gSGVs dm9vcnQgW21haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbV0NCj4gPiA+PiBTZW50OiBGcmlkYXks IEphbnVhcnkgMjMsIDIwMTUgNjoyOCBQTQ0KPiA+ID4+IFRvOiBYdXhpYW9odTsgc2ZjQGlldGYu b3JnOyBtcGxzQGlldGYub3JnDQo+ID4gPj4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5k aWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTDQo+IHBhY2tldD8NCj4gPiA+Pg0K PiA+ID4+IFh1eGlhb2h1IMT6usOjoQ0KPiA+ID4+DQo+ID4gPj4gUGxlYXNlIGNvcnJlY3QgbWUg aWYgSSBhbSB3cm9uZzoNCj4gPiA+Pg0KPiA+ID4+IEl0IGhhcyBhbHdheXMgYmVlbiBteSB1bmRl cnN0YW5kaW5nIHRoYXQgdGhlIE1QTFMgaGVhZGVyL2xhYmVsIHdhcw0KPiA+ID4+IGluZGVwZW5k ZW50IG9mIHRoZSBwcm90b2NvbC9wYXlsb2FkLg0KPiA+ID4+IFNvIG5vIGluZGljYXRpb24gb2Yg dGhlIGFjdHVhbCBwYXlsb2FkIGNvbnRlbnQgd2FzIG5lY2Vzc2FyeS4NCj4gPiA+Pg0KPiA+ID4+ IElNSE8geW91IGNvdWxkIHVzZSB0aGUgYWxlcnQgbGFiZWwgMSB0byBpbmRpY2F0ZSB0byB0aGUg TFNSIHRoYXQgaXQNCj4gPiA+PiBoYXMgdG8gZnVydGhlciBleGFtaW5lIHRoZSBjb250ZW50IG9m IGEgcGFja2V0Lg0KPiA+ID4+DQo+ID4gPj4gUmVnYXJkcywgSHV1Yi4NCj4gPiA+Pg0KPiA+ID4+ ID09PT09PT09DQo+ID4gPj4NCj4gPiA+Pj4gSXQgc2FpZCBpbiAoaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXF1aW5uLXNmYy1uc2gtMDQpOg0KPiA+ID4+Pg0KPiA+ID4+PiAgICAg IFRoZSBzZXJ2aWNlIGhlYWRlciBpcyBpbmRlcGVuZGVudCBvZiB0aGUgZW5jYXBzdWxhdGlvbiB1 c2VkIGFuZCBpcw0KPiA+ID4+PiAgICAgIGVuY2Fwc3VsYXRlZCBpbiBleGlzdGluZyB0cmFuc3Bv cnRzLiAgVGhlIHByZXNlbmNlIG9mIE5TSCBpcw0KPiA+ID4+PiAgICAgIGluZGljYXRlZCB2aWEg cHJvdG9jb2wgdHlwZSBvciBvdGhlciBpbmRpY2F0b3IgaW4gdGhlIG91dGVyDQo+ID4gPj4+ICAg ICAgZW5jYXBzdWxhdGlvbi4NCj4gPiA+Pj4NCj4gPiA+Pj4gSW4gdGhlIGNhc2Ugd2hlcmUgdGhl IG91dGVyIGVuY2Fwc3VsYXRpb24gaXMgYW4gTVBMUyBMU1AsIGhvdyB0bw0KPiA+ID4+PiBpbmRp Y2F0ZSB0aGUNCj4gPiA+PiBwcmVzZW5jZSBvZiBOU0ggc2luY2UgdGhlIE1QTFMgZW5jYXBzdWxh dGlvbiBoYXMgbm8gZXhwbGljaXQNCj4gPiA+PiBwcm90b2NvbCBpZGVudGlmaWVyIGZpZWxkIHRv IGluZGljYXRlIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBNUExTDQo+IHBheWxvYWQ/DQo+ID4g Pj4gU2hvdWxkIHdlIG1ha2UgZWFjaCBTRkYgdG8gYWxsb2NhdGUgYSB1bmlxdWUgbGFiZWwgZm9y IGluZGljYXRpbmcNCj4gPiA+PiB0aGUgcHJlc2VuY2Ugb2YgTlNIPyBPciBzaG91bGQgd2UgdXNl IHRoZSBjb250cm9sIHdvcmQgdG8gaW5kaWNhdGUNCj4gPiA+PiBpdD8gT3Igc2hvdWxkIHdlIHJl Y29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IG9mIGFkZGluZyBhbiBleHBsaWNpdA0KPiA+ID4+IHBy b3RvY29sIGlkZW50aWZpZXIgZmllbGQgdG8gdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBzbyBhcyB0 byBzb2x2ZQ0KPiA+ID4+IHN1Y2gga2luZCBvZiBpc3N1ZXMNCj4gPiBvbmNlIGFuZCBmb3IgYWxs Pw0KPiA+ID4+Pg0KPiA+ID4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4gPj4+IFhpYW9odQ0KPiA+ID4+ Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+PiAtLQ0KPiA+ID4+DQo+ID4NCj4gKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiAqKioNCj4g PiA+PiAqKioqDQo+ID4gPj4gICAgICAgICAgICAgICAgIMfrvMfXoaOsxOPKx7bA0rvO3rb+tcSj rL7Nz/HG5Mv7w7/Su7j2yMvSu9H5DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+IG1wbHNA aWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+IHNmYyBtYWlsaW5nIGxpc3QNCj4gPiA+IHNmY0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPiA+DQo+ID4NCj4gPiAtLQ0K PiA+DQo+ID4NCj4gPiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6 IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiA+IFNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAg ICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+ID4gSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3Vs dGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo= From nobody Tue Jan 27 04:16:13 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C821A879A; Tue, 27 Jan 2015 03:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VvhzuQ6TS8K; Tue, 27 Jan 2015 03:14:53 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E4C1A8794; Tue, 27 Jan 2015 03:14:52 -0800 (PST) Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 11:12:47 +0000 Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 11:12:47 +0000 From: Alexander Vainshtein To: Loa Andersson Thread-Topic: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegARJH4AAIdmfAAABiq6FgAzM48AAAK7wgAAAgCbEAAAiTyAAAI9soAAAjTwYA== Date: Tue, 27 Jan 2015 11:12:47 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> <54C7624B.3080309@pi.nu> In-Reply-To: <54C7624B.3080309@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] authentication-results: pi.nu; dkim=none (message not signed) header.d=none;pi.nu; dmarc=none action=none header.from=ecitele.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR03MB0812; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0812; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(252514010)(377454003)(377424004)(51704005)(77156002)(86362001)(93886004)(2950100001)(33656002)(2900100001)(54206007)(110136001)(62966003)(2656002)(76576001)(74316001)(92566002)(54356999)(76176999)(66066001)(15975445007)(102836002)(54606007)(87936001)(19580405001)(19580395003)(40100003)(122556002)(46102003)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0812; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 11:12:47.2278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0812 Archived-At: X-Mailman-Approved-At: Tue, 27 Jan 2015 04:16:06 -0800 Cc: "mpls@ietf.org" , Xuxiaohu , "sfc@ietf.org" Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 11:14:57 -0000 TG9hLA0KWW91ciBhbmFseXNpcyBpcyBhYnNvbHV0ZWx5IGNvcnJlY3QuIFRoZXJlIGFyZSB0d28g Y2FzZXMsIGFuZCBJIGRvIG5vdCBrbm93IHdoaWNoIG9uZSBpcyBhcHBsaWNhYmxlIHNpbmNlIGJ5 IGtub3dsZWRnZSBvZiBTRkMgaXMgbm9uLWV4aXN0ZW50Lg0KDQotIElmIHNwZWNpZmljIFNGIGlu c3RhbmNlIHdpdGhpbiB0aGUgbm9kZSBjYW4gYmUgaW5mZXJyZWQgZnJvbSB0aGUgTlNILCBhbmQg aWYgaXRzIHByb2Nlc3NpbmcgaW5jbHVkZXMgaWRlbnRpZmljYXRpb24gb2YgdGhlIG5leHQgaG9w IG9mIHRoZSBTRiBwYXRoLCB0aGVuIHdlIGNhbiB1c2UgRVNQTCwgYW5kIHRoZXJlIGlzIG5vIG5l ZWQgZm9yIHNpZ25hbGluZyAoc2luY2UgaXQgaXMgb25lIHZhbHVlIG9ubHkgYW5kICBpdHMgaW50 ZXJwcmV0YXRpb24gaXMgcHJlZGVmaW5lZCkuDQotIElmIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQg dGhlIGhhbmRsaW5nIGNhbm5vdCBiZSBpbmZlcnJlZCBmcm9tIHRoZSBOU0gsIGJlIGl0IHNwZWNp ZmljIFNGIGluc3RhbmNlIGluIHRoaXMgbm9kZSwgb3IgdGhlIG5leHQgaG9wIG9uIHRoZSBTRiBw YXRoIGFuZCB0aGUgU0YgaW5zdGFuY2Ugd2l0aGluIHRoaXMgbm9kZSwgb3IsIHBvc3NpYmx5LCBz b21lIGNvbWJpbmF0aW9uIG9mIHRob3NlLCB0aGVuIHlvdSBuZWVkIGFwcGxpY2F0aW9uIGxhYmVs cyBiZWluZyBhbGxvY2F0ZWQgYnkgdGhlIFNGIG5vZGVzIHdpdGggc29tZSBncmFudWxhcml0eSwg YW5kIHRoZWlyIGRpc3RyaWJ1dGlvbiB2aWEgc29tZSBmb3JtIG9mIHNpZ25hbGluZyAodExEUCBv ciBNUC1CR1AgY291bGQgYmUgdXNlZCkuICANCg0KUmVnYXJkcywNCiAgICAgICBTYXNoYSANCkVt YWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KTW9iaWxlOiAwNTQtOTI2NjMw Mg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG9hIEFuZGVyc3Nv biBbbWFpbHRvOmxvYUBwaS5udV0NCj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNywgMjAxNSAx MjowMyBQTQ0KPiBUbzogWHV4aWFvaHU7IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+IENjOiBtcGxz QGlldGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzZmNdIFttcGxzXSBIb3cg dG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTDQo+IHBhY2tldD8NCj4g DQo+IFNhc2hhLCAoY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcpDQo+IA0KPiBJIHRobmsgeW91IHNh eSB0aGF0IHRoZXJlIGFyZSB0b3cgY2FzZXMNCj4gDQo+IC0geW91IGNhbiBpbmZlciBmcm9tIHRo ZSBOU0ggZXZlcnl0aGluZyB5b3UgbmVlZCB0byB0cmVhdCB0aGUgU0ZDIHBhY2tldA0KPiAgICBj b3JyZWN0DQo+IC0geW91IG5lZWQgbW9yZSBpbmZvcm1hdGlvbiB0aGFuIHRoZSBOU0gNCj4gDQo+ IEluIHRoZSBmaXJzdCBjYXNlIHlvdSBjYW4gdGhlIGxhYmVsIGF0IHRoZSBCb1MganVzdCBuZWVk IHRvIHBvaW50IG91dCB0aGF0IHRoZQ0KPiBOU0ggaXMgcHJlc2VudCBhbmQgdGhlIHJlc3QgaXMg ZG9uZSBiYXNlZCBvbiB0aGUgSFNIDQo+IA0KPiBUaGVyZSBhcmUgdHdvIGNhc2VzIGhlcmUgYWxz bw0KPiAtIHlvdSBhc3NpZ24gdGhlIGxhYmVsIHRoYXQgcG9pbnRzIHRvIHRoZSBOU0ggdExEUCBz dHlsZSBhbmQgaXQgaXMNCj4gICAgc2lnbmFsZWQgYmV0d2VlbiB0aGUgZWdyZXNzIGFuZCBpbmdy ZXNzIExTUg0KPiAtIHlvdSBhc3NpZ24gYSBFU1BMIGFuZCB5b3UgZG9uJ3QgbmVlZCB0aGUgc2ln bmFsaW5nLg0KPiANCj4gSW4gdGhlIHNlY29uZCBjYXNlIHlvdSBuZWVkIHRoZSBhcHBsaWNhdGlv biBsYWJlbCB0byBwb2ludCBvdXQgaG93IHRoZSBhbmQNCj4gdGhlIGNvcnJlY3QgaGFuZGxpbmcg b2YgdGhlIE5TSCBzaG91bGQgYmUgZG9uZS4NCj4gSW4gdGhpcyBjYXNlIHlvdSBuZWVkIHRoZSBz aWduYWxpbmc/DQo+IA0KPiAvTG9hDQo+IA0KPiANCj4gT24gMjAxNS0wMS0yNyAxNjo1OCwgWHV4 aWFvaHUgd3JvdGU6DQo+ID4gSGkgU2FzaGEsDQo+ID4NCj4gPiBJZiBvbmx5IG9uZSBhcHBsaWNh dGlvbiBsYWJlbCBpcyByZXF1aXJlZCB0byBiZSBpbnNlcnRlZCBpbnRvIHRoZSBsYWJlbCBzdGFj aywNCj4gd2hlcmUgc2hvdWxkIGl0IGJlIGluc2VydGVkPyBhdCB0aGUgQm9TPyBJZiBzbywgaXQg c2VlbXMgdGhhdCB0aGUgYXBwbGljYXRpb24NCj4gbGFiZWwgbXVzdCBiZSBhbiBFU1AgbGFiZWwu DQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0 bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCj4gPj4gU2VudDogVHVlc2RheSwg SmFudWFyeSAyNywgMjAxNSA0OjQ2IFBNDQo+ID4+IFRvOiBYdXhpYW9odQ0KPiA+PiBDYzogbXBs c0BpZXRmLm9yZzsgc2ZjQGlldGYub3JnOyBMb2EgQW5kZXJzc29uDQo+ID4+IFN1YmplY3Q6IFJF OiBbc2ZjXSBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4g TVBMUw0KPiBwYWNrZXQ/DQo+ID4+DQo+ID4+IFhpYW9oIGhpIQ0KPiA+PiBJIGRvIG5vdCB0aGlu ayB5b3UgbmVlZCBtdWx0aXBsZSBhcHBsaWNhdGlvbiBsYWJlbHMuDQo+ID4+IFJhdGhlciwgeW91 IGNvdWxkIHN3YXAgdGhlc2UgbGFiZWxzIGFzIHRoZSBwYWNrZXQgcHJvZ3Jlc3NlcyBhbG9uZw0K PiA+PiB0aGUgU0ZQLCBzYW1lIGFzIGlzIGRvbmUgd2l0aCBNUy1QV3MuDQo+ID4+DQo+ID4+IFJl Z2FyZHMsDQo+ID4+ICAgICAgICAgU2FzaGENCj4gPj4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tDQo+ID4+IE1vYmlsZTogMDU0LTkyNjYzMDINCj4gPj4NCj4gPj4NCj4g Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBYdXhpYW9odSBbbWFp bHRvOnh1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4+PiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI3 LCAyMDE1IDk6NDYgQU0NCj4gPj4+IFRvOiBMb2EgQW5kZXJzc29uOyBBbGV4YW5kZXIgVmFpbnNo dGVpbg0KPiA+Pj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiA+Pj4gU3ViamVj dDogUkU6IFtzZmNdIFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBp biBhbg0KPiA+Pj4gTVBMUyBwYWNrZXQ/DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWls dG86bG9hQHBpLm51XQ0KPiA+Pj4+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjcsIDIwMTUgMjoy OCBQTQ0KPiA+Pj4+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgWHV4aWFvaHUNCj4gPj4+PiBD YzogbXBsc0BpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQo+ID4+Pj4gU3ViamVjdDogUmU6IFtzZmNd IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbg0KPiA+Pj4+ IE1QTFMNCj4gPj4+IHBhY2tldD8NCj4gPj4+Pg0KPiA+Pj4+IFNhc2hhLA0KPiA+Pj4+DQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+IE9uIDIwMTUtMDEtMjYgMTQ6MjEsIEFsZXhhbmRlciBWYWluc2h0 ZWluIHdyb3RlOg0KPiA+Pj4+PiBYaWFvaHUsIEh1dWIsDQo+ID4+Pj4+IEkgZG8gbm90IGZvbGxv dyB0aGUgU0ZDIHdvcmsgY2xvc2VseSwgc28gSSB3b3VsZCBsaWtlIHRvDQo+ID4+Pj4+IHVuZGVy c3RhbmQgd2hldGhlciB0aGUNCj4gPj4+PiBOU0ggc2hvdWxkIGJlIGNhcHR1cmVkIGJ5ICB0cmFu c2l0IExTUnMgb24gdGhlIExTUCAtIG9yIGp1c3QgYnkgdGhlDQo+ID4+Pj4gTEVSIGFjdGluZyBh cyB0aGUgTFNQIHRhaWwtZW5kPw0KPiA+Pj4+Pg0KPiA+Pj4+PiBJZiB0aGUgbGF0dGVyIGlzIGNv cnJlY3QsIHRoZSBzaW1wbGVzdCB3YXkgdG8gaW5kaWNhdGUgcHJlc2VuY2Ugb2YNCj4gPj4+Pj4g dGhlIE5TSCBpbiB0aGUNCj4gPj4+PiBNUExTIHBheWxvYWQgd291bGQgYmUgYnkgYWxsb2NhdGlu ZyBhbiAiYXBwbGljYXRpb24gbGFiZWwiDQo+ID4+Pj4gaW5kaWNhdGluZyBpdHMgcHJlc2VuY2Ug YnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5zZXJ0aW5nIGl0IGF0DQo+ID4+Pj4gdGhlIGJv dHRvbSBvZiB0aGUgbGFiZWwgc3RhY2sgYnkgdGhlIGhlYWQtZW5kIExFUiAtIHNpbWlsYXIgdG8g d2hhdA0KPiA+Pj4+IGlzIGRvbmUgZm9yIEwyL0wzVlBOLiAgV2l0aGluIHRoaXMgYXBwcm9hY2gs IGlmIGxhYmVsLWJhc2VkDQo+ID4+Pj4gZGVtdWx0aXBsZXhpbmcgb2YgcGFja2V0cyB3aXRoIE5T SCBpbiB0aGUgTVBMUyBwYXlsb2FkIGlzIG5vdA0KPiA+Pj4+IHJlcXVpcmVkLCB5b3UgY291bGQg cmVxdWVzdCBhbGxvY2F0aW9uIG9mIGEgbmV3IHNwZWNpYWwgcHVycG9zZQ0KPiA+Pj4+IGxhYmVs IGZyb20gdGhlIGV4dGVuZGVkIHNwZWNpYWwgcHVycG9zZXMgbGFiZWwgc3BhY2UgYXMgcGVyIFJG Qw0KPiA+Pj4+IDcyNzQsIGFuZCB0byBpbnNlcnQgc3VjaCBhIGxhYmVsDQo+ID4+PiAocHJlY2Vk ZWQgYnkgdGhlIEV4dGVuc2lvbiBMYWJlbCApIGF0IHRoZSBCb1MuDQo+ID4+Pj4+DQo+ID4+Pj4g SSB0aGluayAidGhlIGxhdHRlciIgaXMgY29ycmVjdCwgdGhlIG9ubHkgaXNzdWUgSSBzZWUgaXMg YWRkaW5nIG9uZQ0KPiA+Pj4+IG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8gdGhlIGxhYmVsIHN0 YWNrLg0KPiA+Pj4NCj4gPj4+IFllcywgdGhlIGxhdHRlciBpcyBjb3JyZWN0LiBUaGUgaXNzdWUg b2YgYWRkaW5nIG9uZSBtb3JlIGxhYmVsIHN0YWNrDQo+ID4+PiBlbnRyeSB0byB0aGUgbGFiZWwg c3RhY2sgbWF5IGJlY29tZSB1bmFjY2VwdGFibGUgaW4gdGhlIGNhc2Ugd2hlcmUNCj4gPj4+IHRo ZSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgaXMgcmVwcmVzZW50ZWQgYnkgYW4gbGFiZWwg c3RhY2sNCj4gPj4+IHdoaWxlIHRoZSBOU0ggaXMgbm93IG9ubHkgdXNlZCBhcyBhIG1ldGFkYXRh IGNvbnRhaW5lci4gRm9yIGV4YW1wbGUsDQo+ID4+PiBmb3IgYW4gU0ZQIGNvbnNpc3Qgb2YgbiBT RnMsIG4gImFwcGxpY2F0aW9uIGxhYmVscyIgd291bGQgaGF2ZSB0byBiZQ0KPiBpbnNlcnRlZCBp bnRvIHRoZSBsYWJlbCBzdGFjay4NCj4gPj4+DQo+ID4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+PiBY aWFvaHUNCj4gPj4+DQo+ID4+Pj4gL0xvYQ0KPiA+Pj4+PiBJZiB0aGUgZm9ybWVyIGlzIGNvcnJl Y3QsIHRoZSBwcm9jZXNzIGFib3ZlIHN0aWxsIGhhcyB0byBiZSB1c2VkDQo+ID4+Pj4+IGJ1dCBp dCBoYXMgdG8gYmUNCj4gPj4+PiBhdWdtZW50ZWQgYnkgYWRkaW5nIHRoZSBSb3V0ZXIgQWxlcnQg TGFiZWwgICBhdCB0aGUgdG9wIG9mIHRoZSBsYWJlbA0KPiBzdGFjay4NCj4gPj4+Pj4NCj4gPj4+ Pj4gICBGcm9tIG15IFBPViB0aGVzZSBzdWdnZXN0aW9ucyBhcmUgaW4gbGluZSB3aXRoIHRoZSBw cm92aXNpb25zIG9mDQo+ID4+Pj4+IFNlY3Rpb24gMi4yDQo+ID4+Pj4gb2YgUkZDIDMwMzIgIkRl dGVybWluaW5nIHRoZSBOZXR3b3JrIExheWVyIFByb3RvY29sIiB0aGF0IHN0YXRlczoNCj4gPj4+ Pj4NCj4gPj4+Pj4gPHF1b3RlPg0KPiA+Pj4+PiAgICAgIFdoZW4gdGhlIGxhc3QgbGFiZWwgaXMg cG9wcGVkIGZyb20gYSBwYWNrZXQncyBsYWJlbCBzdGFjayAocmVzdWx0aW5nDQo+ID4+Pj4+ICAg ICAgaW4gdGhlIHN0YWNrIGJlaW5nIGVtcHRpZWQpLCBmdXJ0aGVyIHByb2Nlc3Npbmcgb2YgdGhl IHBhY2tldCBpcw0KPiA+Pj4+PiAgICAgIGJhc2VkIG9uIHRoZSBwYWNrZXQncyBuZXR3b3JrIGxh eWVyIGhlYWRlci4gIFRoZSBMU1Igd2hpY2gNCj4gPj4+Pj4gcG9wcw0KPiA+PiB0aGUNCj4gPj4+ Pj4gICAgICBsYXN0IGxhYmVsIG9mZiB0aGUgc3RhY2sgbXVzdCB0aGVyZWZvcmUgYmUgYWJsZSB0 byBpZGVudGlmeSB0aGUNCj4gPj4+Pj4gICAgICBwYWNrZXQncyBuZXR3b3JrIGxheWVyIHByb3Rv Y29sLiAgSG93ZXZlciwgdGhlIGxhYmVsIHN0YWNrIGRvZXMgbm90DQo+ID4+Pj4+ICAgICAgY29u dGFpbiBhbnkgZmllbGQgd2hpY2ggZXhwbGljaXRseSBpZGVudGlmaWVzIHRoZSBuZXR3b3JrIGxh eWVyDQo+ID4+Pj4+ICAgICAgcHJvdG9jb2wuICBUaGlzIG1lYW5zIHRoYXQgdGhlIGlkZW50aXR5 IG9mIHRoZSBuZXR3b3JrIGxheWVyDQo+IHByb3RvY29sDQo+ID4+Pj4+ICAgICAgbXVzdCBiZSBp bmZlcmFibGUgZnJvbSB0aGUgdmFsdWUgb2YgdGhlIGxhYmVsIHdoaWNoIGlzIHBvcHBlZCBmcm9t DQo+ID4+Pj4+ICAgICAgdGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ssIHBvc3NpYmx5IGFsb25nIHdp dGggdGhlIGNvbnRlbnRzIG9mIHRoZQ0KPiA+Pj4+PiAgICAgIG5ldHdvcmsgbGF5ZXIgaGVhZGVy IGl0c2VsZi4NCj4gPj4+Pj4gPGVuZCBxdW90ZT4NCj4gPj4+Pj4NCj4gPj4+Pj4gTXkgMmMsDQo+ ID4+Pj4+IFNhc2hhDQo+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4+Pj4gRnJvbTogbXBscyA8bXBscy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhh bGYgb2YgWHV4aWFvaHUNCj4gPj4+Pj4gPHh1eGlhb2h1QGh1YXdlaS5jb20+DQo+ID4+Pj4+IFNl bnQ6IE1vbmRheSwgSmFudWFyeSAyNiwgMjAxNSA1OjA1IEFNDQo+ID4+Pj4+IFRvOiBodXViYXR3 b3JrQGdtYWlsLmNvbTsgc2ZjQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQo+ID4+Pj4+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4g TVBMUw0KPiA+Pj4gcGFja2V0Pw0KPiA+Pj4+Pg0KPiA+Pj4+PiBIaSBIdXViLA0KPiA+Pj4+Pg0K PiA+Pj4+PiBUaGUgYWx0ZXIgbGFiZWwgaXRzZWxmIGNvdWxkbqGvdCBtYWtlIHRoZSByZWNlaXZp bmcgTFNSIHRvDQo+ID4+Pj4+IGRldGVybWluZSB0aGUgTVBMUw0KPiA+Pj4+IHBheWxvYWQgdHlw ZSBieSBleGFtaW5pbmcgdGhlIE1QTFMgcGF5bG9hZC4NCj4gPj4+Pj4NCj4gPj4+Pj4gQmVzdCBy ZWdhcmRzLA0KPiA+Pj4+PiBYaWFvaHUNCj4gPj4+Pj4NCj4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4+Pj4+PiBGcm9tOiBIdXViIHZhbiBIZWx2b29ydCBbbWFpbHRvOmh1 dWJhdHdvcmtAZ21haWwuY29tXQ0KPiA+Pj4+Pj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDIzLCAy MDE1IDY6MjggUE0NCj4gPj4+Pj4+IFRvOiBYdXhpYW9odTsgc2ZjQGlldGYub3JnOyBtcGxzQGll dGYub3JnDQo+ID4+Pj4+PiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0ZSB0aGUg cHJlc2VuY2Ugb2YgTlNIIGluIGFuDQo+ID4+Pj4+PiBNUExTDQo+ID4+PiBwYWNrZXQ/DQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gWHV4aWFvaHUgxPq6w6OhDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gUGxlYXNl IGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZzoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJdCBoYXMgYWx3 YXlzIGJlZW4gbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSBNUExTIGhlYWRlci9sYWJlbA0KPiA+ Pj4+Pj4gd2FzIGluZGVwZW5kZW50IG9mIHRoZSBwcm90b2NvbC9wYXlsb2FkLg0KPiA+Pj4+Pj4g U28gbm8gaW5kaWNhdGlvbiBvZiB0aGUgYWN0dWFsIHBheWxvYWQgY29udGVudCB3YXMgbmVjZXNz YXJ5Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IElNSE8geW91IGNvdWxkIHVzZSB0aGUgYWxlcnQgbGFi ZWwgMSB0byBpbmRpY2F0ZSB0byB0aGUgTFNSIHRoYXQNCj4gPj4+Pj4+IGl0IGhhcyB0byBmdXJ0 aGVyIGV4YW1pbmUgdGhlIGNvbnRlbnQgb2YgYSBwYWNrZXQuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g UmVnYXJkcywgSHV1Yi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiA9PT09PT09PQ0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+PiBJdCBzYWlkIGluIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVp bm4tc2ZjLW5zaC0wNCk6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAgICAgICBUaGUgc2VydmljZSBo ZWFkZXIgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIGVuY2Fwc3VsYXRpb24NCj4gPj4+Pj4+PiB1c2Vk IGFuZA0KPiA+PiBpcw0KPiA+Pj4+Pj4+ICAgICAgIGVuY2Fwc3VsYXRlZCBpbiBleGlzdGluZyB0 cmFuc3BvcnRzLiAgVGhlIHByZXNlbmNlIG9mIE5TSCBpcw0KPiA+Pj4+Pj4+ICAgICAgIGluZGlj YXRlZCB2aWEgcHJvdG9jb2wgdHlwZSBvciBvdGhlciBpbmRpY2F0b3IgaW4gdGhlIG91dGVyDQo+ ID4+Pj4+Pj4gICAgICAgZW5jYXBzdWxhdGlvbi4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEluIHRo ZSBjYXNlIHdoZXJlIHRoZSBvdXRlciBlbmNhcHN1bGF0aW9uIGlzIGFuIE1QTFMgTFNQLCBob3cg dG8NCj4gPj4+Pj4+PiBpbmRpY2F0ZSB0aGUNCj4gPj4+Pj4+IHByZXNlbmNlIG9mIE5TSCBzaW5j ZSB0aGUgTVBMUyBlbmNhcHN1bGF0aW9uIGhhcyBubyBleHBsaWNpdA0KPiA+Pj4+Pj4gcHJvdG9j b2wgaWRlbnRpZmllciBmaWVsZCB0byBpbmRpY2F0ZSB0aGUgcHJvdG9jb2wgdHlwZSBvZiB0aGUN Cj4gPj4+Pj4+IE1QTFMNCj4gPj4+IHBheWxvYWQ/DQo+ID4+Pj4+PiBTaG91bGQgd2UgbWFrZSBl YWNoIFNGRiB0byBhbGxvY2F0ZSBhIHVuaXF1ZSBsYWJlbCBmb3IgaW5kaWNhdGluZw0KPiA+Pj4+ Pj4gdGhlIHByZXNlbmNlIG9mIE5TSD8gT3Igc2hvdWxkIHdlIHVzZSB0aGUgY29udHJvbCB3b3Jk IHRvDQo+ID4+Pj4+PiBpbmRpY2F0ZSBpdD8gT3Igc2hvdWxkIHdlIHJlY29uc2lkZXIgdGhlIHBv c3NpYmlsaXR5IG9mIGFkZGluZyBhbg0KPiA+Pj4+Pj4gZXhwbGljaXQgcHJvdG9jb2wgaWRlbnRp ZmllciBmaWVsZCB0byB0aGUgTVBMUyBlbmNhcHN1bGF0aW9uIHNvDQo+ID4+Pj4+PiBhcyB0byBz b2x2ZSBzdWNoIGtpbmQgb2YgaXNzdWVzDQo+ID4+Pj4gb25jZSBhbmQgZm9yIGFsbD8NCj4gPj4+ Pj4+Pg0KPiA+Pj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4gPj4+Pj4+PiBYaWFvaHUNCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAtLQ0KPiA+Pj4+Pj4NCj4gPj4+Pg0KPiA+ Pj4NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KPiA+Pj4gKioqDQo+ID4+Pj4+PiAqKioqDQo+ID4+Pj4+PiAgICAgICAgICAgICAg ICAgIMfrvMfXoaOsxOPKx7bA0rvO3rb+tcSjrL7Nz/HG5Mv7w7/Su7j2yMvSu9H5DQo+ID4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+ IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+IHNmYyBtYWlsaW5n IGxpc3QNCj4gPj4+Pj4gc2ZjQGlldGYub3JnDQo+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAtLQ0KPiA+Pj4+ DQo+ID4+Pj4NCj4gPj4+PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1h aWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiA+Pj4+IFNlbmlvciBNUExTIEV4cGVydCAgICAg ICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+ID4+Pj4gSHVhd2VpIFRlY2hub2xvZ2ll cyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzZmMgbWFpbGluZyBs aXN0DQo+ID4gc2ZjQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4gPg0KPiANCj4gLS0NCj4gDQo+IA0KPiBMb2EgQW5kZXJzc29uICAgICAg ICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiBTZW5pb3Ig TVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPiBIdWF3ZWkg VGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== From nobody Tue Jan 27 04:16:15 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB2B1A8797; Tue, 27 Jan 2015 03:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.792 X-Spam-Level: X-Spam-Status: No, score=0.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdX5iRxLK-hB; Tue, 27 Jan 2015 03:41:43 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F3D1A2119; Tue, 27 Jan 2015 03:41:42 -0800 (PST) Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0811.eurprd03.prod.outlook.com (25.161.55.143) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 11:01:00 +0000 Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 11:00:59 +0000 From: Alexander Vainshtein To: Xuxiaohu Thread-Topic: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegARJH4AAIdmfAAABiq6FgAzM48AAAK7wgAAAgCbEAAAiTyAAAOaX3A= Date: Tue, 27 Jan 2015 11:00:59 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ecitele.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR03MB0811; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0811; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(13464003)(377454003)(51704005)(252514010)(377424004)(19300405004)(19580395003)(19580405001)(74316001)(86362001)(87936001)(2656002)(62966003)(54206007)(77156002)(66066001)(92566002)(2950100001)(19625215002)(33656002)(102836002)(15975445007)(2900100001)(76576001)(16236675004)(110136001)(16234385003)(40100003)(122556002)(54606007)(54356999)(93886004)(46102003)(76176999)(19617315012)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0811; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0812936A8223F4750DAEA9849D320DB3PR03MB0812eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 11:00:59.6629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0811 Archived-At: X-Mailman-Approved-At: Tue, 27 Jan 2015 04:16:06 -0800 Cc: "mpls@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 11:41:47 -0000 --_000_DB3PR03MB0812936A8223F4750DAEA9849D320DB3PR03MB0812eurp_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WGlhb2h1LA0KDQpJIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSBteSBwb3NpdGlvbi4NCg0KMS4gICAg ICAgQXBwbGljYXRpb24gbGV2ZWwgYW5kIGEgZGVkaWNhdGVkIEVTUCBhcmUgdHdvIGFsdGVybmF0 aXZlIG9wdGlvbnMgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiB0aGUgcGF5bG9h ZCBvZiBhIGxhYmVsZWQgcGFja2V0Lg0KDQphLiAgICAgICBBIGRlZGljYXRlZCBFU1AgY291bGQg YmUgdXNlZCBpZiBhc3NvY2lhdGlvbiBvZiB0aGUgcmVjZWl2ZWQgcGFja2V0IHdpdGggYSBzcGVj aWZpYyBTRiBpbnN0YW5jZSB3aXRoaW4gdGhlIHByb2Nlc3NpbmcgTkUgY2FuIGJlIHBlcmZvcm1l ZCBiYXNlZCBleGNsdXNpdmVseSBvbiBOU0guIEp1c3Qgb25lIEVTUCBsYWJlbCB3b3VsZCBiZSB1 c2VkIChvY2N1cHlpbmcgMiBlbnRyaWVzIGluIHRoZSBsYWJlbCBzdGFjayksIGFuZCBpdCB3b3Vs ZCBqdXN0IGJlIHRyZWF0ZWQgYXMgdGhlIE5TSCBwcmVzZW5jZSBpbmRpY2F0b3IuIFRoaXMgc2l0 dWF0aW9uIGlzIHNpbWlsYXIgdG8gdXNpbmcgdGhlIEdlbmVyaWMgQXNzb2NpYXRlZCBDaGFubmVs IExhYmVsIChHQUwpIGluIE1QTFMtVFAuDQoNCmIuICAgICAgQW4gYXBwbGljYXRpb24gbGFiZWwg cGVyIFNGIGluc3RhbmNlIHNob3VsZCBiZSB1c2VkIGlmIHRoZSBOU0ggaGVhZGVyIGlzIG5vdCBz dWZmaWNpZW50IGZvciBkZWZpbmluZyB0aGUgU0YgaW5zdGFuY2UgdGhhdCB3b3VsZCBoYW5kbGUg dGhlIHBhY2tldC4gQSBkZWRpY2F0ZWQgYXBwbGljYXRpb24gbGFiZWwgd291bGQgYmUgYWxsb2Nh dGVkIGF0IGxlYXN0IHBlciBTRiBpbnN0YW5jZSB3aXRoaW4gdGhlIE5FLCBhbmQgc29tZSBzdWl0 YWJsZSBwcm90b2NvbCB3b3VsZCBiZSB1c2VkIGZvciBkaXN0cmlidXRpbmcgYXNzb2NpYXRpb24g YmV0d2VlbiB0aGlzIGxhYmVsIGFuZCBpdHMgc3BlY2lmaWMgU0YgaW5zdGFuY2UuIFRoaXMgaXMg c2ltaWxhciB0byB1c2luZyBQVyBsYWJlbHMgaW4gUFdzIGFuZC9vciBBcHBsaWNhdGlvbiBsYWJl bHMgKGRpc3RyaWJ1dGVkIHdpdGggdGhlaXIgYXNzb2NpYXRlZCBsYWJlbGVkIElQLVZQTiByb3V0 ZXMpIGluIEwzVlBODQoNCmMuICAgICAgIE15IGtub3dsZWRnZSBvZiBTRkMgaXMgYWxsIGJ1dCBv bi1leGlzdGVudCwgc28gSSBjYW5ub3Qgc2F5IHdoaWNoIG9mIHRoZXNlIHR3byBhbHRlcm5hdGl2 ZXMgaXMgcmVsZXZhbnQuDQoNCjIuICAgICAgIEluIGJvdGggY2FzZXMgdGhlIGxhYmVsIChiZSBp dCBhbiBhcHBsaWNhdGlvbiBsYWJlbCBvciBhIGRlZGljYXRlZCBFU1ApIG11c3QgYmUgaW5zZXJ0 ZWQgYnkgdGhlIGhlYWQtZW5kIGF0IHRoZSBCb1Mgc28gdGhhdCBpdCB3b3VsZCBiZSBwcm9jZXNz ZWQgYnkgdGhlIHRhaWwtZW5kIG5vZGUgb2YgdGhlIExTUCB3aXRob3V0IGFmZmVjdGluZyBhbnkg dHJhbnNpdCBub2RlcyAod2hpY2ggd291bGQganVzdCBwZXJmb3JtIHN0YW5kYXJkIE1QTFMgZm9y d2FyZGluZykuDQoNCjMuICAgICAgIEluIHRoZSBjYXNlIG9mIFNGIHBhdGhzOg0KDQphLiAgICAg ICBJZiB0aGUgZGVkaWNhdGVkIEVTUCBpcyB1c2VkLCBoYW5kbGluZyBvZiB0aGUgcGFja2V0IGJ5 IHRoZSBjdXJyZW50IFNGIG11c3QgaW5jbHVkZSBkZWZpbml0aW9uIG9mIHRoZSBuZXh0IFNGIG5v ZGUgYW5kIGZvcndhcmRpbmcgdG8gdGhpcyBub2RlLiBUaGUgZm9yd2FyZGVkIHBhY2tldCB3b3Vs ZCBhZ2FpbiBpbmNsdWRlIHRoZSBkZWRpY2F0ZWQgRVNQIGF0IHRoZSBCb1MsIHdpdGggdGhlIKGw dHVubmVsIExTUKGxIGxhYmVsIHN0YWNrIG9uIHRvcCBvZiB0aGF0DQoNCmIuICAgICAgSWYgdGhl IGFwcGxpY2F0aW9uIGxhYmVsIGlzIHVzZWQsIHRoZSBuZXh0IFNGIG5vZGUgYW5kIHRoZSBTRiBp bnN0YW5jZSB3aXRoaW4gdGhpcyBub2RlIGNvdWxkIGJlIGluZmVycmVkIGVpdGhlciBmcm9tIHRo ZSBwYXlsb2FkIG9yIGZyb20gdGhlIGFwcGxpY2F0aW9uIGxhYmVsLCBvciBmcm9tIHRoZWlyIGNv bWJpbmF0aW9uLiBJbiBhbnkgY2FzZSBmb3J3YXJkaW5nIG9mIHRoZSBwYWNrZXQgdG8gdGhlIG5l eHQgU0Ygd291bGQgcmVzdWx0IGluIHN3YXBwaW5nIG9mIHRoZSBhcHBsaWNhdGlvbiBsYWJlbCBh dCB0aGUgQm9TIChzaW1pbGFyIHRvIHdoYXQgaXMgZG9uZSBpbiBNUy1QV3MpIGFuZCBwdXNoaW5n IHRoZSChsHR1bm5lbCBMU1ChsSBsYWJlbCBzdGFjayBvbiB0b3Agb2YgdGhhdC4NCg0KDQoNCk5v dCBzdXJlIGlmIHRoaXMgaGVscHMsIG9yIGp1c3QgYWRkcyBtb3JlIG5vaXNlOikuDQoNCg0KDQpS ZWdhcmRzLA0KDQogICAgICAgU2FzaGENCg0KRW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tDQoNCk1vYmlsZTogMDU0LTkyNjYzMDINCg0KDQoNCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogWHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBodWF3 ZWkuY29tXQ0KDQo+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjcsIDIwMTUgMTA6NTkgQU0NCg0K PiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW4NCg0KPiBDYzogbXBsc0BpZXRmLm9yZzsgc2ZjQGll dGYub3JnOyBMb2EgQW5kZXJzc29uDQoNCj4gU3ViamVjdDogUkU6IFtzZmNdIFttcGxzXSBIb3cg dG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTDQoNCj4gcGFja2V0Pw0K DQo+DQoNCj4gSGkgU2FzaGEsDQoNCj4NCg0KPiBJZiBvbmx5IG9uZSBhcHBsaWNhdGlvbiBsYWJl bCBpcyByZXF1aXJlZCB0byBiZSBpbnNlcnRlZCBpbnRvIHRoZSBsYWJlbCBzdGFjaywNCg0KPiB3 aGVyZSBzaG91bGQgaXQgYmUgaW5zZXJ0ZWQ/IGF0IHRoZSBCb1M/IElmIHNvLCBpdCBzZWVtcyB0 aGF0IHRoZSBhcHBsaWNhdGlvbg0KDQo+IGxhYmVsIG11c3QgYmUgYW4gRVNQIGxhYmVsLg0KDQo+ DQoNCj4gQmVzdCByZWdhcmRzLA0KDQo+IFhpYW9odQ0KDQo+DQoNCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KDQo+ID4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCg0KPiA+IFNlbnQ6IFR1ZXNkYXksIEph bnVhcnkgMjcsIDIwMTUgNDo0NiBQTQ0KDQo+ID4gVG86IFh1eGlhb2h1DQoNCj4gPiBDYzogbXBs c0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2Zj QGlldGYub3JnPjsgTG9hIEFuZGVyc3Nvbg0KDQo+ID4gU3ViamVjdDogUkU6IFtzZmNdIFttcGxz XSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTDQoNCj4gcGFj a2V0Pw0KDQo+ID4NCg0KPiA+IFhpYW9oIGhpIQ0KDQo+ID4gSSBkbyBub3QgdGhpbmsgeW91IG5l ZWQgbXVsdGlwbGUgYXBwbGljYXRpb24gbGFiZWxzLg0KDQo+ID4gUmF0aGVyLCB5b3UgY291bGQg c3dhcCB0aGVzZSBsYWJlbHMgYXMgdGhlIHBhY2tldCBwcm9ncmVzc2VzIGFsb25nIHRoZQ0KDQo+ ID4gU0ZQLCBzYW1lIGFzIGlzIGRvbmUgd2l0aCBNUy1QV3MuDQoNCj4gPg0KDQo+ID4gUmVnYXJk cywNCg0KPiA+ICAgICAgICBTYXNoYQ0KDQo+ID4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCg0K PiA+IE1vYmlsZTogMDU0LTkyNjYzMDINCg0KPiA+DQoNCj4gPg0KDQo+ID4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KDQo+ID4gPiBGcm9tOiBYdXhpYW9odSBbbWFpbHRvOnh1eGlhb2h1 QGh1YXdlaS5jb21dDQoNCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjcsIDIwMTUgOTo0 NiBBTQ0KDQo+ID4gPiBUbzogTG9hIEFuZGVyc3NvbjsgQWxleGFuZGVyIFZhaW5zaHRlaW4NCg0K PiA+ID4gQ2M6IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCg0KPiA+ID4gU3ViamVjdDogUkU6IFtzZmNdIFttcGxz XSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbg0KDQo+ID4gPiBNUExT IHBhY2tldD8NCg0KPiA+ID4NCg0KPiA+ID4NCg0KPiA+ID4NCg0KPiA+ID4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KDQo+ID4gPiA+IEZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzps b2FAcGkubnVdDQoNCj4gPiA+ID4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNywgMjAxNSAyOjI4 IFBNDQoNCj4gPiA+ID4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBYdXhpYW9odQ0KDQo+ID4g PiA+IENjOiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQoNCj4gPiA+ID4gU3ViamVjdDogUmU6IFtzZmNdIFttcGxz XSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbg0KDQo+ID4gPiA+IGFuIE1Q TFMNCg0KPiA+ID4gcGFja2V0Pw0KDQo+ID4gPiA+DQoNCj4gPiA+ID4gU2FzaGEsDQoNCj4gPiA+ ID4NCg0KPiA+ID4gPg0KDQo+ID4gPiA+DQoNCj4gPiA+ID4gT24gMjAxNS0wMS0yNiAxNDoyMSwg QWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQoNCj4gPiA+ID4gPiBYaWFvaHUsIEh1dWIsDQoN Cj4gPiA+ID4gPiBJIGRvIG5vdCBmb2xsb3cgdGhlIFNGQyB3b3JrIGNsb3NlbHksIHNvIEkgd291 bGQgbGlrZSB0bw0KDQo+ID4gPiA+ID4gdW5kZXJzdGFuZCB3aGV0aGVyIHRoZQ0KDQo+ID4gPiA+ IE5TSCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRyYW5zaXQgTFNScyBvbiB0aGUgTFNQIC0gb3Ig anVzdCBieQ0KDQo+ID4gPiA+IHRoZSBMRVIgYWN0aW5nIGFzIHRoZSBMU1AgdGFpbC1lbmQ/DQoN Cj4gPiA+ID4gPg0KDQo+ID4gPiA+ID4gSWYgdGhlIGxhdHRlciBpcyBjb3JyZWN0LCB0aGUgc2lt cGxlc3Qgd2F5IHRvIGluZGljYXRlIHByZXNlbmNlDQoNCj4gPiA+ID4gPiBvZiB0aGUgTlNIIGlu IHRoZQ0KDQo+ID4gPiA+IE1QTFMgcGF5bG9hZCB3b3VsZCBiZSBieSBhbGxvY2F0aW5nIGFuICJh cHBsaWNhdGlvbiBsYWJlbCINCg0KPiA+ID4gPiBpbmRpY2F0aW5nIGl0cyBwcmVzZW5jZSBieSB0 aGUgdGFpbC1lbmQgTEVSIGFuZCBieSBpbnNlcnRpbmcgaXQgYXQNCg0KPiA+ID4gPiB0aGUgYm90 dG9tIG9mIHRoZSBsYWJlbCBzdGFjayBieSB0aGUgaGVhZC1lbmQgTEVSIC0gc2ltaWxhciB0bw0K DQo+ID4gPiA+IHdoYXQgaXMgZG9uZSBmb3IgTDIvTDNWUE4uICBXaXRoaW4gdGhpcyBhcHByb2Fj aCwgaWYgbGFiZWwtYmFzZWQNCg0KPiA+ID4gPiBkZW11bHRpcGxleGluZyBvZiBwYWNrZXRzIHdp dGggTlNIIGluIHRoZSBNUExTIHBheWxvYWQgaXMgbm90DQoNCj4gPiA+ID4gcmVxdWlyZWQsIHlv dSBjb3VsZCByZXF1ZXN0IGFsbG9jYXRpb24gb2YgYSBuZXcgc3BlY2lhbCBwdXJwb3NlDQoNCj4g PiA+ID4gbGFiZWwgZnJvbSB0aGUgZXh0ZW5kZWQgc3BlY2lhbCBwdXJwb3NlcyBsYWJlbCBzcGFj ZSBhcyBwZXIgUkZDDQoNCj4gPiA+ID4gNzI3NCwgYW5kIHRvIGluc2VydCBzdWNoIGEgbGFiZWwN Cg0KPiA+ID4gKHByZWNlZGVkIGJ5IHRoZSBFeHRlbnNpb24gTGFiZWwgKSBhdCB0aGUgQm9TLg0K DQo+ID4gPiA+ID4NCg0KPiA+ID4gPiBJIHRoaW5rICJ0aGUgbGF0dGVyIiBpcyBjb3JyZWN0LCB0 aGUgb25seSBpc3N1ZSBJIHNlZSBpcyBhZGRpbmcNCg0KPiA+ID4gPiBvbmUgbW9yZSBsYWJlbCBz dGFjayBlbnRyeSB0byB0aGUgbGFiZWwgc3RhY2suDQoNCj4gPiA+DQoNCj4gPiA+IFllcywgdGhl IGxhdHRlciBpcyBjb3JyZWN0LiBUaGUgaXNzdWUgb2YgYWRkaW5nIG9uZSBtb3JlIGxhYmVsIHN0 YWNrDQoNCj4gPiA+IGVudHJ5IHRvIHRoZSBsYWJlbCBzdGFjayBtYXkgYmVjb21lIHVuYWNjZXB0 YWJsZSBpbiB0aGUgY2FzZSB3aGVyZQ0KDQo+ID4gPiB0aGUgU2VydmljZSBGdW5jdGlvbiBQYXRo IChTRlApIGlzIHJlcHJlc2VudGVkIGJ5IGFuIGxhYmVsIHN0YWNrDQoNCj4gPiA+IHdoaWxlIHRo ZSBOU0ggaXMgbm93IG9ubHkgdXNlZCBhcyBhIG1ldGFkYXRhIGNvbnRhaW5lci4gRm9yIGV4YW1w bGUsDQoNCj4gPiA+IGZvciBhbiBTRlAgY29uc2lzdCBvZiBuIFNGcywgbiAiYXBwbGljYXRpb24g bGFiZWxzIiB3b3VsZCBoYXZlIHRvIGJlDQoNCj4gaW5zZXJ0ZWQgaW50byB0aGUgbGFiZWwgc3Rh Y2suDQoNCj4gPiA+DQoNCj4gPiA+IEJlc3QgcmVnYXJkcywNCg0KPiA+ID4gWGlhb2h1DQoNCj4g PiA+DQoNCj4gPiA+ID4gL0xvYQ0KDQo+ID4gPiA+ID4gSWYgdGhlIGZvcm1lciBpcyBjb3JyZWN0 LCB0aGUgcHJvY2VzcyBhYm92ZSBzdGlsbCBoYXMgdG8gYmUgdXNlZA0KDQo+ID4gPiA+ID4gYnV0 IGl0IGhhcyB0byBiZQ0KDQo+ID4gPiA+IGF1Z21lbnRlZCBieSBhZGRpbmcgdGhlIFJvdXRlciBB bGVydCBMYWJlbCAgIGF0IHRoZSB0b3Agb2YgdGhlIGxhYmVsDQoNCj4gc3RhY2suDQoNCj4gPiA+ ID4gPg0KDQo+ID4gPiA+ID4gIEZyb20gbXkgUE9WIHRoZXNlIHN1Z2dlc3Rpb25zIGFyZSBpbiBs aW5lIHdpdGggdGhlIHByb3Zpc2lvbnMNCg0KPiA+ID4gPiA+IG9mIFNlY3Rpb24gMi4yDQoNCj4g PiA+ID4gb2YgUkZDIDMwMzIgIkRldGVybWluaW5nIHRoZSBOZXR3b3JrIExheWVyIFByb3RvY29s IiB0aGF0IHN0YXRlczoNCg0KPiA+ID4gPiA+DQoNCj4gPiA+ID4gPiA8cXVvdGU+DQoNCj4gPiA+ ID4gPiAgICAgV2hlbiB0aGUgbGFzdCBsYWJlbCBpcyBwb3BwZWQgZnJvbSBhIHBhY2tldCdzIGxh YmVsIHN0YWNrIChyZXN1bHRpbmcNCg0KPiA+ID4gPiA+ICAgICBpbiB0aGUgc3RhY2sgYmVpbmcg ZW1wdGllZCksIGZ1cnRoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0IGlzDQoNCj4gPiA+ID4g PiAgICAgYmFzZWQgb24gdGhlIHBhY2tldCdzIG5ldHdvcmsgbGF5ZXIgaGVhZGVyLiAgVGhlIExT UiB3aGljaA0KDQo+ID4gPiA+ID4gcG9wcw0KDQo+ID4gdGhlDQoNCj4gPiA+ID4gPiAgICAgbGFz dCBsYWJlbCBvZmYgdGhlIHN0YWNrIG11c3QgdGhlcmVmb3JlIGJlIGFibGUgdG8gaWRlbnRpZnkg dGhlDQoNCj4gPiA+ID4gPiAgICAgcGFja2V0J3MgbmV0d29yayBsYXllciBwcm90b2NvbC4gIEhv d2V2ZXIsIHRoZSBsYWJlbCBzdGFjayBkb2VzIG5vdA0KDQo+ID4gPiA+ID4gICAgIGNvbnRhaW4g YW55IGZpZWxkIHdoaWNoIGV4cGxpY2l0bHkgaWRlbnRpZmllcyB0aGUgbmV0d29yayBsYXllcg0K DQo+ID4gPiA+ID4gICAgIHByb3RvY29sLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBpZGVudGl0eSBv ZiB0aGUgbmV0d29yayBsYXllciBwcm90b2NvbA0KDQo+ID4gPiA+ID4gICAgIG11c3QgYmUgaW5m ZXJhYmxlIGZyb20gdGhlIHZhbHVlIG9mIHRoZSBsYWJlbCB3aGljaCBpcyBwb3BwZWQgZnJvbQ0K DQo+ID4gPiA+ID4gICAgIHRoZSBib3R0b20gb2YgdGhlIHN0YWNrLCBwb3NzaWJseSBhbG9uZyB3 aXRoIHRoZSBjb250ZW50cyBvZiB0aGUNCg0KPiA+ID4gPiA+ICAgICBuZXR3b3JrIGxheWVyIGhl YWRlciBpdHNlbGYuDQoNCj4gPiA+ID4gPiA8ZW5kIHF1b3RlPg0KDQo+ID4gPiA+ID4NCg0KPiA+ ID4gPiA+IE15IDJjLA0KDQo+ID4gPiA+ID4gU2FzaGENCg0KPiA+ID4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPiA+ID4gPiA+IEZyb206IG1wbHMgPG1w bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mIFh1eGlhb2h1DQoNCj4gPiA+ID4gPiA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86 eHV4aWFvaHVAaHVhd2VpLmNvbT4+DQoNCj4gPiA+ID4gPiBTZW50OiBNb25kYXksIEphbnVhcnkg MjYsIDIwMTUgNTowNSBBTQ0KDQo+ID4gPiA+ID4gVG86IGh1dWJhdHdvcmtAZ21haWwuY29tPG1h aWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCg0KPiA+ID4gPiA+IFN1 YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4g YW4NCg0KPiA+ID4gPiA+IE1QTFMNCg0KPiA+ID4gcGFja2V0Pw0KDQo+ID4gPiA+ID4NCg0KPiA+ ID4gPiA+IEhpIEh1dWIsDQoNCj4gPiA+ID4gPg0KDQo+ID4gPiA+ID4gVGhlIGFsdGVyIGxhYmVs IGl0c2VsZiBjb3VsZG6hr3QgbWFrZSB0aGUgcmVjZWl2aW5nIExTUiB0bw0KDQo+ID4gPiA+ID4g ZGV0ZXJtaW5lIHRoZSBNUExTDQoNCj4gPiA+ID4gcGF5bG9hZCB0eXBlIGJ5IGV4YW1pbmluZyB0 aGUgTVBMUyBwYXlsb2FkLg0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+IEJlc3QgcmVnYXJkcywN Cg0KPiA+ID4gPiA+IFhpYW9odQ0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KDQo+ID4gPiA+ID4+IEZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFtt YWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb21dDQoNCj4gPiA+ID4gPj4gU2VudDogRnJpZGF5LCBK YW51YXJ5IDIzLCAyMDE1IDY6MjggUE0NCg0KPiA+ID4gPiA+PiBUbzogWHV4aWFvaHU7IHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4NCg0KPiA+ID4gPiA+PiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0 ZSB0aGUgcHJlc2VuY2Ugb2YgTlNIIGluIGFuDQoNCj4gPiA+ID4gPj4gTVBMUw0KDQo+ID4gPiBw YWNrZXQ/DQoNCj4gPiA+ID4gPj4NCg0KPiA+ID4gPiA+PiBYdXhpYW9odSDE+rrDo6ENCg0KPiA+ ID4gPiA+Pg0KDQo+ID4gPiA+ID4+IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3Jvbmc6DQoN Cj4gPiA+ID4gPj4NCg0KPiA+ID4gPiA+PiBJdCBoYXMgYWx3YXlzIGJlZW4gbXkgdW5kZXJzdGFu ZGluZyB0aGF0IHRoZSBNUExTIGhlYWRlci9sYWJlbA0KDQo+ID4gPiA+ID4+IHdhcyBpbmRlcGVu ZGVudCBvZiB0aGUgcHJvdG9jb2wvcGF5bG9hZC4NCg0KPiA+ID4gPiA+PiBTbyBubyBpbmRpY2F0 aW9uIG9mIHRoZSBhY3R1YWwgcGF5bG9hZCBjb250ZW50IHdhcyBuZWNlc3NhcnkuDQoNCj4gPiA+ ID4gPj4NCg0KPiA+ID4gPiA+PiBJTUhPIHlvdSBjb3VsZCB1c2UgdGhlIGFsZXJ0IGxhYmVsIDEg dG8gaW5kaWNhdGUgdG8gdGhlIExTUg0KDQo+ID4gPiA+ID4+IHRoYXQgaXQgaGFzIHRvIGZ1cnRo ZXIgZXhhbWluZSB0aGUgY29udGVudCBvZiBhIHBhY2tldC4NCg0KPiA+ID4gPiA+Pg0KDQo+ID4g PiA+ID4+IFJlZ2FyZHMsIEh1dWIuDQoNCj4gPiA+ID4gPj4NCg0KPiA+ID4gPiA+PiA9PT09PT09 PQ0KDQo+ID4gPiA+ID4+DQoNCj4gPiA+ID4gPj4+IEl0IHNhaWQgaW4gKGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1zZmMtbnNoLTA0KToNCg0KPiA+ID4gPiA+Pj4NCg0K PiA+ID4gPiA+Pj4gICAgICBUaGUgc2VydmljZSBoZWFkZXIgaXMgaW5kZXBlbmRlbnQgb2YgdGhl IGVuY2Fwc3VsYXRpb24NCg0KPiA+ID4gPiA+Pj4gdXNlZCBhbmQNCg0KPiA+IGlzDQoNCj4gPiA+ ID4gPj4+ICAgICAgZW5jYXBzdWxhdGVkIGluIGV4aXN0aW5nIHRyYW5zcG9ydHMuICBUaGUgcHJl c2VuY2Ugb2YgTlNIIGlzDQoNCj4gPiA+ID4gPj4+ICAgICAgaW5kaWNhdGVkIHZpYSBwcm90b2Nv bCB0eXBlIG9yIG90aGVyIGluZGljYXRvciBpbiB0aGUgb3V0ZXINCg0KPiA+ID4gPiA+Pj4gICAg ICBlbmNhcHN1bGF0aW9uLg0KDQo+ID4gPiA+ID4+Pg0KDQo+ID4gPiA+ID4+PiBJbiB0aGUgY2Fz ZSB3aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBpcyBhbiBNUExTIExTUCwgaG93DQoNCj4g PiA+ID4gPj4+IHRvIGluZGljYXRlIHRoZQ0KDQo+ID4gPiA+ID4+IHByZXNlbmNlIG9mIE5TSCBz aW5jZSB0aGUgTVBMUyBlbmNhcHN1bGF0aW9uIGhhcyBubyBleHBsaWNpdA0KDQo+ID4gPiA+ID4+ IHByb3RvY29sIGlkZW50aWZpZXIgZmllbGQgdG8gaW5kaWNhdGUgdGhlIHByb3RvY29sIHR5cGUg b2YgdGhlDQoNCj4gPiA+ID4gPj4gTVBMUw0KDQo+ID4gPiBwYXlsb2FkPw0KDQo+ID4gPiA+ID4+ IFNob3VsZCB3ZSBtYWtlIGVhY2ggU0ZGIHRvIGFsbG9jYXRlIGEgdW5pcXVlIGxhYmVsIGZvcg0K DQo+ID4gPiA+ID4+IGluZGljYXRpbmcgdGhlIHByZXNlbmNlIG9mIE5TSD8gT3Igc2hvdWxkIHdl IHVzZSB0aGUgY29udHJvbA0KDQo+ID4gPiA+ID4+IHdvcmQgdG8gaW5kaWNhdGUgaXQ/IE9yIHNo b3VsZCB3ZSByZWNvbnNpZGVyIHRoZSBwb3NzaWJpbGl0eSBvZg0KDQo+ID4gPiA+ID4+IGFkZGlu ZyBhbiBleHBsaWNpdCBwcm90b2NvbCBpZGVudGlmaWVyIGZpZWxkIHRvIHRoZSBNUExTDQoNCj4g PiA+ID4gPj4gZW5jYXBzdWxhdGlvbiBzbyBhcyB0byBzb2x2ZSBzdWNoIGtpbmQgb2YgaXNzdWVz DQoNCj4gPiA+ID4gb25jZSBhbmQgZm9yIGFsbD8NCg0KPiA+ID4gPiA+Pj4NCg0KPiA+ID4gPiA+ Pj4gQmVzdCByZWdhcmRzLA0KDQo+ID4gPiA+ID4+PiBYaWFvaHUNCg0KPiA+ID4gPiA+Pj4NCg0K PiA+ID4gPiA+Pg0KDQo+ID4gPiA+ID4+DQoNCj4gPiA+ID4gPj4gLS0NCg0KPiA+ID4gPiA+Pg0K DQo+ID4gPiA+DQoNCj4gPiA+DQoNCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKg0KDQo+ID4gPiAqKioNCg0KPiA+ID4gPiA+PiAqKioq DQoNCj4gPiA+ID4gPj4gICAgICAgICAgICAgICAgIMfrvMfXoaOsxOPKx7bA0rvO3rb+tcSjrL7N z/HG5Mv7w7/Su7j2yMvSu9H5DQoNCj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQo+ID4gPiA+ID4gbXBscyBtYWlsaW5nIGxpc3QNCg0K PiA+ID4gPiA+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQoNCj4gPiA+ID4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KPiA+ID4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gPiA+ ID4gPiBzZmMgbWFpbGluZyBsaXN0DQoNCj4gPiA+ID4gPiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCg0KPiA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQoNCj4gPiA+ID4gPg0KDQo+ID4gPiA+DQoNCj4gPiA+ID4gLS0NCg0KPiA+ID4g Pg0KDQo+ID4gPiA+DQoNCj4gPiA+ID4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAg ICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208bWFpbHRvOmxvYUBtYWlsMDEuaHVhd2Vp LmNvbT4NCg0KPiA+ID4gPiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAg ICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KDQo+ID4gPiA+IEh1YXdlaSBUZWNobm9s b2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K --_000_DB3PR03MB0812936A8223F4750DAEA9849D320DB3PR03MB0812eurp_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Xiaohu,

I would like to clarify my position. <= /p>

1.       Application level and a de= dicated ESP are two alternative options to indicate the presence of NSH in = the payload of a labeled packet.

a.       A dedicated ESP could be u= sed if association of the received packet with a specific SF instance withi= n the processing NE can be performed based exclusively on NSH. Just one ESP= label would be used (occupying 2 entries in the label stack), and it would just be treated as the NSH prese= nce indicator. This situation is similar to using the Generic Associated Ch= annel Label (GAL) in MPLS-TP.

b.      An application label per S= F instance should be used if the NSH header is not sufficient for defining = the SF instance that would handle the packet. A dedicated application label= would be allocated at least per SF instance within the NE, and some suitable protocol would be used for distr= ibuting association between this label and its specific SF instance. This i= s similar to using PW labels in PWs and/or Application labels (distributed = with their associated labeled IP-VPN routes) in L3VPN

c.       My knowledge of SFC is all= but on-existent, so I cannot say which of these two alternatives is releva= nt.

2.       In both cases the label (b= e it an application label or a dedicated ESP) must be inserted by the head-= end at the BoS so that it would be processed by the tail-end node of the LS= P without affecting any transit nodes (which would just perform standard MPLS forwarding).

3.       In the case of SF paths:

a.       If the dedicated ESP is us= ed, handling of the packet by the current SF must include definition of the= next SF node and forwarding to this node. The forwarded packet would again= include the dedicated ESP at the BoS, with the =A1=B0tunnel LSP=A1=B1 label stack on top of that=

b.      If the application label i= s used, the next SF node and the SF instance within this node could be infe= rred either from the payload or from the application label, or from their c= ombination. In any case forwarding of the packet to the next SF would result in swapping of the application l= abel at the BoS (similar to what is done in MS-PWs) and pushing the =A1=B0t= unnel LSP=A1=B1 label stack on top of that.

 

Not sure if this helps, or just adds more noiseJ.

 

Regards,

       Sasha <= /o:p>

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

 

 

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

> F= rom: Xuxiaohu [mailto:xuxiaohu@huawei.com]

> S= ent: Tuesday, January 27, 2015 10:59 AM

> T= o: Alexander Vainshtein

> C= c: mpls@ietf.org; sfc@ietf.org; Loa Andersson

> S= ubject: RE: [sfc] [mpls] How to indicate the presence of NSH in an MPLS

> p= acket?

>

> Hi Sasha,

>

> If only one application label is required to= be inserted into the label stack,

> where should it be inserted? at the BoS? If = so, it seems that the application

> label must be an ESP label.

>

> Best regards,

> Xiaohu

>

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

> > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]

> > Sent: Tuesday, January 27, 2015 4:46 PM=

> > To: Xuxiaohu

> > Cc: mpls@ietf.org; sfc@ietf.org; Loa Andersson

> > Subject: RE: [sfc] [mpls] How to indica= te the presence of NSH in an MPLS

> packet?

> >

> > Xiaoh hi!

> > I do not think you need multiple applic= ation labels.

> > Rather, you could swap these labels as = the packet progresses along the

> > SFP, same as is done with MS-PWs.

> >

> > Regards,

> >      &nbs= p; Sasha

> > Email: Alexander.Vainshtein@= ecitele.com

> > Mobile: 054-9266302

> >

> >

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

> > > From: Xuxiaohu [= mailto:xuxiaohu@huawei.com]

> > > Sent: Tuesday, January 27, 2015 9:= 46 AM

> > > To: Loa Andersson; Alexander Vains= htein

> > > Cc: mpls@ietf.org; sfc@ietf.org

> > > Subject: RE: [sfc] [mpls] How to i= ndicate the presence of NSH in an

> > > MPLS packet?

> > >

> > >

> > >

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

> > > > From: Loa Andersson [mailto:loa@pi.nu]

> > > > Sent: Tuesday, January 27, 20= 15 2:28 PM

> > > > To: Alexander Vainshtein; Xux= iaohu

> > > > Cc: mpls@ietf.org= ; sfc@ietf.org

> > > > Subject: Re: [sfc] [mpls] How= to indicate the presence of NSH in

> > > > an MPLS

> > > packet?

> > > >

> > > > Sasha,

> > > >

> > > >

> > > >

> > > > On 2015-01-26 14:21, Alexande= r Vainshtein wrote:

> > > > > Xiaohu, Huub,

> > > > > I do not follow the SFC = work closely, so I would like to

> > > > > understand whether the

> > > > NSH should be captured by&nbs= p; transit LSRs on the LSP - or just by

> > > > the LER acting as the LSP tai= l-end?

> > > > >

> > > > > If the latter is correct= , the simplest way to indicate presence

> > > > > of the NSH in the

> > > > MPLS payload would be by allo= cating an "application label"

> > > > indicating its presence by th= e tail-end LER and by inserting it at

> > > > the bottom of the label stack= by the head-end LER - similar to

> > > > what is done for L2/L3VPN.&nb= sp; Within this approach, if label-based

> > > > demultiplexing of packets wit= h NSH in the MPLS payload is not

> > > > required, you could request a= llocation of a new special purpose

> > > > label from the extended speci= al purposes label space as per RFC

> > > > 7274, and to insert such a la= bel

> > > (preceded by the Extension Label )= at the BoS.

> > > > >

> > > > I think "the latter"= ; is correct, the only issue I see is adding

> > > > one more label stack entry to= the label stack.

> > >

> > > Yes, the latter is correct. The is= sue of adding one more label stack

> > > entry to the label stack may becom= e unacceptable in the case where

> > > the Service Function Path (SFP) is= represented by an label stack

> > > while the NSH is now only used as = a metadata container. For example,

> > > for an SFP consist of n SFs, n &qu= ot;application labels" would have to be

> inserted into the label stack.

> > >

> > > Best regards,

> > > Xiaohu

> > >

> > > > /Loa

> > > > > If the former is correct= , the process above still has to be used

> > > > > but it has to be

> > > > augmented by adding the Route= r Alert Label   at the top of the label

> stack.

> > > > >

> > > > >  From my POV these = suggestions are in line with the provisions

> > > > > of Section 2.2

> > > > of RFC 3032 "Determining= the Network Layer Protocol" that states:

> > > > >

> > > > > <quote>

> > > > >     = When the last label is popped from a packet's label stack (resulting

> > > > >     = in the stack being emptied), further processing of the packet is

> > > > >     = based on the packet's network layer header.  The LSR which

> > > > > pops

> > the

> > > > >     = last label off the stack must therefore be able to identify the

> > > > >     = packet's network layer protocol.  However, the label stack does not

> > > > >     = contain any field which explicitly identifies the network layer

> > > > >     = protocol.  This means that the identity of the network layer protocol<= /p>

> > > > >     = must be inferable from the value of the label which is popped from

> > > > >     = the bottom of the stack, possibly along with the contents of the

> > > > >     = network layer header itself.

> > > > > <end quote>

> > > > >

> > > > > My 2c,

> > > > > Sasha

> > > > > ________________________= ________________

> > > > > From: mpls <mpls-bounces@ietf.org> on behalf of Xuxiaohu

> > > > > <xu= xiaohu@huawei.com>

> > > > > Sent: Monday, January 26= , 2015 5:05 AM

> > > > > To: h= uubatwork@gmail.com; sfc@ietf.org; mpls@ietf.org

> > > > > Subject: Re: [mpls] How = to indicate the presence of NSH in an

> > > > > MPLS

> > > packet?

> > > > >

> > > > > Hi Huub,

> > > > >

> > > > > The alter label itself c= ouldn=A1=AFt make the receiving LSR to

> > > > > determine the MPLS

> > > > payload type by examining the= MPLS payload.

> > > > >

> > > > > Best regards,

> > > > > Xiaohu

> > > > >

> > > > >> -----Original Messag= e-----

> > > > >> From: Huub van Helvo= ort [mailto:huubatwork@gmail.com]

> > > > >> Sent: Friday, Januar= y 23, 2015 6:28 PM

> > > > >> To: Xuxiaohu; sfc@ietf.org; mpls@ietf.org

> > > > >> Subject: Re: [mpls] = How to indicate the presence of NSH in an

> > > > >> MPLS

> > > packet?

> > > > >>

> > > > >> Xuxiaohu =C4=FA=BA=C3=A3=A1

> > > > >>

> > > > >> Please correct me if= I am wrong:

> > > > >>

> > > > >> It has always been m= y understanding that the MPLS header/label

> > > > >> was independent of t= he protocol/payload.

> > > > >> So no indication of = the actual payload content was necessary.

> > > > >>

> > > > >> IMHO you could use t= he alert label 1 to indicate to the LSR

> > > > >> that it has to furth= er examine the content of a packet.

> > > > >>

> > > > >> Regards, Huub.

> > > > >>

> > > > >> =3D=3D=3D=3D=3D=3D= =3D=3D

> > > > >>

> > > > >>> It said in (https://tools.ietf.org/html/draft-qui= nn-sfc-nsh-04):

> > > > >>>

> > > > >>>   = ;   The service header is independent of the encapsulation

> > > > >>> used and

> > is

> > > > >>>   = ;   encapsulated in existing transports.  The presence of NS= H is

> > > > >>>   = ;   indicated via protocol type or other indicator in the outer

> > > > >>>   = ;   encapsulation.

> > > > >>>

> > > > >>> In the case wher= e the outer encapsulation is an MPLS LSP, how

> > > > >>> to indicate the<= /p>

> > > > >> presence of NSH sinc= e the MPLS encapsulation has no explicit

> > > > >> protocol identifier = field to indicate the protocol type of the

> > > > >> MPLS

> > > payload?

> > > > >> Should we make each = SFF to allocate a unique label for

> > > > >> indicating the prese= nce of NSH? Or should we use the control

> > > > >> word to indicate it?= Or should we reconsider the possibility of

> > > > >> adding an explicit p= rotocol identifier field to the MPLS

> > > > >> encapsulation so as = to solve such kind of issues

> > > > once and for all?

> > > > >>>

> > > > >>> Best regards,

> > > > >>> Xiaohu

> > > > >>>

> > > > >>

> > > > >>

> > > > >> --

> > > > >>

> > > >

> > >

> ********************************************= **************

> > > ***

> > > > >> ****

> > > > >>   &nb= sp;            = =C7=EB=BC=C7=D7=A1=A3=AC=C4=E3=CA=C7=B6=C0=D2=BB=CE=DE=B6=FE=B5=C4=A3=AC=BE= =CD=CF=F1=C6=E4=CB=FB=C3=BF=D2=BB=B8=F6=C8=CB=D2=BB=D1=F9

> > > > > ________________________= _______________________

> > > > > mpls mailing list

> > > > > mpls@ietf.or= g

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

> > > > > ________________________= _______________________

> > > > > sfc mailing list

> > > > > sfc@ietf.org<= /span>

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

> > > > >

> > > >

> > > > --

> > > >

> > > >

> > > > Loa Andersson  &nbs= p;            &= nbsp;        email: loa@mail01.huawei.com=

> > > > Senior MPLS Expert  = ;            &n= bsp;           loa@pi.nu<= /p>

> > > > Huawei Technologies (consulta= nt)     phone: +46 739 81 21 64

--_000_DB3PR03MB0812936A8223F4750DAEA9849D320DB3PR03MB0812eurp_-- From nobody Tue Jan 27 07:37:54 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B981A883E; Tue, 27 Jan 2015 07:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9ajzPKOcj3P; Tue, 27 Jan 2015 07:37:44 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA171A883C; Tue, 27 Jan 2015 07:37:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D4C7A1C077E; Tue, 27 Jan 2015 07:37:43 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-12.clppva.east.verizon.net [70.106.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6AE8E1C0673; Tue, 27 Jan 2015 07:37:42 -0800 (PST) Message-ID: <54C7B084.3090709@joelhalpern.com> Date: Tue, 27 Jan 2015 10:36:36 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Xuxiaohu , Alexander Vainshtein , "huubatwork@gmail.com" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 15:37:46 -0000 I am a bit concerned by the tone of this which assumes that there is only one way to use MPLS as a transport for NSH. There are several different MPLS-based transport architectures that will work. As far as I can tell, most of them will even interoperate with each other. But they do imply different things about how NSH is indicated. As far as I can tell, all of the transport mechanisms operate on the assumption that forwarding devices between SFF will not see or need to be aware of the NSH header. Thus, those will always interoperate. In the MPLS case, whether one terminates the MPLS LSP at the first SFF, or allows to to cross several SFF affects how identification is done. Also, if segment routing is used then there are other options such as the use of dedicated local service labels for NSH delivery. (Doing that with conventional MPLS is more complex, but likely can also be done.) Yours, Joel On 1/27/15 1:45 AM, Xuxiaohu wrote: > Hi Sasha, > >> -----Original Message----- >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Monday, January 26, 2015 2:22 PM >> To: Xuxiaohu; huubatwork@gmail.com >> Cc: sfc@ietf.org; mpls@ietf.org >> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >> >> Xiaohu, Huub, >> I do not follow the SFC work closely, so I would like to understand whether the >> NSH should be captured by transit LSRs on the LSP - or just by the LER acting as >> the LSP tail-end? >> >> If the latter is correct, the simplest way to indicate presence of the NSH in the >> MPLS payload would be by allocating an "application label" indicating its >> presence by the tail-end LER and by inserting it at the bottom of the label stack >> by the head-end LER - similar to what is done for L2/L3VPN. Within this > > If I understand it correct, the above approach is the same as option 1 as I mentioned in the earlier email (i.e., making each SFF to allocate a unique label for indicating the > presence of NSH). > >> approach, if label-based demultiplexing of packets with NSH in the MPLS >> payload is not required, you could request allocation of a new special purpose >> label from the extended special purposes label space as per RFC 7274, and to >> insert such a label (preceded by the Extension Label ) at the BoS. > > What's the purpose of inserting a particular ESP label at the BoS? > > Best regards, > Xiaohu > >> If the former is correct, the process above still has to be used but it has to be >> augmented by adding the Router Alert Label at the top of the label stack. >> >> From my POV these suggestions are in line with the provisions of Section 2.2 of >> RFC 3032 "Determining the Network Layer Protocol" that states: >> >> >> When the last label is popped from a packet's label stack (resulting >> in the stack being emptied), further processing of the packet is >> based on the packet's network layer header. The LSR which pops the >> last label off the stack must therefore be able to identify the >> packet's network layer protocol. However, the label stack does not >> contain any field which explicitly identifies the network layer >> protocol. This means that the identity of the network layer protocol >> must be inferable from the value of the label which is popped from >> the bottom of the stack, possibly along with the contents of the >> network layer header itself. >> >> >> My 2c, >> Sasha >> ________________________________________ >> From: mpls on behalf of Xuxiaohu >> >> Sent: Monday, January 26, 2015 5:05 AM >> To: huubatwork@gmail.com; sfc@ietf.org; mpls@ietf.org >> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >> >> Hi Huub, >> >> The alter label itself couldn¡¯t make the receiving LSR to determine the MPLS >> payload type by examining the MPLS payload. >> >> Best regards, >> Xiaohu >> >>> -----Original Message----- >>> From: Huub van Helvoort [mailto:huubatwork@gmail.com] >>> Sent: Friday, January 23, 2015 6:28 PM >>> To: Xuxiaohu; sfc@ietf.org; mpls@ietf.org >>> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >>> >>> Xuxiaohu ÄúºÃ£¡ >>> >>> Please correct me if I am wrong: >>> >>> It has always been my understanding that the MPLS header/label was >>> independent of the protocol/payload. >>> So no indication of the actual payload content was necessary. >>> >>> IMHO you could use the alert label 1 to indicate to the LSR that it >>> has to further examine the content of a packet. >>> >>> Regards, Huub. >>> >>> ======== >>> >>>> It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04): >>>> >>>> The service header is independent of the encapsulation used and is >>>> encapsulated in existing transports. The presence of NSH is >>>> indicated via protocol type or other indicator in the outer >>>> encapsulation. >>>> >>>> In the case where the outer encapsulation is an MPLS LSP, how to >>>> indicate the >>> presence of NSH since the MPLS encapsulation has no explicit protocol >>> identifier field to indicate the protocol type of the MPLS payload? >>> Should we make each SFF to allocate a unique label for indicating the >>> presence of NSH? Or should we use the control word to indicate it? Or >>> should we reconsider the possibility of adding an explicit protocol >>> identifier field to the MPLS encapsulation so as to solve such kind of issues >> once and for all? >>>> >>>> Best regards, >>>> Xiaohu >>>> >>> >>> >>> -- >>> >> ************************************************************* >>> **** >>> Çë¼Çס£¬ÄãÊǶÀÒ»ÎÞ¶þµÄ£¬¾ÍÏñÆäËûÿһ¸öÈËÒ»Ñù >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Tue Jan 27 09:56:01 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBEF1A88F1; Tue, 27 Jan 2015 09:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.507 X-Spam-Level: X-Spam-Status: No, score=-1.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybDQKHtCu-dJ; Tue, 27 Jan 2015 09:55:44 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A614D1A1B38; Tue, 27 Jan 2015 09:55:37 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-c5-54c77e3ca922 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 6F.D6.03307.C3E77C45; Tue, 27 Jan 2015 13:02:05 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 12:55:36 -0500 From: David Allan I To: "mpls@ietf.org" , "sfc@ietf.org" Thread-Topic: [mpls] [sfc] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AQHQOfpp3GPXWcXE5UuPlLNIHMj25JzT6nIAgAAQoACAAAOvgIAAIiuAgAAbVeA= Date: Tue, 27 Jan 2015 17:55:35 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.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: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C39376271eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPuK5t3fEQg77FXBa3lq5ktXjyYCu7 A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyXq1uZyu4NYu54vfWZtYGxo3fmboYOTkkBEwkVi5Z zQJhi0lcuLeerYuRi0NI4AijxInuJcwQznJGid7OHWAdbAIGEnv+f2EEsUUEnCT+/7jNCmIL CwRJvOlqZoGIB0scefYUyvaTuHv9PFg9i4CqxIHmPcwgNq+Ar8T3W/PAbCGBXSwSDe1g9ZwC sRKrvt9mA7EZgS76fmoN2F5mAXGJW0/mQ10tILFkz3lmCFtU4uXjf6wQtqLEvv7p7BD1+RL/ dvxlhdglKHFy5hOWCYwis5CMmoWkbBaSMoi4lsS8ht9QNYoSU7ofskPYmhJXJh+CsrUlli18 zbyAkX0VI0dpcWpZbrqRwSZGYOQck2DT3cG456XlIUYBDkYlHt4NfcdChFgTy4orcw8xSnOw KInzLnpwMERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY+mF2S3KhUvKf+ndUJ99ee2i+UEW /s9u7Yg99JDz+0ex2M1tItvOTd7xiPNBgN6LGZ+2vb856VCFuMeiVxP71lzf3XXv0uaEzKn8 6/8pXd2ftcCqa9JsRR0pqa+f87gUXDLqM6OiP39Q+/PJo/1f86/mO+x8rAlFnP1lEpeUOp8/ NdDJfC3eEKTEUpyRaKjFXFScCACE6CB9fQIAAA== Archived-At: Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 17:55:57 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C39376271eusaamb105erics_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgZm9sa3M6DQoNCkNvcnJlY3QgbWUgaWYgSaGvbSB3cm9uZywgYnV0IGlzbqGvdCBhbnkgbGFi ZWwgc3RhY2sgZGlyZWN0bHkgcHJlcGVuZGluZyBhbiBOU0ggdGhhdCBpcyBjb21wb3NlZCBlbnRp cmVseSBvZiBub24tcmVzZXJ2ZWQgbGFiZWxzIGdvaW5nIHRvIG1lYW4gYW4gU0ZDIGhlYWRlciAo YXQgbGVhc3QgZm9yIG5vbiBPQU0sIG5vbiBjcml0aWNhbCBtZXRhZGF0YSwgdmVyc2lvbiAxIHBh Y2tldHMpIHdpbGwgYWxpYXMgYXMgYW4gSVB2NCBwYWNrZXQgZm9yIHByZXR0eSBtdWNoIGFsbCB0 cmFuc2l0IExTUnM/IEFuZCB2ZXJzaW9uIDEgT0FNIHBhY2tldHMgd2lsbCBhbGlhcyBhcyBJUHY2 IGJsb3dpbmcgb3V0IGZhdGUgc2hhcmluZz8gSW4gZWl0aGVyIGNhc2UsIG9idGFpbmluZyBlbnRy b3B5IGZvciBFQ01QIGJ5IHRyYW5zaXQgTFNScyB3aWxsIGJlIG92ZXJsYWlkIG9uIHRoZSBiYXNl IGFuZCBzZXJ2aWNlIHBhdGggaGVhZGVycyAoYW5kIGJleW9uZCBmb3IgSVB2NiBhbGlhc2luZymh rS4NCg0KUmVnYXJkcw0KRGF2ZQ0KDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZGVyIFZhaW5zaHRlaW4NClNlbnQ6IFR1ZXNkYXks IEphbnVhcnkgMjcsIDIwMTUgMzowMSBBTQ0KVG86IFh1eGlhb2h1DQpDYzogbXBsc0BpZXRmLm9y Zzsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIFtzZmNdIEhvdyB0byBpbmRpY2F0 ZSB0aGUgcHJlc2VuY2Ugb2YgTlNIIGluIGFuIE1QTFMgcGFja2V0Pw0KDQoNClhpYW9odSwNCg0K SSB3b3VsZCBsaWtlIHRvIGNsYXJpZnkgbXkgcG9zaXRpb24uDQoNCjEuICAgICAgIEFwcGxpY2F0 aW9uIGxldmVsIGFuZCBhIGRlZGljYXRlZCBFU1AgYXJlIHR3byBhbHRlcm5hdGl2ZSBvcHRpb25z IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gdGhlIHBheWxvYWQgb2YgYSBsYWJl bGVkIHBhY2tldC4NCg0KYS4gICAgICAgQSBkZWRpY2F0ZWQgRVNQIGNvdWxkIGJlIHVzZWQgaWYg YXNzb2NpYXRpb24gb2YgdGhlIHJlY2VpdmVkIHBhY2tldCB3aXRoIGEgc3BlY2lmaWMgU0YgaW5z dGFuY2Ugd2l0aGluIHRoZSBwcm9jZXNzaW5nIE5FIGNhbiBiZSBwZXJmb3JtZWQgYmFzZWQgZXhj bHVzaXZlbHkgb24gTlNILiBKdXN0IG9uZSBFU1AgbGFiZWwgd291bGQgYmUgdXNlZCAob2NjdXB5 aW5nIDIgZW50cmllcyBpbiB0aGUgbGFiZWwgc3RhY2spLCBhbmQgaXQgd291bGQganVzdCBiZSB0 cmVhdGVkIGFzIHRoZSBOU0ggcHJlc2VuY2UgaW5kaWNhdG9yLiBUaGlzIHNpdHVhdGlvbiBpcyBz aW1pbGFyIHRvIHVzaW5nIHRoZSBHZW5lcmljIEFzc29jaWF0ZWQgQ2hhbm5lbCBMYWJlbCAoR0FM KSBpbiBNUExTLVRQLg0KDQpiLiAgICAgIEFuIGFwcGxpY2F0aW9uIGxhYmVsIHBlciBTRiBpbnN0 YW5jZSBzaG91bGQgYmUgdXNlZCBpZiB0aGUgTlNIIGhlYWRlciBpcyBub3Qgc3VmZmljaWVudCBm b3IgZGVmaW5pbmcgdGhlIFNGIGluc3RhbmNlIHRoYXQgd291bGQgaGFuZGxlIHRoZSBwYWNrZXQu IEEgZGVkaWNhdGVkIGFwcGxpY2F0aW9uIGxhYmVsIHdvdWxkIGJlIGFsbG9jYXRlZCBhdCBsZWFz dCBwZXIgU0YgaW5zdGFuY2Ugd2l0aGluIHRoZSBORSwgYW5kIHNvbWUgc3VpdGFibGUgcHJvdG9j b2wgd291bGQgYmUgdXNlZCBmb3IgZGlzdHJpYnV0aW5nIGFzc29jaWF0aW9uIGJldHdlZW4gdGhp cyBsYWJlbCBhbmQgaXRzIHNwZWNpZmljIFNGIGluc3RhbmNlLiBUaGlzIGlzIHNpbWlsYXIgdG8g dXNpbmcgUFcgbGFiZWxzIGluIFBXcyBhbmQvb3IgQXBwbGljYXRpb24gbGFiZWxzIChkaXN0cmli dXRlZCB3aXRoIHRoZWlyIGFzc29jaWF0ZWQgbGFiZWxlZCBJUC1WUE4gcm91dGVzKSBpbiBMM1ZQ Tg0KDQpjLiAgICAgICBNeSBrbm93bGVkZ2Ugb2YgU0ZDIGlzIGFsbCBidXQgb24tZXhpc3RlbnQs IHNvIEkgY2Fubm90IHNheSB3aGljaCBvZiB0aGVzZSB0d28gYWx0ZXJuYXRpdmVzIGlzIHJlbGV2 YW50Lg0KDQoyLiAgICAgICBJbiBib3RoIGNhc2VzIHRoZSBsYWJlbCAoYmUgaXQgYW4gYXBwbGlj YXRpb24gbGFiZWwgb3IgYSBkZWRpY2F0ZWQgRVNQKSBtdXN0IGJlIGluc2VydGVkIGJ5IHRoZSBo ZWFkLWVuZCBhdCB0aGUgQm9TIHNvIHRoYXQgaXQgd291bGQgYmUgcHJvY2Vzc2VkIGJ5IHRoZSB0 YWlsLWVuZCBub2RlIG9mIHRoZSBMU1Agd2l0aG91dCBhZmZlY3RpbmcgYW55IHRyYW5zaXQgbm9k ZXMgKHdoaWNoIHdvdWxkIGp1c3QgcGVyZm9ybSBzdGFuZGFyZCBNUExTIGZvcndhcmRpbmcpLg0K DQozLiAgICAgICBJbiB0aGUgY2FzZSBvZiBTRiBwYXRoczoNCg0KYS4gICAgICAgSWYgdGhlIGRl ZGljYXRlZCBFU1AgaXMgdXNlZCwgaGFuZGxpbmcgb2YgdGhlIHBhY2tldCBieSB0aGUgY3VycmVu dCBTRiBtdXN0IGluY2x1ZGUgZGVmaW5pdGlvbiBvZiB0aGUgbmV4dCBTRiBub2RlIGFuZCBmb3J3 YXJkaW5nIHRvIHRoaXMgbm9kZS4gVGhlIGZvcndhcmRlZCBwYWNrZXQgd291bGQgYWdhaW4gaW5j bHVkZSB0aGUgZGVkaWNhdGVkIEVTUCBhdCB0aGUgQm9TLCB3aXRoIHRoZSChsHR1bm5lbCBMU1Ch sSBsYWJlbCBzdGFjayBvbiB0b3Agb2YgdGhhdA0KDQpiLiAgICAgIElmIHRoZSBhcHBsaWNhdGlv biBsYWJlbCBpcyB1c2VkLCB0aGUgbmV4dCBTRiBub2RlIGFuZCB0aGUgU0YgaW5zdGFuY2Ugd2l0 aGluIHRoaXMgbm9kZSBjb3VsZCBiZSBpbmZlcnJlZCBlaXRoZXIgZnJvbSB0aGUgcGF5bG9hZCBv ciBmcm9tIHRoZSBhcHBsaWNhdGlvbiBsYWJlbCwgb3IgZnJvbSB0aGVpciBjb21iaW5hdGlvbi4g SW4gYW55IGNhc2UgZm9yd2FyZGluZyBvZiB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNGIHdvdWxk IHJlc3VsdCBpbiBzd2FwcGluZyBvZiB0aGUgYXBwbGljYXRpb24gbGFiZWwgYXQgdGhlIEJvUyAo c2ltaWxhciB0byB3aGF0IGlzIGRvbmUgaW4gTVMtUFdzKSBhbmQgcHVzaGluZyB0aGUgobB0dW5u ZWwgTFNQobEgbGFiZWwgc3RhY2sgb24gdG9wIG9mIHRoYXQuDQoNCg0KDQpOb3Qgc3VyZSBpZiB0 aGlzIGhlbHBzLCBvciBqdXN0IGFkZHMgbW9yZSBub2lzZTopLg0KDQoNCg0KUmVnYXJkcywNCg0K ICAgICAgIFNhc2hhDQoNCkVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxt YWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQoNCk1vYmlsZTogMDU0LTky NjYzMDINCg0KDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTog WHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXQ0KDQo+IFNlbnQ6IFR1ZXNkYXks IEphbnVhcnkgMjcsIDIwMTUgMTA6NTkgQU0NCg0KPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW4N Cg0KPiBDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPjsgTG9hIEFuZGVyc3Nvbg0KDQo+IFN1YmplY3Q6IFJFOiBb c2ZjXSBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBM Uw0KDQo+IHBhY2tldD8NCg0KPg0KDQo+IEhpIFNhc2hhLA0KDQo+DQoNCj4gSWYgb25seSBvbmUg YXBwbGljYXRpb24gbGFiZWwgaXMgcmVxdWlyZWQgdG8gYmUgaW5zZXJ0ZWQgaW50byB0aGUgbGFi ZWwgc3RhY2ssDQoNCj4gd2hlcmUgc2hvdWxkIGl0IGJlIGluc2VydGVkPyBhdCB0aGUgQm9TPyBJ ZiBzbywgaXQgc2VlbXMgdGhhdCB0aGUgYXBwbGljYXRpb24NCg0KPiBsYWJlbCBtdXN0IGJlIGFu IEVTUCBsYWJlbC4NCg0KPg0KDQo+IEJlc3QgcmVnYXJkcywNCg0KPiBYaWFvaHUNCg0KPg0KDQo+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiA+IEZyb206IEFsZXhhbmRlciBWYWlu c2h0ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dDQoNCj4gPiBT ZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1IDQ6NDYgUE0NCg0KPiA+IFRvOiBYdXhpYW9o dQ0KDQo+ID4gQ2M6IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47IExvYSBBbmRlcnNzb24NCg0KPiA+IFN1YmplY3Q6 IFJFOiBbc2ZjXSBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4g YW4gTVBMUw0KDQo+IHBhY2tldD8NCg0KPiA+DQoNCj4gPiBYaWFvaCBoaSENCg0KPiA+IEkgZG8g bm90IHRoaW5rIHlvdSBuZWVkIG11bHRpcGxlIGFwcGxpY2F0aW9uIGxhYmVscy4NCg0KPiA+IFJh dGhlciwgeW91IGNvdWxkIHN3YXAgdGhlc2UgbGFiZWxzIGFzIHRoZSBwYWNrZXQgcHJvZ3Jlc3Nl cyBhbG9uZyB0aGUNCg0KPiA+IFNGUCwgc2FtZSBhcyBpcyBkb25lIHdpdGggTVMtUFdzLg0KDQo+ ID4NCg0KPiA+IFJlZ2FyZHMsDQoNCj4gPiAgICAgICAgU2FzaGENCg0KPiA+IEVtYWlsOiBBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20+DQoNCj4gPiBNb2JpbGU6IDA1NC05MjY2MzAyDQoNCj4gPg0KDQo+ID4NCg0K PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiA+ID4gRnJvbTogWHV4aWFvaHUg W21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXQ0KDQo+ID4gPiBTZW50OiBUdWVzZGF5LCBKYW51 YXJ5IDI3LCAyMDE1IDk6NDYgQU0NCg0KPiA+ID4gVG86IExvYSBBbmRlcnNzb247IEFsZXhhbmRl ciBWYWluc2h0ZWluDQoNCj4gPiA+IENjOiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYu b3JnPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQoNCj4gPiA+IFN1YmplY3Q6 IFJFOiBbc2ZjXSBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4g YW4NCg0KPiA+ID4gTVBMUyBwYWNrZXQ/DQoNCj4gPiA+DQoNCj4gPiA+DQoNCj4gPiA+DQoNCj4g PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiA+ID4gPiBGcm9tOiBMb2EgQW5k ZXJzc29uIFttYWlsdG86bG9hQHBpLm51XQ0KDQo+ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIEphbnVh cnkgMjcsIDIwMTUgMjoyOCBQTQ0KDQo+ID4gPiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsg WHV4aWFvaHUNCg0KPiA+ID4gPiBDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9y Zz47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KDQo+ID4gPiA+IFN1YmplY3Q6 IFJlOiBbc2ZjXSBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4N Cg0KPiA+ID4gPiBhbiBNUExTDQoNCj4gPiA+IHBhY2tldD8NCg0KPiA+ID4gPg0KDQo+ID4gPiA+ IFNhc2hhLA0KDQo+ID4gPiA+DQoNCj4gPiA+ID4NCg0KPiA+ID4gPg0KDQo+ID4gPiA+IE9uIDIw MTUtMDEtMjYgMTQ6MjEsIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOg0KDQo+ID4gPiA+ID4g WGlhb2h1LCBIdXViLA0KDQo+ID4gPiA+ID4gSSBkbyBub3QgZm9sbG93IHRoZSBTRkMgd29yayBj bG9zZWx5LCBzbyBJIHdvdWxkIGxpa2UgdG8NCg0KPiA+ID4gPiA+IHVuZGVyc3RhbmQgd2hldGhl ciB0aGUNCg0KPiA+ID4gPiBOU0ggc2hvdWxkIGJlIGNhcHR1cmVkIGJ5ICB0cmFuc2l0IExTUnMg b24gdGhlIExTUCAtIG9yIGp1c3QgYnkNCg0KPiA+ID4gPiB0aGUgTEVSIGFjdGluZyBhcyB0aGUg TFNQIHRhaWwtZW5kPw0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+IElmIHRoZSBsYXR0ZXIgaXMg Y29ycmVjdCwgdGhlIHNpbXBsZXN0IHdheSB0byBpbmRpY2F0ZSBwcmVzZW5jZQ0KDQo+ID4gPiA+ ID4gb2YgdGhlIE5TSCBpbiB0aGUNCg0KPiA+ID4gPiBNUExTIHBheWxvYWQgd291bGQgYmUgYnkg YWxsb2NhdGluZyBhbiAiYXBwbGljYXRpb24gbGFiZWwiDQoNCj4gPiA+ID4gaW5kaWNhdGluZyBp dHMgcHJlc2VuY2UgYnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5zZXJ0aW5nIGl0IGF0DQoN Cj4gPiA+ID4gdGhlIGJvdHRvbSBvZiB0aGUgbGFiZWwgc3RhY2sgYnkgdGhlIGhlYWQtZW5kIExF UiAtIHNpbWlsYXIgdG8NCg0KPiA+ID4gPiB3aGF0IGlzIGRvbmUgZm9yIEwyL0wzVlBOLiAgV2l0 aGluIHRoaXMgYXBwcm9hY2gsIGlmIGxhYmVsLWJhc2VkDQoNCj4gPiA+ID4gZGVtdWx0aXBsZXhp bmcgb2YgcGFja2V0cyB3aXRoIE5TSCBpbiB0aGUgTVBMUyBwYXlsb2FkIGlzIG5vdA0KDQo+ID4g PiA+IHJlcXVpcmVkLCB5b3UgY291bGQgcmVxdWVzdCBhbGxvY2F0aW9uIG9mIGEgbmV3IHNwZWNp YWwgcHVycG9zZQ0KDQo+ID4gPiA+IGxhYmVsIGZyb20gdGhlIGV4dGVuZGVkIHNwZWNpYWwgcHVy cG9zZXMgbGFiZWwgc3BhY2UgYXMgcGVyIFJGQw0KDQo+ID4gPiA+IDcyNzQsIGFuZCB0byBpbnNl cnQgc3VjaCBhIGxhYmVsDQoNCj4gPiA+IChwcmVjZWRlZCBieSB0aGUgRXh0ZW5zaW9uIExhYmVs ICkgYXQgdGhlIEJvUy4NCg0KPiA+ID4gPiA+DQoNCj4gPiA+ID4gSSB0aGluayAidGhlIGxhdHRl ciIgaXMgY29ycmVjdCwgdGhlIG9ubHkgaXNzdWUgSSBzZWUgaXMgYWRkaW5nDQoNCj4gPiA+ID4g b25lIG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8gdGhlIGxhYmVsIHN0YWNrLg0KDQo+ID4gPg0K DQo+ID4gPiBZZXMsIHRoZSBsYXR0ZXIgaXMgY29ycmVjdC4gVGhlIGlzc3VlIG9mIGFkZGluZyBv bmUgbW9yZSBsYWJlbCBzdGFjaw0KDQo+ID4gPiBlbnRyeSB0byB0aGUgbGFiZWwgc3RhY2sgbWF5 IGJlY29tZSB1bmFjY2VwdGFibGUgaW4gdGhlIGNhc2Ugd2hlcmUNCg0KPiA+ID4gdGhlIFNlcnZp Y2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBpcyByZXByZXNlbnRlZCBieSBhbiBsYWJlbCBzdGFjaw0K DQo+ID4gPiB3aGlsZSB0aGUgTlNIIGlzIG5vdyBvbmx5IHVzZWQgYXMgYSBtZXRhZGF0YSBjb250 YWluZXIuIEZvciBleGFtcGxlLA0KDQo+ID4gPiBmb3IgYW4gU0ZQIGNvbnNpc3Qgb2YgbiBTRnMs IG4gImFwcGxpY2F0aW9uIGxhYmVscyIgd291bGQgaGF2ZSB0byBiZQ0KDQo+IGluc2VydGVkIGlu dG8gdGhlIGxhYmVsIHN0YWNrLg0KDQo+ID4gPg0KDQo+ID4gPiBCZXN0IHJlZ2FyZHMsDQoNCj4g PiA+IFhpYW9odQ0KDQo+ID4gPg0KDQo+ID4gPiA+IC9Mb2ENCg0KPiA+ID4gPiA+IElmIHRoZSBm b3JtZXIgaXMgY29ycmVjdCwgdGhlIHByb2Nlc3MgYWJvdmUgc3RpbGwgaGFzIHRvIGJlIHVzZWQN Cg0KPiA+ID4gPiA+IGJ1dCBpdCBoYXMgdG8gYmUNCg0KPiA+ID4gPiBhdWdtZW50ZWQgYnkgYWRk aW5nIHRoZSBSb3V0ZXIgQWxlcnQgTGFiZWwgICBhdCB0aGUgdG9wIG9mIHRoZSBsYWJlbA0KDQo+ IHN0YWNrLg0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+ICBGcm9tIG15IFBPViB0aGVzZSBzdWdn ZXN0aW9ucyBhcmUgaW4gbGluZSB3aXRoIHRoZSBwcm92aXNpb25zDQoNCj4gPiA+ID4gPiBvZiBT ZWN0aW9uIDIuMg0KDQo+ID4gPiA+IG9mIFJGQyAzMDMyICJEZXRlcm1pbmluZyB0aGUgTmV0d29y ayBMYXllciBQcm90b2NvbCIgdGhhdCBzdGF0ZXM6DQoNCj4gPiA+ID4gPg0KDQo+ID4gPiA+ID4g PHF1b3RlPg0KDQo+ID4gPiA+ID4gICAgIFdoZW4gdGhlIGxhc3QgbGFiZWwgaXMgcG9wcGVkIGZy b20gYSBwYWNrZXQncyBsYWJlbCBzdGFjayAocmVzdWx0aW5nDQoNCj4gPiA+ID4gPiAgICAgaW4g dGhlIHN0YWNrIGJlaW5nIGVtcHRpZWQpLCBmdXJ0aGVyIHByb2Nlc3Npbmcgb2YgdGhlIHBhY2tl dCBpcw0KDQo+ID4gPiA+ID4gICAgIGJhc2VkIG9uIHRoZSBwYWNrZXQncyBuZXR3b3JrIGxheWVy IGhlYWRlci4gIFRoZSBMU1Igd2hpY2gNCg0KPiA+ID4gPiA+IHBvcHMNCg0KPiA+IHRoZQ0KDQo+ ID4gPiA+ID4gICAgIGxhc3QgbGFiZWwgb2ZmIHRoZSBzdGFjayBtdXN0IHRoZXJlZm9yZSBiZSBh YmxlIHRvIGlkZW50aWZ5IHRoZQ0KDQo+ID4gPiA+ID4gICAgIHBhY2tldCdzIG5ldHdvcmsgbGF5 ZXIgcHJvdG9jb2wuICBIb3dldmVyLCB0aGUgbGFiZWwgc3RhY2sgZG9lcyBub3QNCg0KPiA+ID4g PiA+ICAgICBjb250YWluIGFueSBmaWVsZCB3aGljaCBleHBsaWNpdGx5IGlkZW50aWZpZXMgdGhl IG5ldHdvcmsgbGF5ZXINCg0KPiA+ID4gPiA+ICAgICBwcm90b2NvbC4gIFRoaXMgbWVhbnMgdGhh dCB0aGUgaWRlbnRpdHkgb2YgdGhlIG5ldHdvcmsgbGF5ZXIgcHJvdG9jb2wNCg0KPiA+ID4gPiA+ ICAgICBtdXN0IGJlIGluZmVyYWJsZSBmcm9tIHRoZSB2YWx1ZSBvZiB0aGUgbGFiZWwgd2hpY2gg aXMgcG9wcGVkIGZyb20NCg0KPiA+ID4gPiA+ICAgICB0aGUgYm90dG9tIG9mIHRoZSBzdGFjaywg cG9zc2libHkgYWxvbmcgd2l0aCB0aGUgY29udGVudHMgb2YgdGhlDQoNCj4gPiA+ID4gPiAgICAg bmV0d29yayBsYXllciBoZWFkZXIgaXRzZWxmLg0KDQo+ID4gPiA+ID4gPGVuZCBxdW90ZT4NCg0K PiA+ID4gPiA+DQoNCj4gPiA+ID4gPiBNeSAyYywNCg0KPiA+ID4gPiA+IFNhc2hhDQoNCj4gPiA+ ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gPiA+ID4g PiBGcm9tOiBtcGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBYdXhpYW9odQ0KDQo+ID4gPiA+ID4gPHh1eGlhb2h1QGh1 YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+Pg0KDQo+ID4gPiA+ID4gU2VudDog TW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDU6MDUgQU0NCg0KPiA+ID4gPiA+IFRvOiBodXViYXR3 b3JrQGdtYWlsLmNvbTxtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20+OyBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+ DQoNCj4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0ZSB0aGUgcHJl c2VuY2Ugb2YgTlNIIGluIGFuDQoNCj4gPiA+ID4gPiBNUExTDQoNCj4gPiA+IHBhY2tldD8NCg0K PiA+ID4gPiA+DQoNCj4gPiA+ID4gPiBIaSBIdXViLA0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+ IFRoZSBhbHRlciBsYWJlbCBpdHNlbGYgY291bGRuoa90IG1ha2UgdGhlIHJlY2VpdmluZyBMU1Ig dG8NCg0KPiA+ID4gPiA+IGRldGVybWluZSB0aGUgTVBMUw0KDQo+ID4gPiA+IHBheWxvYWQgdHlw ZSBieSBleGFtaW5pbmcgdGhlIE1QTFMgcGF5bG9hZC4NCg0KPiA+ID4gPiA+DQoNCj4gPiA+ID4g PiBCZXN0IHJlZ2FyZHMsDQoNCj4gPiA+ID4gPiBYaWFvaHUNCg0KPiA+ID4gPiA+DQoNCj4gPiA+ ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiA+ID4gPiA+PiBGcm9tOiBIdXVi IHZhbiBIZWx2b29ydCBbbWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tXQ0KDQo+ID4gPiA+ID4+ IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAyMywgMjAxNSA2OjI4IFBNDQoNCj4gPiA+ID4gPj4gVG86 IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47IG1wbHNAaWV0Zi5v cmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQoNCj4gPiA+ID4gPj4gU3ViamVjdDogUmU6IFttcGxz XSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbg0KDQo+ID4gPiA+ID4+ IE1QTFMNCg0KPiA+ID4gcGFja2V0Pw0KDQo+ID4gPiA+ID4+DQoNCj4gPiA+ID4gPj4gWHV4aWFv aHUgxPq6w6OhDQoNCj4gPiA+ID4gPj4NCg0KPiA+ID4gPiA+PiBQbGVhc2UgY29ycmVjdCBtZSBp ZiBJIGFtIHdyb25nOg0KDQo+ID4gPiA+ID4+DQoNCj4gPiA+ID4gPj4gSXQgaGFzIGFsd2F5cyBi ZWVuIG15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgTVBMUyBoZWFkZXIvbGFiZWwNCg0KPiA+ID4g PiA+PiB3YXMgaW5kZXBlbmRlbnQgb2YgdGhlIHByb3RvY29sL3BheWxvYWQuDQoNCj4gPiA+ID4g Pj4gU28gbm8gaW5kaWNhdGlvbiBvZiB0aGUgYWN0dWFsIHBheWxvYWQgY29udGVudCB3YXMgbmVj ZXNzYXJ5Lg0KDQo+ID4gPiA+ID4+DQoNCj4gPiA+ID4gPj4gSU1ITyB5b3UgY291bGQgdXNlIHRo ZSBhbGVydCBsYWJlbCAxIHRvIGluZGljYXRlIHRvIHRoZSBMU1INCg0KPiA+ID4gPiA+PiB0aGF0 IGl0IGhhcyB0byBmdXJ0aGVyIGV4YW1pbmUgdGhlIGNvbnRlbnQgb2YgYSBwYWNrZXQuDQoNCj4g PiA+ID4gPj4NCg0KPiA+ID4gPiA+PiBSZWdhcmRzLCBIdXViLg0KDQo+ID4gPiA+ID4+DQoNCj4g PiA+ID4gPj4gPT09PT09PT0NCg0KPiA+ID4gPiA+Pg0KDQo+ID4gPiA+ID4+PiBJdCBzYWlkIGlu IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tc2ZjLW5zaC0wNCk6DQoN Cj4gPiA+ID4gPj4+DQoNCj4gPiA+ID4gPj4+ICAgICAgVGhlIHNlcnZpY2UgaGVhZGVyIGlzIGlu ZGVwZW5kZW50IG9mIHRoZSBlbmNhcHN1bGF0aW9uDQoNCj4gPiA+ID4gPj4+IHVzZWQgYW5kDQoN Cj4gPiBpcw0KDQo+ID4gPiA+ID4+PiAgICAgIGVuY2Fwc3VsYXRlZCBpbiBleGlzdGluZyB0cmFu c3BvcnRzLiAgVGhlIHByZXNlbmNlIG9mIE5TSCBpcw0KDQo+ID4gPiA+ID4+PiAgICAgIGluZGlj YXRlZCB2aWEgcHJvdG9jb2wgdHlwZSBvciBvdGhlciBpbmRpY2F0b3IgaW4gdGhlIG91dGVyDQoN Cj4gPiA+ID4gPj4+ICAgICAgZW5jYXBzdWxhdGlvbi4NCg0KPiA+ID4gPiA+Pj4NCg0KPiA+ID4g PiA+Pj4gSW4gdGhlIGNhc2Ugd2hlcmUgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24gaXMgYW4gTVBM UyBMU1AsIGhvdw0KDQo+ID4gPiA+ID4+PiB0byBpbmRpY2F0ZSB0aGUNCg0KPiA+ID4gPiA+PiBw cmVzZW5jZSBvZiBOU0ggc2luY2UgdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBoYXMgbm8gZXhwbGlj aXQNCg0KPiA+ID4gPiA+PiBwcm90b2NvbCBpZGVudGlmaWVyIGZpZWxkIHRvIGluZGljYXRlIHRo ZSBwcm90b2NvbCB0eXBlIG9mIHRoZQ0KDQo+ID4gPiA+ID4+IE1QTFMNCg0KPiA+ID4gcGF5bG9h ZD8NCg0KPiA+ID4gPiA+PiBTaG91bGQgd2UgbWFrZSBlYWNoIFNGRiB0byBhbGxvY2F0ZSBhIHVu aXF1ZSBsYWJlbCBmb3INCg0KPiA+ID4gPiA+PiBpbmRpY2F0aW5nIHRoZSBwcmVzZW5jZSBvZiBO U0g/IE9yIHNob3VsZCB3ZSB1c2UgdGhlIGNvbnRyb2wNCg0KPiA+ID4gPiA+PiB3b3JkIHRvIGlu ZGljYXRlIGl0PyBPciBzaG91bGQgd2UgcmVjb25zaWRlciB0aGUgcG9zc2liaWxpdHkgb2YNCg0K PiA+ID4gPiA+PiBhZGRpbmcgYW4gZXhwbGljaXQgcHJvdG9jb2wgaWRlbnRpZmllciBmaWVsZCB0 byB0aGUgTVBMUw0KDQo+ID4gPiA+ID4+IGVuY2Fwc3VsYXRpb24gc28gYXMgdG8gc29sdmUgc3Vj aCBraW5kIG9mIGlzc3Vlcw0KDQo+ID4gPiA+IG9uY2UgYW5kIGZvciBhbGw/DQoNCj4gPiA+ID4g Pj4+DQoNCj4gPiA+ID4gPj4+IEJlc3QgcmVnYXJkcywNCg0KPiA+ID4gPiA+Pj4gWGlhb2h1DQoN Cj4gPiA+ID4gPj4+DQoNCj4gPiA+ID4gPj4NCg0KPiA+ID4gPiA+Pg0KDQo+ID4gPiA+ID4+IC0t DQoNCj4gPiA+ID4gPj4NCg0KPiA+ID4gPg0KDQo+ID4gPg0KDQo+ICoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KPiA+ID4gKioqDQoN Cj4gPiA+ID4gPj4gKioqKg0KDQo+ID4gPiA+ID4+ICAgICAgICAgICAgICAgICDH67zH16GjrMTj yse2wNK7zt62/rXEo6y+zc/xxuTL+8O/0ru49sjL0rvR+Q0KDQo+ID4gPiA+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPiA+ID4gPiA+IG1wbHMg bWFpbGluZyBsaXN0DQoNCj4gPiA+ID4gPiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYu b3JnPg0KDQo+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQoNCj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQo+ID4gPiA+ID4gc2ZjIG1haWxpbmcgbGlzdA0KDQo+ID4gPiA+ID4gc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQoNCj4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPg0KDQo+ID4g PiA+IC0tDQoNCj4gPiA+ID4NCg0KPiA+ID4gPg0KDQo+ID4gPiA+IExvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzps b2FAbWFpbDAxLmh1YXdlaS5jb20+DQoNCj4gPiA+ID4gU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAg ICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4NCg0KPiA+ID4g PiBIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEg MjEgNjQNCg== --_000_E6C17D2345AC7A45B7D054D407AA205C39376271eusaamb105erics_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi folks:

 

Correct me if I=A1=AFm= wrong, but isn=A1=AFt any label stack directly prepending an NSH that is c= omposed entirely of non-reserved labels going to mean an SFC header (at lea= st for non OAM, non critical metadata, version 1 packets) will alias as an IPv4 packet for pretty much all transit LSRs? = And version 1 OAM packets will alias as IPv6 blowing out fate sharing? In e= ither case, obtaining entropy for ECMP by transit LSRs will be overlaid on = the base and service path headers (and beyond for IPv6 aliasing)=A1=AD.

 

Regards

Dave=

 

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Tuesday, January 27, 2015 3:01 AM
To: Xuxiaohu
Cc: mpls@ietf.org; sfc@ietf.org
Subject: Re: [mpls] [sfc] How to indicate the presence of NSH in an = MPLS packet?

 

Xiaohu,

I would like to clarify my position. <= /p>

1.       Application level and a dedicated ESP are two alter= native options to indicate the presence of NSH in the payload of a labeled = packet.

a.       A dedicated ESP could be used if association of the= received packet with a specific SF instance within the processing NE can b= e performed based exclusively on NSH. Just one ESP label would be used (occ= upying 2 entries in the label stack), and it would just be treated as the NSH presence indicator. This situation= is similar to using the Generic Associated Channel Label (GAL) in MPLS-TP.=

b.      An application label per SF instance should be used= if the NSH header is not sufficient for defining the SF instance that woul= d handle the packet. A dedicated application label would be allocated at le= ast per SF instance within the NE, and some suitable protocol would be used for distributing association betw= een this label and its specific SF instance. This is similar to using PW la= bels in PWs and/or Application labels (distributed with their associated la= beled IP-VPN routes) in L3VPN

c.       My knowledge of SFC is all but on-existent, so I ca= nnot say which of these two alternatives is relevant.

2.       In both cases the label (be it an application label= or a dedicated ESP) must be inserted by the head-end at the BoS so that it= would be processed by the tail-end node of the LSP without affecting any t= ransit nodes (which would just perform standard MPLS forwarding).

3.       In the case of SF paths:

a.       If the dedicated ESP is used, handling of the packe= t by the current SF must include definition of the next SF node and forward= ing to this node. The forwarded packet would again include the dedicated ES= P at the BoS, with the =A1=B0tunnel LSP=A1=B1 label stack on top of that

b.      If the application label is used, the next SF node = and the SF instance within this node could be inferred either from the payl= oad or from the application label, or from their combination. In any case f= orwarding of the packet to the next SF would result in swapping of the application label at the BoS (similar t= o what is done in MS-PWs) and pushing the =A1=B0tunnel LSP=A1=B1 label stac= k on top of that.

 

Not sure if this helps, or just adds more noiseJ.

 

Regards,

       Sasha <= /o:p>

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

 

 

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

> From: Xuxiaohu [mailto:xuxiaohu@huawei.com]

> Sent: Tuesday, January 27, 2015 10:59 AM

> To: Alexander Vainshtein

> Cc: mpls@ie= tf.org; sfc@ietf.org; Loa Andersson

> Subject: RE: [sfc] [mpls] How to indicate th= e presence of NSH in an MPLS

> packet?

>

> Hi Sasha,

>

> If only one application label is required to= be inserted into the label stack,

> where should it be inserted? at the BoS? If = so, it seems that the application

> label must be an ESP label.

>

> Best regards,

> Xiaohu

>

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

> > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]

> > Sent: Tuesday, January 27, 2015 4:46 PM=

> > To: Xuxiaohu

> > Cc: mpls@ietf.org; sfc@ietf.org; Loa Andersson

> > Subject: RE: [sfc] [mpls] How to indica= te the presence of NSH in an MPLS

> packet?

> >

> > Xiaoh hi!

> > I do not think you need multiple applic= ation labels.

> > Rather, you could swap these labels as = the packet progresses along the

> > SFP, same as is done with MS-PWs.<= /o:p>

> >

> > Regards,

> >      &nbs= p; Sasha

> > Email: Alexander.Vainshtein@= ecitele.com

> > Mobile: 054-9266302

> >

> >

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

> > > From: Xuxiaohu [= mailto:xuxiaohu@huawei.com]

> > > Sent: Tuesday, January 27, 2015 9:= 46 AM

> > > To: Loa Andersson; Alexander Vains= htein

> > > Cc: mpls@ietf.org; sfc@ietf.org

> > > Subject: RE: [sfc] [mpls] How to i= ndicate the presence of NSH in an

> > > MPLS packet?

> > >

> > >

> > >

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

> > > > From: Loa Andersson [mailto:loa@pi.nu]

> > > > Sent: Tuesday, January 27, 20= 15 2:28 PM

> > > > To: Alexander Vainshtein; Xux= iaohu

> > > > Cc: mpls@ietf.org= ; sfc@ietf.org

> > > > Subject: Re: [sfc] [mpls] How= to indicate the presence of NSH in

> > > > an MPLS

> > > packet?

> > > >

> > > > Sasha,

> > > >

> > > >

> > > >

> > > > On 2015-01-26 14:21, Alexande= r Vainshtein wrote:

> > > > > Xiaohu, Huub,=

> > > > > I do not follow the SFC = work closely, so I would like to

> > > > > understand whether the

> > > > NSH should be captured by&nbs= p; transit LSRs on the LSP - or just by

> > > > the LER acting as the LSP tai= l-end?

> > > > >

> > > > > If the latter is correct= , the simplest way to indicate presence

> > > > > of the NSH in the

> > > > MPLS payload would be by allo= cating an "application label"

> > > > indicating its presence by th= e tail-end LER and by inserting it at

> > > > the bottom of the label stack= by the head-end LER - similar to

> > > > what is done for L2/L3VPN.&nb= sp; Within this approach, if label-based

> > > > demultiplexing of packets wit= h NSH in the MPLS payload is not

> > > > required, you could request a= llocation of a new special purpose

> > > > label from the extended speci= al purposes label space as per RFC

> > > > 7274, and to insert such a la= bel

> > > (preceded by the Extension Label )= at the BoS.

> > > > >

> > > > I think "the latter"= ; is correct, the only issue I see is adding

> > > > one more label stack entry to= the label stack.

> > >

> > > Yes, the latter is correct. The is= sue of adding one more label stack

> > > entry to the label stack may becom= e unacceptable in the case where

> > > the Service Function Path (SFP) is= represented by an label stack

> > > while the NSH is now only used as = a metadata container. For example,

> > > for an SFP consist of n SFs, n &qu= ot;application labels" would have to be

> inserted into the label stack.

> > >

> > > Best regards,

> > > Xiaohu

> > >

> > > > /Loa

> > > > > If the former is correct= , the process above still has to be used

> > > > > but it has to be

> > > > augmented by adding the Route= r Alert Label   at the top of the label

> stack.

> > > > >

> > > > >  From my POV these = suggestions are in line with the provisions

> > > > > of Section 2.2

> > > > of RFC 3032 "Determining= the Network Layer Protocol" that states:

> > > > >

> > > > > <quote>=

> > > > >     = When the last label is popped from a packet's label stack (resulting

> > > > >     = in the stack being emptied), further processing of the packet is=

> > > > >     = based on the packet's network layer header.  The LSR which<= /p>

> > > > > pops

> > the

> > > > >     = last label off the stack must therefore be able to identify the<= /p>

> > > > >     = packet's network layer protocol.  However, the label stack does not

> > > > >     = contain any field which explicitly identifies the network layer<= /p>

> > > > >     = protocol.  This means that the identity of the network layer protocol<= o:p>

> > > > >     = must be inferable from the value of the label which is popped from

> > > > >     = the bottom of the stack, possibly along with the contents of the=

> > > > >     = network layer header itself.

> > > > > <end quote>

> > > > >

> > > > > My 2c,

> > > > > Sasha

> > > > > ________________________= ________________

> > > > > From: mpls <mpls-bounces@ietf.org> on behalf of Xuxiaohu

> > > > > <xu= xiaohu@huawei.com>

> > > > > Sent: Monday, January 26= , 2015 5:05 AM

> > > > > To: h= uubatwork@gmail.com; sfc@ietf.org; mpls@ietf.org

> > > > > Subject: Re: [mpls] How = to indicate the presence of NSH in an

> > > > > MPLS

> > > packet?

> > > > >

> > > > > Hi Huub,

> > > > >

> > > > > The alter label itself c= ouldn=A1=AFt make the receiving LSR to

> > > > > determine the MPLS<= /o:p>

> > > > payload type by examining the= MPLS payload.

> > > > >

> > > > > Best regards,=

> > > > > Xiaohu

> > > > >

> > > > >> -----Original Messag= e-----

> > > > >> From: Huub van Helvo= ort [mailto:huubatwork@gmail.com]<= /p>

> > > > >> Sent: Friday, Januar= y 23, 2015 6:28 PM

> > > > >> To: Xuxiaohu; sfc@ietf.org; mpls@ietf.org

> > > > >> Subject: Re: [mpls] = How to indicate the presence of NSH in an

> > > > >> MPLS

> > > packet?

> > > > >>

> > > > >> Xuxiaohu =C4=FA=BA=C3=A3=A1

> > > > >>

> > > > >> Please correct me if= I am wrong:

> > > > >>

> > > > >> It has always been m= y understanding that the MPLS header/label

> > > > >> was independent of t= he protocol/payload.

> > > > >> So no indication of = the actual payload content was necessary.

> > > > >>

> > > > >> IMHO you could use t= he alert label 1 to indicate to the LSR

> > > > >> that it has to furth= er examine the content of a packet.

> > > > >>

> > > > >> Regards, Huub.<= /o:p>

> > > > >>

> > > > >> =3D=3D=3D=3D=3D=3D= =3D=3D

> > > > >>

> > > > >>> It said in (https://tools.ietf.org/html/draft-qui= nn-sfc-nsh-04):

> > > > >>>

> > > > >>>   = ;   The service header is independent of the encapsulation

> > > > >>> used and

> > is

> > > > >>>   = ;   encapsulated in existing transports.  The presence of NS= H is

> > > > >>>   = ;   indicated via protocol type or other indicator in the outer

> > > > >>>   = ;   encapsulation.

> > > > >>>

> > > > >>> In the case wher= e the outer encapsulation is an MPLS LSP, how

> > > > >>> to indicate the<= o:p>

> > > > >> presence of NSH sinc= e the MPLS encapsulation has no explicit

> > > > >> protocol identifier = field to indicate the protocol type of the

> > > > >> MPLS

> > > payload?

> > > > >> Should we make each = SFF to allocate a unique label for

> > > > >> indicating the prese= nce of NSH? Or should we use the control

> > > > >> word to indicate it?= Or should we reconsider the possibility of

> > > > >> adding an explicit p= rotocol identifier field to the MPLS

> > > > >> encapsulation so as = to solve such kind of issues

> > > > once and for all?<= /p>

> > > > >>>

> > > > >>> Best regards,

> > > > >>> Xiaohu

> > > > >>>

> > > > >>

> > > > >>

> > > > >> --

> > > > >>

> > > >

> > >

> ********************************************= **************

> > > ***

> > > > >> ****

> > > > >>   &nb= sp;            = =C7=EB=BC=C7=D7=A1=A3=AC=C4=E3=CA=C7=B6=C0=D2=BB=CE=DE=B6=FE=B5=C4=A3=AC=BE= =CD=CF=F1=C6=E4=CB=FB=C3=BF=D2=BB=B8=F6=C8=CB=D2=BB=D1=F9=

> > > > > ________________________= _______________________

> > > > > mpls mailing list

> > > > > mpls@ietf.or= g

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

> > > > > ________________________= _______________________

> > > > > sfc mailing list

> > > > > sfc@ietf.org<= /span>

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

> > > > >

> > > >

> > > > --

> > > >

> > > >

> > > > Loa Andersson  &nbs= p;            &= nbsp;        email: loa@mail01.huawei.com=

> > > > Senior MPLS Expert  = ;            &n= bsp;           loa@pi.nu<= o:p>

> > > > Huawei Technologies (consulta= nt)     phone: +46 739 81 21 64

--_000_E6C17D2345AC7A45B7D054D407AA205C39376271eusaamb105erics_-- From nobody Tue Jan 27 18:34:23 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6851ACC87; Tue, 27 Jan 2015 18:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgD_BAGL0Xqp; Tue, 27 Jan 2015 18:34:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0D31ACC82; Tue, 27 Jan 2015 18:34:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOM57127; Wed, 28 Jan 2015 02:34:14 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Jan 2015 02:34:13 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 28 Jan 2015 10:34:10 +0800 From: Xuxiaohu To: "Joel M. Halpern" , Alexander Vainshtein , "huubatwork@gmail.com" Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfD//7JaAP/94nYAgARK9AD//sdrIA== Date: Wed, 28 Jan 2015 02:34:09 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083025EF@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> <54C7B084.3090709@joelhalpern.com> In-Reply-To: <54C7B084.3090709@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 02:34:19 -0000 SGkgSm9lbCwNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15 IHJlc3BvbnNlIGlubGluZS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPiBTZW50OiBU dWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1IDExOjM3IFBNDQo+IFRvOiBYdXhpYW9odTsgQWxleGFu ZGVyIFZhaW5zaHRlaW47IGh1dWJhdHdvcmtAZ21haWwuY29tDQo+IENjOiBtcGxzQGlldGYub3Jn OyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhl IHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTIHBhY2tldD8NCj4gDQo+IEkgYW0gYSBiaXQgY29u Y2VybmVkIGJ5IHRoZSB0b25lIG9mIHRoaXMgd2hpY2ggYXNzdW1lcyB0aGF0IHRoZXJlIGlzIG9u bHkgb25lDQo+IHdheSB0byB1c2UgTVBMUyBhcyBhIHRyYW5zcG9ydCBmb3IgTlNILiAgVGhlcmUg YXJlIHNldmVyYWwgZGlmZmVyZW50DQo+IE1QTFMtYmFzZWQgdHJhbnNwb3J0IGFyY2hpdGVjdHVy ZXMgdGhhdCB3aWxsIHdvcmsuICBBcyBmYXIgYXMgSSBjYW4gdGVsbCwgbW9zdCBvZg0KPiB0aGVt IHdpbGwgZXZlbiBpbnRlcm9wZXJhdGUgd2l0aCBlYWNoIG90aGVyLiAgQnV0IHRoZXkgZG8gaW1w bHkgZGlmZmVyZW50IHRoaW5ncw0KPiBhYm91dCBob3cgTlNIIGlzIGluZGljYXRlZC4NCg0KQWx0 aG91Z2ggd2UgY291bGQgdXNlIGRpZmZlcmVudCBhcHByb2FjaGVzIGZvciBpbmRpY2F0aW5nIHRo ZSBwcmVzZW5jZSBvZiB0aGUgTlNILCB3b3VsZG4ndCBpdCBiZSBiZXR0ZXIgaWYgd2UgY291bGQg ZmluZCBhIHVuaWZpZWQgYW5kIHN1c3RhaW5hYmxlIHdheSB0byBhZGRyZXNzIHRoaXMgTVBMUyBw YXlsb2FkIHR5cGUgaW5kaWNhdGlvbiBpc3N1ZT8NCg0KPiBBcyBmYXIgYXMgSSBjYW4gdGVsbCwg YWxsIG9mIHRoZSB0cmFuc3BvcnQgbWVjaGFuaXNtcyBvcGVyYXRlIG9uIHRoZSBhc3N1bXB0aW9u DQo+IHRoYXQgZm9yd2FyZGluZyBkZXZpY2VzIGJldHdlZW4gU0ZGIHdpbGwgbm90IHNlZSBvciBu ZWVkIHRvIGJlIGF3YXJlIG9mIHRoZQ0KPiBOU0ggaGVhZGVyLiAgVGh1cywgdGhvc2Ugd2lsbCBh bHdheXMgaW50ZXJvcGVyYXRlLg0KPiANCj4gSW4gdGhlIE1QTFMgY2FzZSwgd2hldGhlciBvbmUg dGVybWluYXRlcyB0aGUgTVBMUyBMU1AgYXQgdGhlIGZpcnN0IFNGRiwgb3INCj4gYWxsb3dzIHRv IHRvIGNyb3NzIHNldmVyYWwgU0ZGIGFmZmVjdHMgaG93IGlkZW50aWZpY2F0aW9uIGlzIGRvbmUu DQo+IEFsc28sIGlmIHNlZ21lbnQgcm91dGluZyBpcyB1c2VkIHRoZW4gdGhlcmUgYXJlIG90aGVy IG9wdGlvbnMgc3VjaCBhcyB0aGUgdXNlIG9mDQo+IGRlZGljYXRlZCBsb2NhbCBzZXJ2aWNlIGxh YmVscyBmb3IgTlNIIGRlbGl2ZXJ5LiAgKERvaW5nIHRoYXQgd2l0aCBjb252ZW50aW9uYWwNCj4g TVBMUyBpcyBtb3JlIGNvbXBsZXgsIGJ1dCBsaWtlbHkgY2FuIGFsc28gYmUgZG9uZS4pDQoNCkRp ZCB5b3UgbWVhbiB1c2luZyBhIGxhYmVsIHN0YWNrIHRvIHJlcHJlc2VudCBhbiBTRlAgYnkgc2F5 aW5nICJpZiBzZWdtZW50IHJvdXRpbmcgaXMgdXNlZCIsIElmIHNvLCBzaW5jZSBlYWNoIFNGIG5v ZGUgYWxvbmcgdGhlIFNGUCB3b3VsZCBuZWVkIHRvIGtub3cgdGhlIE1QTFMgcGF5bG9hZCB0eXBl IGZvciBwZXJmb3JtaW5nIHRoZSBjb3JyZXNwb25kaW5nIHNlcnZpY2UgZnVuY3Rpb24gb24gdGhl IG9yaWdpbmFsIHBheWxvYWQsIGl0IHdvdWxkIHJlcXVpcmUgU0Ygbm9kZXMgdG8gYWxsb2NhdGUg YSBkZWRpY2F0ZWQgbG9jYWwgbGFiZWwgcGVyIHBheWxvYWQgdHlwZSBmb3IgYSBnaXZlbiBTRi4g UHJvdmlkZWQgd2UgaGF2ZSBhIHVuaWZpZWQgd2F5IGZvciBpbmRpY2F0aW5nIHRoZSBNUExTIHBh eWxvYWQgdHlwZSwgU0Ygbm9kZXMgb25seSBuZWVkIHRvIGFsbG9jYXRlIGEgc2luZ2xlIGxhYmVs IGZvciBhIGdpdmVuIFNGIHJlZ2FyZGxlc3Mgb2YgdGhlIHBheWxvYWQgdHlwZS4NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCj4gWW91cnMsDQo+IEpvZWwNCj4gDQo+IE9uIDEvMjcvMTUgMTo0 NSBBTSwgWHV4aWFvaHUgd3JvdGU6DQo+ID4gSGkgU2FzaGEsDQo+ID4NCj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0 bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCj4gPj4gU2VudDogTW9uZGF5LCBK YW51YXJ5IDI2LCAyMDE1IDI6MjIgUE0NCj4gPj4gVG86IFh1eGlhb2h1OyBodXViYXR3b3JrQGdt YWlsLmNvbQ0KPiA+PiBDYzogc2ZjQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQo+ID4+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4g TVBMUyBwYWNrZXQ/DQo+ID4+DQo+ID4+IFhpYW9odSwgSHV1YiwNCj4gPj4gSSBkbyBub3QgZm9s bG93IHRoZSBTRkMgd29yayBjbG9zZWx5LCBzbyBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZA0K PiA+PiB3aGV0aGVyIHRoZSBOU0ggc2hvdWxkIGJlIGNhcHR1cmVkIGJ5ICB0cmFuc2l0IExTUnMg b24gdGhlIExTUCAtIG9yDQo+ID4+IGp1c3QgYnkgdGhlIExFUiBhY3RpbmcgYXMgdGhlIExTUCB0 YWlsLWVuZD8NCj4gPj4NCj4gPj4gSWYgdGhlIGxhdHRlciBpcyBjb3JyZWN0LCB0aGUgc2ltcGxl c3Qgd2F5IHRvIGluZGljYXRlIHByZXNlbmNlIG9mDQo+ID4+IHRoZSBOU0ggaW4gdGhlIE1QTFMg cGF5bG9hZCB3b3VsZCBiZSBieSBhbGxvY2F0aW5nIGFuICJhcHBsaWNhdGlvbg0KPiA+PiBsYWJl bCIgaW5kaWNhdGluZyBpdHMgcHJlc2VuY2UgYnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5z ZXJ0aW5nDQo+ID4+IGl0IGF0IHRoZSBib3R0b20gb2YgdGhlIGxhYmVsIHN0YWNrIGJ5IHRoZSBo ZWFkLWVuZCBMRVIgLSBzaW1pbGFyIHRvDQo+ID4+IHdoYXQgaXMgZG9uZSBmb3IgTDIvTDNWUE4u ICBXaXRoaW4gdGhpcw0KPiA+DQo+ID4gSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3QsIHRoZSBh Ym92ZSBhcHByb2FjaCBpcyB0aGUgc2FtZSBhcyBvcHRpb24gMQ0KPiA+IGFzIEkgbWVudGlvbmVk IGluIHRoZSBlYXJsaWVyIGVtYWlsIChpLmUuLCBtYWtpbmcgZWFjaCBTRkYgdG8gYWxsb2NhdGUg YSB1bmlxdWUNCj4gbGFiZWwgZm9yIGluZGljYXRpbmcgdGhlIHByZXNlbmNlIG9mIE5TSCkuDQo+ ID4NCj4gPj4gYXBwcm9hY2gsIGlmIGxhYmVsLWJhc2VkIGRlbXVsdGlwbGV4aW5nIG9mICBwYWNr ZXRzIHdpdGggTlNIIGluIHRoZQ0KPiA+PiBNUExTIHBheWxvYWQgaXMgbm90IHJlcXVpcmVkLCB5 b3UgY291bGQgcmVxdWVzdCBhbGxvY2F0aW9uIG9mIGEgbmV3DQo+ID4+IHNwZWNpYWwgcHVycG9z ZSBsYWJlbCBmcm9tIHRoZSBleHRlbmRlZCBzcGVjaWFsIHB1cnBvc2VzIGxhYmVsIHNwYWNlDQo+ ID4+IGFzIHBlciBSRkMgNzI3NCwgYW5kIHRvIGluc2VydCBzdWNoIGEgbGFiZWwgKHByZWNlZGVk IGJ5IHRoZSBFeHRlbnNpb24gTGFiZWwgKQ0KPiBhdCB0aGUgQm9TLg0KPiA+DQo+ID4gV2hhdCdz IHRoZSBwdXJwb3NlIG9mIGluc2VydGluZyBhIHBhcnRpY3VsYXIgRVNQIGxhYmVsIGF0IHRoZSBC b1M/DQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPj4gSWYgdGhl IGZvcm1lciBpcyBjb3JyZWN0LCB0aGUgcHJvY2VzcyBhYm92ZSBzdGlsbCBoYXMgdG8gYmUgdXNl ZCBidXQgaXQgaGFzIHRvIGJlDQo+ID4+IGF1Z21lbnRlZCBieSBhZGRpbmcgdGhlIFJvdXRlciBB bGVydCBMYWJlbCAgIGF0IHRoZSB0b3Agb2YgdGhlIGxhYmVsIHN0YWNrLg0KPiA+Pg0KPiA+PiAg RnJvbSBteSBQT1YgdGhlc2Ugc3VnZ2VzdGlvbnMgYXJlIGluIGxpbmUgd2l0aCB0aGUgcHJvdmlz aW9ucyBvZg0KPiA+PiBTZWN0aW9uIDIuMiBvZiBSRkMgMzAzMiAiRGV0ZXJtaW5pbmcgdGhlIE5l dHdvcmsgTGF5ZXIgUHJvdG9jb2wiIHRoYXQNCj4gc3RhdGVzOg0KPiA+Pg0KPiA+PiA8cXVvdGU+ DQo+ID4+ICAgICBXaGVuIHRoZSBsYXN0IGxhYmVsIGlzIHBvcHBlZCBmcm9tIGEgcGFja2V0J3Mg bGFiZWwgc3RhY2sgKHJlc3VsdGluZw0KPiA+PiAgICAgaW4gdGhlIHN0YWNrIGJlaW5nIGVtcHRp ZWQpLCBmdXJ0aGVyIHByb2Nlc3Npbmcgb2YgdGhlIHBhY2tldCBpcw0KPiA+PiAgICAgYmFzZWQg b24gdGhlIHBhY2tldCdzIG5ldHdvcmsgbGF5ZXIgaGVhZGVyLiAgVGhlIExTUiB3aGljaCBwb3Bz IHRoZQ0KPiA+PiAgICAgbGFzdCBsYWJlbCBvZmYgdGhlIHN0YWNrIG11c3QgdGhlcmVmb3JlIGJl IGFibGUgdG8gaWRlbnRpZnkgdGhlDQo+ID4+ICAgICBwYWNrZXQncyBuZXR3b3JrIGxheWVyIHBy b3RvY29sLiAgSG93ZXZlciwgdGhlIGxhYmVsIHN0YWNrIGRvZXMgbm90DQo+ID4+ICAgICBjb250 YWluIGFueSBmaWVsZCB3aGljaCBleHBsaWNpdGx5IGlkZW50aWZpZXMgdGhlIG5ldHdvcmsgbGF5 ZXINCj4gPj4gICAgIHByb3RvY29sLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBpZGVudGl0eSBvZiB0 aGUgbmV0d29yayBsYXllciBwcm90b2NvbA0KPiA+PiAgICAgbXVzdCBiZSBpbmZlcmFibGUgZnJv bSB0aGUgdmFsdWUgb2YgdGhlIGxhYmVsIHdoaWNoIGlzIHBvcHBlZCBmcm9tDQo+ID4+ICAgICB0 aGUgYm90dG9tIG9mIHRoZSBzdGFjaywgcG9zc2libHkgYWxvbmcgd2l0aCB0aGUgY29udGVudHMg b2YgdGhlDQo+ID4+ICAgICBuZXR3b3JrIGxheWVyIGhlYWRlciBpdHNlbGYuDQo+ID4+IDxlbmQg cXVvdGU+DQo+ID4+DQo+ID4+IE15IDJjLA0KPiA+PiBTYXNoYQ0KPiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IEZyb206IG1wbHMgPG1wbHMtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFh1eGlhb2h1DQo+ID4+IDx4dXhpYW9odUBodWF3ZWku Y29tPg0KPiA+PiBTZW50OiBNb25kYXksIEphbnVhcnkgMjYsIDIwMTUgNTowNSBBTQ0KPiA+PiBU bzogaHV1YmF0d29ya0BnbWFpbC5jb207IHNmY0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0KPiA+ PiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2YgTlNI IGluIGFuIE1QTFMgcGFja2V0Pw0KPiA+Pg0KPiA+PiBIaSBIdXViLA0KPiA+Pg0KPiA+PiBUaGUg YWx0ZXIgbGFiZWwgaXRzZWxmIGNvdWxkbqGvdCBtYWtlIHRoZSByZWNlaXZpbmcgTFNSIHRvIGRl dGVybWluZQ0KPiA+PiB0aGUgTVBMUyBwYXlsb2FkIHR5cGUgYnkgZXhhbWluaW5nIHRoZSBNUExT IHBheWxvYWQuDQo+ID4+DQo+ID4+IEJlc3QgcmVnYXJkcywNCj4gPj4gWGlhb2h1DQo+ID4+DQo+ ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogSHV1YiB2YW4gSGVs dm9vcnQgW21haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbV0NCj4gPj4+IFNlbnQ6IEZyaWRheSwg SmFudWFyeSAyMywgMjAxNSA2OjI4IFBNDQo+ID4+PiBUbzogWHV4aWFvaHU7IHNmY0BpZXRmLm9y ZzsgbXBsc0BpZXRmLm9yZw0KPiA+Pj4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNh dGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTIHBhY2tldD8NCj4gPj4+DQo+ID4+PiBY dXhpYW9odSDE+rrDo6ENCj4gPj4+DQo+ID4+PiBQbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdy b25nOg0KPiA+Pj4NCj4gPj4+IEl0IGhhcyBhbHdheXMgYmVlbiBteSB1bmRlcnN0YW5kaW5nIHRo YXQgdGhlIE1QTFMgaGVhZGVyL2xhYmVsIHdhcw0KPiA+Pj4gaW5kZXBlbmRlbnQgb2YgdGhlIHBy b3RvY29sL3BheWxvYWQuDQo+ID4+PiBTbyBubyBpbmRpY2F0aW9uIG9mIHRoZSBhY3R1YWwgcGF5 bG9hZCBjb250ZW50IHdhcyBuZWNlc3NhcnkuDQo+ID4+Pg0KPiA+Pj4gSU1ITyB5b3UgY291bGQg dXNlIHRoZSBhbGVydCBsYWJlbCAxIHRvIGluZGljYXRlIHRvIHRoZSBMU1IgdGhhdCBpdA0KPiA+ Pj4gaGFzIHRvIGZ1cnRoZXIgZXhhbWluZSB0aGUgY29udGVudCBvZiBhIHBhY2tldC4NCj4gPj4+ DQo+ID4+PiBSZWdhcmRzLCBIdXViLg0KPiA+Pj4NCj4gPj4+ID09PT09PT09DQo+ID4+Pg0KPiA+ Pj4+IEl0IHNhaWQgaW4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1z ZmMtbnNoLTA0KToNCj4gPj4+Pg0KPiA+Pj4+ICAgICAgVGhlIHNlcnZpY2UgaGVhZGVyIGlzIGlu ZGVwZW5kZW50IG9mIHRoZSBlbmNhcHN1bGF0aW9uIHVzZWQgYW5kIGlzDQo+ID4+Pj4gICAgICBl bmNhcHN1bGF0ZWQgaW4gZXhpc3RpbmcgdHJhbnNwb3J0cy4gIFRoZSBwcmVzZW5jZSBvZiBOU0gg aXMNCj4gPj4+PiAgICAgIGluZGljYXRlZCB2aWEgcHJvdG9jb2wgdHlwZSBvciBvdGhlciBpbmRp Y2F0b3IgaW4gdGhlIG91dGVyDQo+ID4+Pj4gICAgICBlbmNhcHN1bGF0aW9uLg0KPiA+Pj4+DQo+ ID4+Pj4gSW4gdGhlIGNhc2Ugd2hlcmUgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24gaXMgYW4gTVBM UyBMU1AsIGhvdyB0bw0KPiA+Pj4+IGluZGljYXRlIHRoZQ0KPiA+Pj4gcHJlc2VuY2Ugb2YgTlNI IHNpbmNlIHRoZSBNUExTIGVuY2Fwc3VsYXRpb24gaGFzIG5vIGV4cGxpY2l0DQo+ID4+PiBwcm90 b2NvbCBpZGVudGlmaWVyIGZpZWxkIHRvIGluZGljYXRlIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRo ZSBNUExTIHBheWxvYWQ/DQo+ID4+PiBTaG91bGQgd2UgbWFrZSBlYWNoIFNGRiB0byBhbGxvY2F0 ZSBhIHVuaXF1ZSBsYWJlbCBmb3IgaW5kaWNhdGluZw0KPiA+Pj4gdGhlIHByZXNlbmNlIG9mIE5T SD8gT3Igc2hvdWxkIHdlIHVzZSB0aGUgY29udHJvbCB3b3JkIHRvIGluZGljYXRlDQo+ID4+PiBp dD8gT3Igc2hvdWxkIHdlIHJlY29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IG9mIGFkZGluZyBhbiBl eHBsaWNpdA0KPiA+Pj4gcHJvdG9jb2wgaWRlbnRpZmllciBmaWVsZCB0byB0aGUgTVBMUyBlbmNh cHN1bGF0aW9uIHNvIGFzIHRvIHNvbHZlDQo+ID4+PiBzdWNoIGtpbmQgb2YgaXNzdWVzDQo+ID4+ IG9uY2UgYW5kIGZvciBhbGw/DQo+ID4+Pj4NCj4gPj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4g WGlhb2h1DQo+ID4+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gLS0NCj4gPj4+DQo+ID4+DQo+ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCj4gPj4+ICoqKioNCj4gPj4+ICAgICAgICAgICAgICAgICDH67zH16GjrMTjyse2wNK7zt62 /rXEo6y+zc/xxuTL+8O/0ru49sjL0rvR+Q0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+PiBtcGxz QGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiBtcGxzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4NCg== From nobody Tue Jan 27 18:39:30 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDFE1ACC87; Tue, 27 Jan 2015 18:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2BwD8UtMocg; Tue, 27 Jan 2015 18:39:24 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2EA1A1AE0; Tue, 27 Jan 2015 18:39:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 77D21240D97; Tue, 27 Jan 2015 18:39:24 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-12.clppva.east.verizon.net [70.106.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9C3452405A5; Tue, 27 Jan 2015 18:39:22 -0800 (PST) Message-ID: <54C84BD8.6060504@joelhalpern.com> Date: Tue, 27 Jan 2015 21:39:20 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Xuxiaohu , Alexander Vainshtein , "huubatwork@gmail.com" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> <54C7B084.3090709@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083025EF@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083025EF@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 02:39:26 -0000 If one uses service labels (as in segment routing), one would not have a service label per payload type but rather one per services. Since the SFC services will be different from any other use of labels, those labels will be distinct. Since they are local, it does not even matter how many there are. The point is that the different deployments of MPLS for service chaining lead to different identification needs. If the needs were identical then I would agree that a common identification scheme would be appropriate. Yours, Joel On 1/27/15 9:34 PM, Xuxiaohu wrote: > Hi Joel, > > Thanks a lot for your comments. Please see my response inline. > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, January 27, 2015 11:37 PM >> To: Xuxiaohu; Alexander Vainshtein; huubatwork@gmail.com >> Cc: mpls@ietf.org; sfc@ietf.org >> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >> >> I am a bit concerned by the tone of this which assumes that there is only one >> way to use MPLS as a transport for NSH. There are several different >> MPLS-based transport architectures that will work. As far as I can tell, most of >> them will even interoperate with each other. But they do imply different things >> about how NSH is indicated. > > Although we could use different approaches for indicating the presence of the NSH, wouldn't it be better if we could find a unified and sustainable way to address this MPLS payload type indication issue? > >> As far as I can tell, all of the transport mechanisms operate on the assumption >> that forwarding devices between SFF will not see or need to be aware of the >> NSH header. Thus, those will always interoperate. >> >> In the MPLS case, whether one terminates the MPLS LSP at the first SFF, or >> allows to to cross several SFF affects how identification is done. >> Also, if segment routing is used then there are other options such as the use of >> dedicated local service labels for NSH delivery. (Doing that with conventional >> MPLS is more complex, but likely can also be done.) > > Did you mean using a label stack to represent an SFP by saying "if segment routing is used", If so, since each SF node along the SFP would need to know the MPLS payload type for performing the corresponding service function on the original payload, it would require SF nodes to allocate a dedicated local label per payload type for a given SF. Provided we have a unified way for indicating the MPLS payload type, SF nodes only need to allocate a single label for a given SF regardless of the payload type. > > Best regards, > Xiaohu > >> Yours, >> Joel >> >> On 1/27/15 1:45 AM, Xuxiaohu wrote: >>> Hi Sasha, >>> >>>> -----Original Message----- >>>> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >>>> Sent: Monday, January 26, 2015 2:22 PM >>>> To: Xuxiaohu; huubatwork@gmail.com >>>> Cc: sfc@ietf.org; mpls@ietf.org >>>> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >>>> >>>> Xiaohu, Huub, >>>> I do not follow the SFC work closely, so I would like to understand >>>> whether the NSH should be captured by transit LSRs on the LSP - or >>>> just by the LER acting as the LSP tail-end? >>>> >>>> If the latter is correct, the simplest way to indicate presence of >>>> the NSH in the MPLS payload would be by allocating an "application >>>> label" indicating its presence by the tail-end LER and by inserting >>>> it at the bottom of the label stack by the head-end LER - similar to >>>> what is done for L2/L3VPN. Within this >>> >>> If I understand it correct, the above approach is the same as option 1 >>> as I mentioned in the earlier email (i.e., making each SFF to allocate a unique >> label for indicating the presence of NSH). >>> >>>> approach, if label-based demultiplexing of packets with NSH in the >>>> MPLS payload is not required, you could request allocation of a new >>>> special purpose label from the extended special purposes label space >>>> as per RFC 7274, and to insert such a label (preceded by the Extension Label ) >> at the BoS. >>> >>> What's the purpose of inserting a particular ESP label at the BoS? >>> >>> Best regards, >>> Xiaohu >>> >>>> If the former is correct, the process above still has to be used but it has to be >>>> augmented by adding the Router Alert Label at the top of the label stack. >>>> >>>> From my POV these suggestions are in line with the provisions of >>>> Section 2.2 of RFC 3032 "Determining the Network Layer Protocol" that >> states: >>>> >>>> >>>> When the last label is popped from a packet's label stack (resulting >>>> in the stack being emptied), further processing of the packet is >>>> based on the packet's network layer header. The LSR which pops the >>>> last label off the stack must therefore be able to identify the >>>> packet's network layer protocol. However, the label stack does not >>>> contain any field which explicitly identifies the network layer >>>> protocol. This means that the identity of the network layer protocol >>>> must be inferable from the value of the label which is popped from >>>> the bottom of the stack, possibly along with the contents of the >>>> network layer header itself. >>>> >>>> >>>> My 2c, >>>> Sasha >>>> ________________________________________ >>>> From: mpls on behalf of Xuxiaohu >>>> >>>> Sent: Monday, January 26, 2015 5:05 AM >>>> To: huubatwork@gmail.com; sfc@ietf.org; mpls@ietf.org >>>> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >>>> >>>> Hi Huub, >>>> >>>> The alter label itself couldn¡¯t make the receiving LSR to determine >>>> the MPLS payload type by examining the MPLS payload. >>>> >>>> Best regards, >>>> Xiaohu >>>> >>>>> -----Original Message----- >>>>> From: Huub van Helvoort [mailto:huubatwork@gmail.com] >>>>> Sent: Friday, January 23, 2015 6:28 PM >>>>> To: Xuxiaohu; sfc@ietf.org; mpls@ietf.org >>>>> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >>>>> >>>>> Xuxiaohu ÄúºÃ£¡ >>>>> >>>>> Please correct me if I am wrong: >>>>> >>>>> It has always been my understanding that the MPLS header/label was >>>>> independent of the protocol/payload. >>>>> So no indication of the actual payload content was necessary. >>>>> >>>>> IMHO you could use the alert label 1 to indicate to the LSR that it >>>>> has to further examine the content of a packet. >>>>> >>>>> Regards, Huub. >>>>> >>>>> ======== >>>>> >>>>>> It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04): >>>>>> >>>>>> The service header is independent of the encapsulation used and is >>>>>> encapsulated in existing transports. The presence of NSH is >>>>>> indicated via protocol type or other indicator in the outer >>>>>> encapsulation. >>>>>> >>>>>> In the case where the outer encapsulation is an MPLS LSP, how to >>>>>> indicate the >>>>> presence of NSH since the MPLS encapsulation has no explicit >>>>> protocol identifier field to indicate the protocol type of the MPLS payload? >>>>> Should we make each SFF to allocate a unique label for indicating >>>>> the presence of NSH? Or should we use the control word to indicate >>>>> it? Or should we reconsider the possibility of adding an explicit >>>>> protocol identifier field to the MPLS encapsulation so as to solve >>>>> such kind of issues >>>> once and for all? >>>>>> >>>>>> Best regards, >>>>>> Xiaohu >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>> >> ************************************************************* >>>>> **** >>>>> Çë¼Çס£¬ÄãÊǶÀÒ»ÎÞ¶þµÄ£¬¾ÍÏñÆäËûÿһ¸öÈËÒ»Ñù >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> From nobody Tue Jan 27 19:29:50 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C30B1A1B7C; Tue, 27 Jan 2015 19:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWavByZARk3v; Tue, 27 Jan 2015 19:29:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7067E1A1B78; Tue, 27 Jan 2015 19:29:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOM60703; Wed, 28 Jan 2015 03:29:33 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Jan 2015 03:29:31 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 28 Jan 2015 11:29:27 +0800 From: Xuxiaohu To: "Joel M. Halpern" , Alexander Vainshtein , "huubatwork@gmail.com" Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfD//7JaAP/94nYAgARK9AD//sdrIIAB8b8A//9uXbA= Date: Wed, 28 Jan 2015 03:29:27 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830261F@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> <54C7B084.3090709@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083025EF@NKGEML512-MBS.china.huawei.com> <54C84BD8.6060504@joelhalpern.com> In-Reply-To: <54C84BD8.6060504@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 03:29:40 -0000 SGkgSm9lbCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2VsIE0u IEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPiBTZW50OiBXZWRuZXNkYXks IEphbnVhcnkgMjgsIDIwMTUgMTA6MzkgQU0NCj4gVG86IFh1eGlhb2h1OyBBbGV4YW5kZXIgVmFp bnNodGVpbjsgaHV1YmF0d29ya0BnbWFpbC5jb20NCj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IHNmY0Bp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0ZSB0aGUgcHJlc2Vu Y2Ugb2YgTlNIIGluIGFuIE1QTFMgcGFja2V0Pw0KPiANCj4gSWYgb25lIHVzZXMgc2VydmljZSBs YWJlbHMgKGFzIGluIHNlZ21lbnQgcm91dGluZyksIG9uZSB3b3VsZCBub3QgaGF2ZSBhIHNlcnZp Y2UNCj4gbGFiZWwgcGVyIHBheWxvYWQgdHlwZSBidXQgcmF0aGVyIG9uZSBwZXIgc2VydmljZXMu ICBTaW5jZSB0aGUgU0ZDIHNlcnZpY2VzIHdpbGwNCj4gYmUgZGlmZmVyZW50IGZyb20gYW55IG90 aGVyIHVzZSBvZiBsYWJlbHMsIHRob3NlIGxhYmVscyB3aWxsIGJlIGRpc3RpbmN0LiAgU2luY2UN Cj4gdGhleSBhcmUgbG9jYWwsIGl0IGRvZXMgbm90IGV2ZW4gbWF0dGVyIGhvdyBtYW55IHRoZXJl IGFyZS4NCg0KU2luY2UgdGhlIE1QTFMgcGF5bG9hZCBjb3VsZCBiZSBJUHY0IHBhY2tldCwgSVB2 NiBwYWNrZXQsIEV0aGVybmV0IGZyYW1lIG9yIGV2ZW4gTlNIIChhcyBhIG1ldGFkYXRhIGNvbnRh aW5lciBvbmx5KSBpbiB0aGUgTVBMUy1TUFJJTkctYmFzZWQgU0ZDIGFwcHJvYWNoLCBob3cgY291 bGQgdGhlIFNGIG9yIHRoZSBTRkMtcHJveHkgZGV0ZXJtaW5lIHRoZSBNUExTIHBheWxvYWQgdHlw ZSBpZiBvbmUgbGFiZWwgcGVyIHNlcnZpY2UgaXMgYWxsb2NhdGVkLg0KDQo+IFRoZSBwb2ludCBp cyB0aGF0IHRoZSBkaWZmZXJlbnQgZGVwbG95bWVudHMgb2YgTVBMUyBmb3Igc2VydmljZSBjaGFp bmluZyBsZWFkIHRvDQo+IGRpZmZlcmVudCBpZGVudGlmaWNhdGlvbiBuZWVkcy4gIElmIHRoZSBu ZWVkcyB3ZXJlIGlkZW50aWNhbCB0aGVuIEkgd291bGQgYWdyZWUNCj4gdGhhdCBhIGNvbW1vbiBp ZGVudGlmaWNhdGlvbiBzY2hlbWUgd291bGQgYmUgYXBwcm9wcmlhdGUuDQoNCklNSE8sIGFsdGhv dWdoIHRoZSBTRlAvU0ZDIGlkZW50aWZpY2F0aW9uIG5lZWRzIGFyZSBkaWZmZXJlbnQsIHRoZSBN UExTIHBheWxvYWQgdHlwZSBpZGVudGlmaWNhdGlvbiBuZWVkcyBhcmUgYWxtb3N0IHRoZSBzYW1l Lg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gT24g MS8yNy8xNSA5OjM0IFBNLCBYdXhpYW9odSB3cm90ZToNCj4gPiBIaSBKb2VsLA0KPiA+DQo+ID4g VGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlIGlu bGluZS4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBK b2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPiA+PiBTZW50OiBU dWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1IDExOjM3IFBNDQo+ID4+IFRvOiBYdXhpYW9odTsgQWxl eGFuZGVyIFZhaW5zaHRlaW47IGh1dWJhdHdvcmtAZ21haWwuY29tDQo+ID4+IENjOiBtcGxzQGll dGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5k aWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTIHBhY2tldD8NCj4gPj4NCj4gPj4g SSBhbSBhIGJpdCBjb25jZXJuZWQgYnkgdGhlIHRvbmUgb2YgdGhpcyB3aGljaCBhc3N1bWVzIHRo YXQgdGhlcmUgaXMNCj4gPj4gb25seSBvbmUgd2F5IHRvIHVzZSBNUExTIGFzIGEgdHJhbnNwb3J0 IGZvciBOU0guICBUaGVyZSBhcmUgc2V2ZXJhbA0KPiA+PiBkaWZmZXJlbnQgTVBMUy1iYXNlZCB0 cmFuc3BvcnQgYXJjaGl0ZWN0dXJlcyB0aGF0IHdpbGwgd29yay4gIEFzIGZhcg0KPiA+PiBhcyBJ IGNhbiB0ZWxsLCBtb3N0IG9mIHRoZW0gd2lsbCBldmVuIGludGVyb3BlcmF0ZSB3aXRoIGVhY2gg b3RoZXIuDQo+ID4+IEJ1dCB0aGV5IGRvIGltcGx5IGRpZmZlcmVudCB0aGluZ3MgYWJvdXQgaG93 IE5TSCBpcyBpbmRpY2F0ZWQuDQo+ID4NCj4gPiBBbHRob3VnaCB3ZSBjb3VsZCB1c2UgZGlmZmVy ZW50IGFwcHJvYWNoZXMgZm9yIGluZGljYXRpbmcgdGhlIHByZXNlbmNlIG9mIHRoZQ0KPiBOU0gs IHdvdWxkbid0IGl0IGJlIGJldHRlciBpZiB3ZSBjb3VsZCBmaW5kIGEgdW5pZmllZCBhbmQgc3Vz dGFpbmFibGUgd2F5IHRvDQo+IGFkZHJlc3MgdGhpcyBNUExTIHBheWxvYWQgdHlwZSBpbmRpY2F0 aW9uIGlzc3VlPw0KPiA+DQo+ID4+IEFzIGZhciBhcyBJIGNhbiB0ZWxsLCBhbGwgb2YgdGhlIHRy YW5zcG9ydCBtZWNoYW5pc21zIG9wZXJhdGUgb24gdGhlDQo+ID4+IGFzc3VtcHRpb24gdGhhdCBm b3J3YXJkaW5nIGRldmljZXMgYmV0d2VlbiBTRkYgd2lsbCBub3Qgc2VlIG9yIG5lZWQNCj4gPj4g dG8gYmUgYXdhcmUgb2YgdGhlIE5TSCBoZWFkZXIuICBUaHVzLCB0aG9zZSB3aWxsIGFsd2F5cyBp bnRlcm9wZXJhdGUuDQo+ID4+DQo+ID4+IEluIHRoZSBNUExTIGNhc2UsIHdoZXRoZXIgb25lIHRl cm1pbmF0ZXMgdGhlIE1QTFMgTFNQIGF0IHRoZSBmaXJzdA0KPiA+PiBTRkYsIG9yIGFsbG93cyB0 byB0byBjcm9zcyBzZXZlcmFsIFNGRiBhZmZlY3RzIGhvdyBpZGVudGlmaWNhdGlvbiBpcyBkb25l Lg0KPiA+PiBBbHNvLCBpZiBzZWdtZW50IHJvdXRpbmcgaXMgdXNlZCB0aGVuIHRoZXJlIGFyZSBv dGhlciBvcHRpb25zIHN1Y2ggYXMNCj4gPj4gdGhlIHVzZSBvZiBkZWRpY2F0ZWQgbG9jYWwgc2Vy dmljZSBsYWJlbHMgZm9yIE5TSCBkZWxpdmVyeS4gIChEb2luZw0KPiA+PiB0aGF0IHdpdGggY29u dmVudGlvbmFsIE1QTFMgaXMgbW9yZSBjb21wbGV4LCBidXQgbGlrZWx5IGNhbiBhbHNvIGJlDQo+ ID4+IGRvbmUuKQ0KPiA+DQo+ID4gRGlkIHlvdSBtZWFuIHVzaW5nIGEgbGFiZWwgc3RhY2sgdG8g cmVwcmVzZW50IGFuIFNGUCBieSBzYXlpbmcgImlmIHNlZ21lbnQNCj4gcm91dGluZyBpcyB1c2Vk IiwgSWYgc28sIHNpbmNlIGVhY2ggU0Ygbm9kZSBhbG9uZyB0aGUgU0ZQIHdvdWxkIG5lZWQgdG8g a25vdyB0aGUNCj4gTVBMUyBwYXlsb2FkIHR5cGUgZm9yIHBlcmZvcm1pbmcgdGhlIGNvcnJlc3Bv bmRpbmcgc2VydmljZSBmdW5jdGlvbiBvbiB0aGUNCj4gb3JpZ2luYWwgcGF5bG9hZCwgaXQgd291 bGQgcmVxdWlyZSBTRiBub2RlcyB0byBhbGxvY2F0ZSBhIGRlZGljYXRlZCBsb2NhbCBsYWJlbCBw ZXINCj4gcGF5bG9hZCB0eXBlIGZvciBhIGdpdmVuIFNGLiBQcm92aWRlZCB3ZSBoYXZlIGEgdW5p ZmllZCB3YXkgZm9yIGluZGljYXRpbmcgdGhlDQo+IE1QTFMgcGF5bG9hZCB0eXBlLCBTRiBub2Rl cyBvbmx5IG5lZWQgdG8gYWxsb2NhdGUgYSBzaW5nbGUgbGFiZWwgZm9yIGEgZ2l2ZW4gU0YNCj4g cmVnYXJkbGVzcyBvZiB0aGUgcGF5bG9hZCB0eXBlLg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0K PiA+IFhpYW9odQ0KPiA+DQo+ID4+IFlvdXJzLA0KPiA+PiBKb2VsDQo+ID4+DQo+ID4+IE9uIDEv MjcvMTUgMTo0NSBBTSwgWHV4aWFvaHUgd3JvdGU6DQo+ID4+PiBIaSBTYXNoYSwNCj4gPj4+DQo+ ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBBbGV4YW5kZXIg VmFpbnNodGVpbg0KPiA+Pj4+IFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b21dDQo+ID4+Pj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDI6MjIgUE0NCj4gPj4+ PiBUbzogWHV4aWFvaHU7IGh1dWJhdHdvcmtAZ21haWwuY29tDQo+ID4+Pj4gQ2M6IHNmY0BpZXRm Lm9yZzsgbXBsc0BpZXRmLm9yZw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGlu ZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBMUw0KPiBwYWNrZXQ/DQo+ID4+Pj4N Cj4gPj4+PiBYaWFvaHUsIEh1dWIsDQo+ID4+Pj4gSSBkbyBub3QgZm9sbG93IHRoZSBTRkMgd29y ayBjbG9zZWx5LCBzbyBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZA0KPiA+Pj4+IHdoZXRoZXIg dGhlIE5TSCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRyYW5zaXQgTFNScyBvbiB0aGUgTFNQIC0g b3INCj4gPj4+PiBqdXN0IGJ5IHRoZSBMRVIgYWN0aW5nIGFzIHRoZSBMU1AgdGFpbC1lbmQ/DQo+ ID4+Pj4NCj4gPj4+PiBJZiB0aGUgbGF0dGVyIGlzIGNvcnJlY3QsIHRoZSBzaW1wbGVzdCB3YXkg dG8gaW5kaWNhdGUgcHJlc2VuY2Ugb2YNCj4gPj4+PiB0aGUgTlNIIGluIHRoZSBNUExTIHBheWxv YWQgd291bGQgYmUgYnkgYWxsb2NhdGluZyBhbiAiYXBwbGljYXRpb24NCj4gPj4+PiBsYWJlbCIg aW5kaWNhdGluZyBpdHMgcHJlc2VuY2UgYnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5zZXJ0 aW5nDQo+ID4+Pj4gaXQgYXQgdGhlIGJvdHRvbSBvZiB0aGUgbGFiZWwgc3RhY2sgYnkgdGhlIGhl YWQtZW5kIExFUiAtIHNpbWlsYXINCj4gPj4+PiB0byB3aGF0IGlzIGRvbmUgZm9yIEwyL0wzVlBO LiAgV2l0aGluIHRoaXMNCj4gPj4+DQo+ID4+PiBJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdCwg dGhlIGFib3ZlIGFwcHJvYWNoIGlzIHRoZSBzYW1lIGFzIG9wdGlvbg0KPiA+Pj4gMSBhcyBJIG1l bnRpb25lZCBpbiB0aGUgZWFybGllciBlbWFpbCAoaS5lLiwgbWFraW5nIGVhY2ggU0ZGIHRvDQo+ ID4+PiBhbGxvY2F0ZSBhIHVuaXF1ZQ0KPiA+PiBsYWJlbCBmb3IgaW5kaWNhdGluZyB0aGUgcHJl c2VuY2Ugb2YgTlNIKS4NCj4gPj4+DQo+ID4+Pj4gYXBwcm9hY2gsIGlmIGxhYmVsLWJhc2VkIGRl bXVsdGlwbGV4aW5nIG9mICBwYWNrZXRzIHdpdGggTlNIIGluIHRoZQ0KPiA+Pj4+IE1QTFMgcGF5 bG9hZCBpcyBub3QgcmVxdWlyZWQsIHlvdSBjb3VsZCByZXF1ZXN0IGFsbG9jYXRpb24gb2YgYSBu ZXcNCj4gPj4+PiBzcGVjaWFsIHB1cnBvc2UgbGFiZWwgZnJvbSB0aGUgZXh0ZW5kZWQgc3BlY2lh bCBwdXJwb3NlcyBsYWJlbA0KPiA+Pj4+IHNwYWNlIGFzIHBlciBSRkMgNzI3NCwgYW5kIHRvIGlu c2VydCBzdWNoIGEgbGFiZWwgKHByZWNlZGVkIGJ5IHRoZQ0KPiA+Pj4+IEV4dGVuc2lvbiBMYWJl bCApDQo+ID4+IGF0IHRoZSBCb1MuDQo+ID4+Pg0KPiA+Pj4gV2hhdCdzIHRoZSBwdXJwb3NlIG9m IGluc2VydGluZyBhIHBhcnRpY3VsYXIgRVNQIGxhYmVsIGF0IHRoZSBCb1M/DQo+ID4+Pg0KPiA+ Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4gWGlhb2h1DQo+ID4+Pg0KPiA+Pj4+IElmIHRoZSBmb3Jt ZXIgaXMgY29ycmVjdCwgdGhlIHByb2Nlc3MgYWJvdmUgc3RpbGwgaGFzIHRvIGJlIHVzZWQgYnV0 IGl0IGhhcyB0bw0KPiBiZQ0KPiA+Pj4+IGF1Z21lbnRlZCBieSBhZGRpbmcgdGhlIFJvdXRlciBB bGVydCBMYWJlbCAgIGF0IHRoZSB0b3Agb2YgdGhlIGxhYmVsDQo+IHN0YWNrLg0KPiA+Pj4+DQo+ ID4+Pj4gICBGcm9tIG15IFBPViB0aGVzZSBzdWdnZXN0aW9ucyBhcmUgaW4gbGluZSB3aXRoIHRo ZSBwcm92aXNpb25zIG9mDQo+ID4+Pj4gU2VjdGlvbiAyLjIgb2YgUkZDIDMwMzIgIkRldGVybWlu aW5nIHRoZSBOZXR3b3JrIExheWVyIFByb3RvY29sIg0KPiA+Pj4+IHRoYXQNCj4gPj4gc3RhdGVz Og0KPiA+Pj4+DQo+ID4+Pj4gPHF1b3RlPg0KPiA+Pj4+ICAgICAgV2hlbiB0aGUgbGFzdCBsYWJl bCBpcyBwb3BwZWQgZnJvbSBhIHBhY2tldCdzIGxhYmVsIHN0YWNrIChyZXN1bHRpbmcNCj4gPj4+ PiAgICAgIGluIHRoZSBzdGFjayBiZWluZyBlbXB0aWVkKSwgZnVydGhlciBwcm9jZXNzaW5nIG9m IHRoZSBwYWNrZXQgaXMNCj4gPj4+PiAgICAgIGJhc2VkIG9uIHRoZSBwYWNrZXQncyBuZXR3b3Jr IGxheWVyIGhlYWRlci4gIFRoZSBMU1Igd2hpY2ggcG9wcw0KPiB0aGUNCj4gPj4+PiAgICAgIGxh c3QgbGFiZWwgb2ZmIHRoZSBzdGFjayBtdXN0IHRoZXJlZm9yZSBiZSBhYmxlIHRvIGlkZW50aWZ5 IHRoZQ0KPiA+Pj4+ICAgICAgcGFja2V0J3MgbmV0d29yayBsYXllciBwcm90b2NvbC4gIEhvd2V2 ZXIsIHRoZSBsYWJlbCBzdGFjayBkb2VzIG5vdA0KPiA+Pj4+ICAgICAgY29udGFpbiBhbnkgZmll bGQgd2hpY2ggZXhwbGljaXRseSBpZGVudGlmaWVzIHRoZSBuZXR3b3JrIGxheWVyDQo+ID4+Pj4g ICAgICBwcm90b2NvbC4gIFRoaXMgbWVhbnMgdGhhdCB0aGUgaWRlbnRpdHkgb2YgdGhlIG5ldHdv cmsgbGF5ZXINCj4gcHJvdG9jb2wNCj4gPj4+PiAgICAgIG11c3QgYmUgaW5mZXJhYmxlIGZyb20g dGhlIHZhbHVlIG9mIHRoZSBsYWJlbCB3aGljaCBpcyBwb3BwZWQgZnJvbQ0KPiA+Pj4+ICAgICAg dGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ssIHBvc3NpYmx5IGFsb25nIHdpdGggdGhlIGNvbnRlbnRz IG9mIHRoZQ0KPiA+Pj4+ICAgICAgbmV0d29yayBsYXllciBoZWFkZXIgaXRzZWxmLg0KPiA+Pj4+ IDxlbmQgcXVvdGU+DQo+ID4+Pj4NCj4gPj4+PiBNeSAyYywNCj4gPj4+PiBTYXNoYQ0KPiA+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBGcm9tOiBt cGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBYdXhpYW9odQ0KPiA+Pj4+ IDx4dXhpYW9odUBodWF3ZWkuY29tPg0KPiA+Pj4+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAyNiwg MjAxNSA1OjA1IEFNDQo+ID4+Pj4gVG86IGh1dWJhdHdvcmtAZ21haWwuY29tOyBzZmNAaWV0Zi5v cmc7IG1wbHNAaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRp Y2F0ZSB0aGUgcHJlc2VuY2Ugb2YgTlNIIGluIGFuIE1QTFMNCj4gcGFja2V0Pw0KPiA+Pj4+DQo+ ID4+Pj4gSGkgSHV1YiwNCj4gPj4+Pg0KPiA+Pj4+IFRoZSBhbHRlciBsYWJlbCBpdHNlbGYgY291 bGRuoa90IG1ha2UgdGhlIHJlY2VpdmluZyBMU1IgdG8gZGV0ZXJtaW5lDQo+ID4+Pj4gdGhlIE1Q TFMgcGF5bG9hZCB0eXBlIGJ5IGV4YW1pbmluZyB0aGUgTVBMUyBwYXlsb2FkLg0KPiA+Pj4+DQo+ ID4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4+IFhpYW9odQ0KPiA+Pj4+DQo+ID4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+IEZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFtt YWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb21dDQo+ID4+Pj4+IFNlbnQ6IEZyaWRheSwgSmFudWFy eSAyMywgMjAxNSA2OjI4IFBNDQo+ID4+Pj4+IFRvOiBYdXhpYW9odTsgc2ZjQGlldGYub3JnOyBt cGxzQGlldGYub3JnDQo+ID4+Pj4+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRl IHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBMUw0KPiBwYWNrZXQ/DQo+ID4+Pj4+DQo+ID4+ Pj4+IFh1eGlhb2h1IMT6usOjoQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBQbGVhc2UgY29ycmVjdCBtZSBp ZiBJIGFtIHdyb25nOg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJdCBoYXMgYWx3YXlzIGJlZW4gbXkgdW5k ZXJzdGFuZGluZyB0aGF0IHRoZSBNUExTIGhlYWRlci9sYWJlbCB3YXMNCj4gPj4+Pj4gaW5kZXBl bmRlbnQgb2YgdGhlIHByb3RvY29sL3BheWxvYWQuDQo+ID4+Pj4+IFNvIG5vIGluZGljYXRpb24g b2YgdGhlIGFjdHVhbCBwYXlsb2FkIGNvbnRlbnQgd2FzIG5lY2Vzc2FyeS4NCj4gPj4+Pj4NCj4g Pj4+Pj4gSU1ITyB5b3UgY291bGQgdXNlIHRoZSBhbGVydCBsYWJlbCAxIHRvIGluZGljYXRlIHRv IHRoZSBMU1IgdGhhdA0KPiA+Pj4+PiBpdCBoYXMgdG8gZnVydGhlciBleGFtaW5lIHRoZSBjb250 ZW50IG9mIGEgcGFja2V0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBSZWdhcmRzLCBIdXViLg0KPiA+Pj4+ Pg0KPiA+Pj4+PiA9PT09PT09PQ0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gSXQgc2FpZCBpbiAoaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXNmYy1uc2gtMDQpOg0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+ICAgICAgIFRoZSBzZXJ2aWNlIGhlYWRlciBpcyBpbmRlcGVuZGVudCBvZiB0aGUg ZW5jYXBzdWxhdGlvbiB1c2VkDQo+IGFuZCBpcw0KPiA+Pj4+Pj4gICAgICAgZW5jYXBzdWxhdGVk IGluIGV4aXN0aW5nIHRyYW5zcG9ydHMuICBUaGUgcHJlc2VuY2Ugb2YgTlNIIGlzDQo+ID4+Pj4+ PiAgICAgICBpbmRpY2F0ZWQgdmlhIHByb3RvY29sIHR5cGUgb3Igb3RoZXIgaW5kaWNhdG9yIGlu IHRoZSBvdXRlcg0KPiA+Pj4+Pj4gICAgICAgZW5jYXBzdWxhdGlvbi4NCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBJbiB0aGUgY2FzZSB3aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBpcyBhbiBNUExT IExTUCwgaG93IHRvDQo+ID4+Pj4+PiBpbmRpY2F0ZSB0aGUNCj4gPj4+Pj4gcHJlc2VuY2Ugb2Yg TlNIIHNpbmNlIHRoZSBNUExTIGVuY2Fwc3VsYXRpb24gaGFzIG5vIGV4cGxpY2l0DQo+ID4+Pj4+ IHByb3RvY29sIGlkZW50aWZpZXIgZmllbGQgdG8gaW5kaWNhdGUgdGhlIHByb3RvY29sIHR5cGUg b2YgdGhlIE1QTFMNCj4gcGF5bG9hZD8NCj4gPj4+Pj4gU2hvdWxkIHdlIG1ha2UgZWFjaCBTRkYg dG8gYWxsb2NhdGUgYSB1bmlxdWUgbGFiZWwgZm9yIGluZGljYXRpbmcNCj4gPj4+Pj4gdGhlIHBy ZXNlbmNlIG9mIE5TSD8gT3Igc2hvdWxkIHdlIHVzZSB0aGUgY29udHJvbCB3b3JkIHRvIGluZGlj YXRlDQo+ID4+Pj4+IGl0PyBPciBzaG91bGQgd2UgcmVjb25zaWRlciB0aGUgcG9zc2liaWxpdHkg b2YgYWRkaW5nIGFuIGV4cGxpY2l0DQo+ID4+Pj4+IHByb3RvY29sIGlkZW50aWZpZXIgZmllbGQg dG8gdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBzbyBhcyB0byBzb2x2ZQ0KPiA+Pj4+PiBzdWNoIGtp bmQgb2YgaXNzdWVzDQo+ID4+Pj4gb25jZSBhbmQgZm9yIGFsbD8NCj4gPj4+Pj4+DQo+ID4+Pj4+ PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4+PiBYaWFvaHUNCj4gPj4+Pj4+DQo+ID4+Pj4+DQo+ID4+ Pj4+DQo+ID4+Pj4+IC0tDQo+ID4+Pj4+DQo+ID4+Pj4NCj4gPj4NCj4gKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+Pj4+PiAq KioqDQo+ID4+Pj4+ICAgICAgICAgICAgICAgICAgx+u8x9eho6zE48rHtsDSu87etv61xKOsvs3P 8cbky/vDv9K7uPbIy9K7DQo+INH5DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+IG1w bHNAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMNCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4gbXBsc0BpZXRmLm9yZw0KPiA+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pg0K From nobody Thu Jan 29 11:44:35 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5811A6FEF for ; Thu, 29 Jan 2015 11:44:32 -0800 (PST) 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=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWqMaKiF5srP for ; Thu, 29 Jan 2015 11:44:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061591A6F33 for ; Thu, 29 Jan 2015 11:44:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOO48652; Thu, 29 Jan 2015 19:44:26 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 19:44:25 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML703-CHM.china.huawei.com ([169.254.5.223]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 11:44:16 -0800 From: Cathy Zhang To: Cathy Zhang , Srini Addepalli , "Reinaldo Penno (repenno)" , "Joel M. Halpern" , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4g Date: Thu, 29 Jan 2015 19:44:15 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com>, <1417792592229.41970@freescale.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "nsmurthy@freescale.com" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 19:44:33 -0000 Hi everyone, We have uploaded a new SCH version (3) which adds definition of a new metad= ata type for the flow ID to support load balancing among SF instances and m= itigate the potential issue of "not enough path ID". The flow ID is named "= rendered service path ID" in the draft. Please refer to section 4.3.2 of ht= tps://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ for detail description.= =20 In its previous version, SCH defines a "Bypass bit" in the base header. Thi= s bit enables the SF to provide feedback/notification via the data path to = its connecting SFF about whether the remaining packets of the SFC should by= pass that SF. This is useful in the case that only the first few packets of= a flow need to go to a SF (such as a DPI or FW or IDS) and remaining packe= ts can bypass that SF, thus saving the expensive SF resource and reducing d= ata path latency. =20 B bit: The B (Bypass) bit, when set to 1, it is used by a Service=20 Function to signal to its Service Function Forwarder that no further packets are to be sent to it for the flow specified in encap= sulated packet. In addition, SCH defines a metadata type for Generic Context Block, which i= s optional and can be used if needed to carry any vendor's specific "Contex= t Header".=20 Any comments on these new additions?=20 Thanks, Cathy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang Sent: Friday, December 05, 2014 11:47 AM To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.o= rg' Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) Ron, Louis, Myo and I have been discussing off line last few weeks about de= fining a metadata type for flow ID in addition to the path ID of the main h= eader to support load balancing among SF instances. We will define a TLV ty= pe for the flow ID. The combination of "path ID + flow ID" specifies a real= ized service chain instance path. It is left to the design/implementation w= hether to use a centralized method or a distributed method to bind the flow= ID to a realized service instance path although our original thought is fo= r distributed LB usage. I am not sure if we need a bit in the header to den= ote whether there are more path ID bits (we call it flow ID) in the metadat= a fields since when you parse the TLV metadata, you will know whether there= are flow ID bits or not. Note that if multiple sessions share the same rea= lized service instance path, they will share the same "path ID+ flow ID". = We can also consider extending the number of bits to 32 if that is the cons= ensus. We will post an updated draft describing these soon.=20 Thanks, Cathy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Srini Addepalli Sent: Friday, December 05, 2014 7:17 AM To: Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org' Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) [RP] Data plane efficiency.=20 SRINI> I am not so sure about data plane efficiency. Most of the processor= s work good if the number of bits are either 32 or 64. If it is 24 bits, t= hen one needs to do masking and shifting before the value is used to do any= lookup. But, this discussion can go into different direction :-), it may= not be good to go in that direction. Where do we draw the line? 32-bits, 64-bits, 128 bits? I think we should have a sensible value in the Service Path header and if you need to convey more bits you need to use the context headers. SRINI> This is a good point. This should work fine as long as there is way= to convey in the main header that the extension to path ID is available in= so and so TLV field. That should work too. Thanks Srini ________________________________________ From: Reinaldo Penno (repenno) Sent: Friday, December 5, 2014 7:08 AM To: Addepalli Srini-B22160; Joel M. Halpern; 'sfc@ietf.org' Cc: NS Srinivasa Murthy-B37840 Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) On 12/5/14, 6:54 AM, "Srini Addepalli" wrote: > >In real deployments, number of active path IDs are very lesser than 2^64, >but there is a good possibility of the number being more than 2^24 (16M). > I think bigger point is that why restrict this in the standards? What >advantage do we have restricting this size to 24 bits? [RP] Data plane efficiency. Where do we draw the line? 32-bits, 64-bits, 128 bits? I think we should have a sensible value in the Service Path header and if you need to convey more bits you need to use the context headers. > >There can be deployments, where SFC controller (Logically central, but >distributed) itself can do the SF instance selection on per >connection/session basis, thereby avoiding the LBs for services. In my >view, assumption that there will be LB SF for each scale-out service in >the chain is not valid in all cases. > >Thanks >Srini > >________________________________________ >From: Reinaldo Penno (repenno) >Sent: Thursday, December 4, 2014 1:17 PM >To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >Cc: NS Srinivasa Murthy-B37840 >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >If I understood you, I do not think this is realistic. Are you saying you >need 64-bits of paths and then will monitor them all? Do fault tolerance >and OAM for 2^64-bits worth of paths? Just for comparison, it=B9s like >managing and monitoring the entire IPv6 host range, one-by-one. > >Anyway, I do not expect every single permutations to be a different path. > >If each service has 256 devices providing similar service, you should most >likely use load-balancing and then you would have a single (or a few) >paths. There is some discussion going on LB. > >From a data plane perspective, the path is ultimately defined by the SFFs >traversed and services provided, not by a specific IP:port that the device >providing the service sits on. Well, at least from a GPE+NSH perspective. > > >On 12/4/14, 12:57 PM, "Srini Addepalli" wrote: > >>If I take a chain with 5 services with each service say having 256 >>instances for scale-out, possible number of paths are 256*256*256*256*256 >>=3D 0xFF FF FF FF FF. One requires 33 bits in this case. If there are mo= re >>services in the chain or more chains or more instances for scale-out, >>then it could go to big number very fast. >> >>As I mentioned my preference is to make the path ID size flexible for >>future growth. If that is perceived as complex, then going for 64bit is >>safer bet. >> >>Thanks >>Srini >> >> >>-----Original Message----- >>From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>Sent: Thursday, December 04, 2014 12:05 PM >>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >>Cc: NS Srinivasa Murthy-B37840 >>Subject: Re: [sfc] Comments on SCH Draft >>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >> >>A controller (or other decision logic) can certainly be aware of such >>concerns. >>But the number of service function paths is not related to the number of >>flows or the number of tenants. It is related to the number of >>combinations of services and the policies for service function selection. >> While that can be a large number, I sure hope it does not come close to >>saturating 24 bits. >> >>Having said that, if we think that 24 bits is only just enough, then we >>ought to use 32. From where I sit, I would normally expect 16 bits to be >>more than sufficient, which is why I am comfortable with 24. Having said >>that, the field size is not a big deal to me. >> >>Yours, >>Joel >> >>On 12/4/14, 2:01 PM, Srini Addepalli wrote: >>> >>> I was not implying that path ID should have information in regards to >>>tenant/controller/flow/scale-out. But SFC controllers should keep these >>>in mind to assign the path ID. A deployment can have multiple >>>tenants, each tenant can have multiple networks, there could be >>>millions of flows in each of those networks. And considering all these, >>> 24 bit path ID may not be able to represent paths for these flows. >>>Hence, I was wondering whether path ID can be extended to 64 bits or >>>make it flexible. >>> >>> Thanks >>> Srini >>> >>> ________________________________________ >>> From: Joel M. Halpern >>> Sent: Thursday, December 4, 2014 7:42 AM >>> To: Addepalli Srini-B22160; sfc@ietf.org >>> Cc: NS Srinivasa Murthy-B37840 >>> Subject: Re: [sfc] Comments on SCH Draft >>> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>> >>> The Index is not just for loop prevention. In the case of ambiguity, >>> the index tells the SFF where in the path the packet currently resides. >>> There are multiple ways such ambiguity can occur. >>> >>> The Path Identifier is specifically not expected to include controller >>> ID or Tenant ID. While a deployer can have a path per tenant, the >>> architecture still does not treat the path ID as a tenant ID. Tenant >>> ID, controller ID, and other non-path-specifying information is to be >>> carried in metadata. >>> >>> Yours, >>> Joel >>> >>> On 12/4/14, 10:02 AM, Srini Addepalli wrote: >>>> Two comments : >>>> >>>> >>>> 1. SF Index : Since it is meant for loop detection, wouldn't >>>> better to rename this as "TTL"? >>>> >>>> 2. Path Identifier : 24 bit path identifier seems to be too less. >>>> Based on our experience in traffic steering, this path identifier >>>> needs to encode good amount of information to make it unique. For >>>>example, >>>> this identifier needs to encode (in our case) some information >>>> representing the distributed controller ID, tenant ID, flow ID, >>>> Service function instance (in case of scale-out) and few more.. >>>> One suggestion is to make it 64 bits value or to make it even >>>>extendable, >>>> it is good if path identifier is also represented in TLV form. >>>> >>>> >>>> Thanks >>>> >>>> Srini >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Jan 29 13:23:44 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDFF1A878B for ; Thu, 29 Jan 2015 13:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3e5BYcgTFv8A for ; Thu, 29 Jan 2015 13:23:40 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15EC1A877F for ; Thu, 29 Jan 2015 13:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12119; q=dns/txt; s=iport; t=1422566620; x=1423776220; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VSi7B+VtOeeUoGVHNYZ9xtPI14/IuoBvSabw23APOdo=; b=N4Tjgu87XeQYfmp+8Md+GFBD+UBsOyTf6OTbgM2n6+AHIYxpNPF7/hia T31MBcY5cOuNyyFTmljfD3qpZHuXr3meoTT6p9hxW/jjSeIfkmKcWNzeg ZGaBLOrOvbPshh9/ZMcUMHUGRWSYjXWSBGY+eHI9ZKvNZ5YzJg6wOC1Ak 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAAqkylStJA2B/2dsb2JhbABagwZSWQTEUwqFcQKBJkMBAQEBAX2EDAEBAQMBAQEBZAcLBQcEAgEIEQEDAQEBJwcnCxQDBggCBA4FiCQIDdcrAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPFTAIKwcCBIMQgRMFiWaFFoNLhVeBF4MBiACCfIM9IoICHBSBPG8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,488,1418083200"; d="scan'208";a="391909446" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 29 Jan 2015 21:23:38 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t0TLNcdS015531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Jan 2015 21:23:38 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.163]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 15:23:38 -0600 From: "Paul Quinn (paulq)" To: Cathy Zhang Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/9uiAgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgCAAEtwAIBWb4+AgAAbwIA= Date: Thu, 29 Jan 2015 21:23:37 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <, <>> <1417792592229.41970@freescale.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.17.229] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <19BD0404AFB46C4489F8649AA247C4DE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Reinaldo Penno \(repenno\)" , "Joel M. Halpern" , Srini Addepalli , "sfc@ietf.org" , "nsmurthy@freescale.com" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 21:23:43 -0000 Cathy, I believe that you omitted a reference to an existing draft that clearly de= scribes the use of what you call bypass (and provides an implemenation exam= ple). =20 I suggest that you review https://datatracker.ietf.org/doc/draft-kumar-sfc-= sfp-optimization/ and update your references accordingly. Paul > On Jan 29, 2015, at 2:44 PM, Cathy Zhang wrote= : >=20 > Hi everyone, >=20 > We have uploaded a new SCH version (3) which adds definition of a new met= adata type for the flow ID to support load balancing among SF instances and= mitigate the potential issue of "not enough path ID". The flow ID is named= "rendered service path ID" in the draft. Please refer to section 4.3.2 of = https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ for detail descriptio= n.=20 >=20 > In its previous version, SCH defines a "Bypass bit" in the base header. T= his bit enables the SF to provide feedback/notification via the data path t= o its connecting SFF about whether the remaining packets of the SFC should = bypass that SF. This is useful in the case that only the first few packets = of a flow need to go to a SF (such as a DPI or FW or IDS) and remaining pac= kets can bypass that SF, thus saving the expensive SF resource and reducing= data path latency. =20 >=20 > B bit: The B (Bypass) bit, when set to 1, it is used by a Service=20 > Function to signal to its Service Function Forwarder that no > further packets are to be sent to it for the flow specified in enca= psulated packet. >=20 > In addition, SCH defines a metadata type for Generic Context Block, which= is optional and can be used if needed to carry any vendor's specific "Cont= ext Header".=20 >=20 > Any comments on these new additions?=20 >=20 > Thanks, > Cathy >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang > Sent: Friday, December 05, 2014 11:47 AM > To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf= .org' > Cc: nsmurthy@freescale.com > Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/dra= ft-zhang-sfc-sch-02) >=20 > Ron, Louis, Myo and I have been discussing off line last few weeks about = defining a metadata type for flow ID in addition to the path ID of the main= header to support load balancing among SF instances. We will define a TLV = type for the flow ID. The combination of "path ID + flow ID" specifies a re= alized service chain instance path. It is left to the design/implementation= whether to use a centralized method or a distributed method to bind the fl= ow ID to a realized service instance path although our original thought is = for distributed LB usage. I am not sure if we need a bit in the header to d= enote whether there are more path ID bits (we call it flow ID) in the metad= ata fields since when you parse the TLV metadata, you will know whether the= re are flow ID bits or not. Note that if multiple sessions share the same r= ealized service instance path, they will share the same "path ID+ flow ID".= We can also consider extending the number of bits to 32 if that is the co= nsensus. We will post an updated draft describing these soon.=20 >=20 > Thanks, > Cathy >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Srini Addepalli > Sent: Friday, December 05, 2014 7:17 AM > To: Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org' > Cc: nsmurthy@freescale.com > Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/dra= ft-zhang-sfc-sch-02) >=20 >=20 > [RP] Data plane efficiency.=20 >=20 > SRINI> I am not so sure about data plane efficiency. Most of the process= ors work good if the number of bits are either 32 or 64. If it is 24 bits,= then one needs to do masking and shifting before the value is used to do a= ny lookup. But, this discussion can go into different direction :-), it m= ay not be good to go in that direction. >=20 > Where do we draw the line? 32-bits, 64-bits, > 128 bits? I think we should have a sensible value in the Service Path > header and if you need to convey more bits you need to use the context > headers. >=20 > SRINI> This is a good point. This should work fine as long as there is w= ay to convey in the main header that the extension to path ID is available = in so and so TLV field. That should work too. >=20 > Thanks > Srini >=20 > ________________________________________ > From: Reinaldo Penno (repenno) > Sent: Friday, December 5, 2014 7:08 AM > To: Addepalli Srini-B22160; Joel M. Halpern; 'sfc@ietf.org' > Cc: NS Srinivasa Murthy-B37840 > Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/dra= ft-zhang-sfc-sch-02) >=20 > On 12/5/14, 6:54 AM, "Srini Addepalli" wrote: >=20 >>=20 >> In real deployments, number of active path IDs are very lesser than 2^64= , >> but there is a good possibility of the number being more than 2^24 (16M)= . >> I think bigger point is that why restrict this in the standards? What >> advantage do we have restricting this size to 24 bits? >=20 > [RP] Data plane efficiency. Where do we draw the line? 32-bits, 64-bits, > 128 bits? I think we should have a sensible value in the Service Path > header and if you need to convey more bits you need to use the context > headers. >=20 >=20 >>=20 >> There can be deployments, where SFC controller (Logically central, but >> distributed) itself can do the SF instance selection on per >> connection/session basis, thereby avoiding the LBs for services. In my >> view, assumption that there will be LB SF for each scale-out service in >> the chain is not valid in all cases. >>=20 >> Thanks >> Srini >>=20 >> ________________________________________ >> From: Reinaldo Penno (repenno) >> Sent: Thursday, December 4, 2014 1:17 PM >> To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >> Cc: NS Srinivasa Murthy-B37840 >> Subject: Re: [sfc] Comments on SCH Draft >> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>=20 >> If I understood you, I do not think this is realistic. Are you saying yo= u >> need 64-bits of paths and then will monitor them all? Do fault tolerance >> and OAM for 2^64-bits worth of paths? Just for comparison, it=B9s like >> managing and monitoring the entire IPv6 host range, one-by-one. >>=20 >> Anyway, I do not expect every single permutations to be a different path= . >>=20 >> If each service has 256 devices providing similar service, you should mo= st >> likely use load-balancing and then you would have a single (or a few) >> paths. There is some discussion going on LB. >>=20 >> From a data plane perspective, the path is ultimately defined by the SFF= s >> traversed and services provided, not by a specific IP:port that the devi= ce >> providing the service sits on. Well, at least from a GPE+NSH perspective= . >>=20 >>=20 >> On 12/4/14, 12:57 PM, "Srini Addepalli" wrote= : >>=20 >>> If I take a chain with 5 services with each service say having 256 >>> instances for scale-out, possible number of paths are 256*256*256*256*2= 56 >>> =3D 0xFF FF FF FF FF. One requires 33 bits in this case. If there are = more >>> services in the chain or more chains or more instances for scale-out, >>> then it could go to big number very fast. >>>=20 >>> As I mentioned my preference is to make the path ID size flexible for >>> future growth. If that is perceived as complex, then going for 64bit is >>> safer bet. >>>=20 >>> Thanks >>> Srini >>>=20 >>>=20 >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Thursday, December 04, 2014 12:05 PM >>> To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >>> Cc: NS Srinivasa Murthy-B37840 >>> Subject: Re: [sfc] Comments on SCH Draft >>> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>>=20 >>> A controller (or other decision logic) can certainly be aware of such >>> concerns. >>> But the number of service function paths is not related to the number o= f >>> flows or the number of tenants. It is related to the number of >>> combinations of services and the policies for service function selectio= n. >>> While that can be a large number, I sure hope it does not come close to >>> saturating 24 bits. >>>=20 >>> Having said that, if we think that 24 bits is only just enough, then we >>> ought to use 32. From where I sit, I would normally expect 16 bits to = be >>> more than sufficient, which is why I am comfortable with 24. Having sa= id >>> that, the field size is not a big deal to me. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 12/4/14, 2:01 PM, Srini Addepalli wrote: >>>>=20 >>>> I was not implying that path ID should have information in regards to >>>> tenant/controller/flow/scale-out. But SFC controllers should keep the= se >>>> in mind to assign the path ID. A deployment can have multiple >>>> tenants, each tenant can have multiple networks, there could be >>>> millions of flows in each of those networks. And considering all thes= e, >>>> 24 bit path ID may not be able to represent paths for these flows. >>>> Hence, I was wondering whether path ID can be extended to 64 bits or >>>> make it flexible. >>>>=20 >>>> Thanks >>>> Srini >>>>=20 >>>> ________________________________________ >>>> From: Joel M. Halpern >>>> Sent: Thursday, December 4, 2014 7:42 AM >>>> To: Addepalli Srini-B22160; sfc@ietf.org >>>> Cc: NS Srinivasa Murthy-B37840 >>>> Subject: Re: [sfc] Comments on SCH Draft >>>> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>>>=20 >>>> The Index is not just for loop prevention. In the case of ambiguity, >>>> the index tells the SFF where in the path the packet currently resides= . >>>> There are multiple ways such ambiguity can occur. >>>>=20 >>>> The Path Identifier is specifically not expected to include controller >>>> ID or Tenant ID. While a deployer can have a path per tenant, the >>>> architecture still does not treat the path ID as a tenant ID. Tenant >>>> ID, controller ID, and other non-path-specifying information is to be >>>> carried in metadata. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 12/4/14, 10:02 AM, Srini Addepalli wrote: >>>>> Two comments : >>>>>=20 >>>>>=20 >>>>> 1. SF Index : Since it is meant for loop detection, wouldn't >>>>> better to rename this as "TTL"? >>>>>=20 >>>>> 2. Path Identifier : 24 bit path identifier seems to be too less. >>>>> Based on our experience in traffic steering, this path identifier >>>>> needs to encode good amount of information to make it unique. For >>>>> example, >>>>> this identifier needs to encode (in our case) some information >>>>> representing the distributed controller ID, tenant ID, flow ID, >>>>> Service function instance (in case of scale-out) and few more.. >>>>> One suggestion is to make it 64 bits value or to make it even >>>>> extendable, >>>>> it is good if path identifier is also represented in TLV form. >>>>>=20 >>>>>=20 >>>>> Thanks >>>>>=20 >>>>> Srini >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jan 30 03:38:13 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B6D1A8F37 for ; Fri, 30 Jan 2015 03:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiwG6quHqJim for ; Fri, 30 Jan 2015 03:38:05 -0800 (PST) Received: from mc24.lon.server.colt.net (mc24.lon.server.colt.net [212.74.77.104]) by ietfa.amsl.com (Postfix) with ESMTP id 741C71A8BC5 for ; Fri, 30 Jan 2015 03:38:04 -0800 (PST) Received: from mc24.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8E5D81E006E for ; Fri, 30 Jan 2015 11:38:02 +0000 (UTC) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc24.lon.server.colt.net (Postfix) with ESMTP id 697191E0045 for ; Fri, 30 Jan 2015 11:38:02 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.09,491,1418079600"; d="scan'208";a="1506367" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 30 Jan 2015 12:38:02 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.51]) with mapi id 14.01.0438.000; Fri, 30 Jan 2015 12:38:01 +0100 From: Nicolas BOUTHORS To: Cathy Zhang , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQO/5DH/wTNyDwgkS9ydl+3/sIXZzYeC9A Date: Fri, 30 Jan 2015 11:38:00 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com>, <1417792592229.41970@freescale.com> In-Reply-To: Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-7.5.0.1018-21292.006 X-TM-AS-Result: No--32.306-5.0-31-10 X-imss-scan-details: No--32.306-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-Version: IMSVA-8.2.0.1679-7.5.1018-21292.006 X-TMASE-Result: 10--32.306300-5.000000 X-TMASE-MatchedRID: l4bxV8Hot0EpwNTiG5IsEjDfgfM3Zc/RkT7cMJfe6Ju638ZUY6gSd8lO 14E7OluC9j3V/2NT7SOEmp+esCczKu6QcuaXEyZOMIiU395I8H0zc8FC0MEwT9UykPK1RFAonfW 7sz7e3/7zk6lHKY3Pf+6Avfi45Pl5orXvpLj1Q0fKUCo1O3wV1VAI6wCVrE3vWabPstVV86n3hV qZ9UIEDvbmUJBrlXZ6avo7g6bCba7tvMVN/9JMyszWN98iBBeGpxwSG8jIwhRnnK6mXN72m8hn1 Ic03CCkjJg4DkSEeWRRS7xjEb+dxKvMAWimA+x/bBu6+EIezdw2vbWaKPnQ21S+oHmj8upzkqO2 AbVSuPwHXE5t+qNveT/U4p7KPAQXpF+0lJVCjVWJQ9k+Ypk5CQsE9gx+4jJuvStYzicikmu3Cq/ Z6GbmSX+4w6FvtqdqOSvqZEF50IxFhnuoIz0wod/wYmMFcJSITXnWmEdM1hHkMnUVL5d0E1D6Ya Jho05l7+U2XZtk9iqE+nLF9zB0AZY8NqPobX+LW7gz/Gbgpl5imi8LvNfmr2rhyhOS2sZfCHcG+ 1BToTKv5+ENPTcy9LHyebymXrvoZCSBV6VCLjXx5KZMlKYS/WlYsa84w2hTLLoMUXmFqmYQ7tWd 3Cjw3lVKgk1zIX2/WEYSSzCyggEwdNeS5WKnLHPkIViiTNOD0jJvp2mlCWAwEhHW5KVAzwBuo8M 5Nxn407I9vh2gtDMaJb4OkejEyBYdCmVPeiAabQ9aoPSmWJEAHmJpemgWruyuaeea5tPzZwgFEq tFxBEu2MLpd1qzAozzUBYJlbzG7ELzYy1LdXmeAiCmPx4NwMFrpUbb72MU1B0Hk1Q1KyKlpfSTJ RNTL7ew1twePJJB3QfwsVk0UbslCGssfkpInQ== Archived-At: Cc: Jerome TOLLET Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 11:38:09 -0000 SGVsbG8gQ2F0aHksDQoNCkluZGVlZCB0aGUgbm90aW9uIG9mICJyZW5kZXJlZCBzZXJ2aWNlIHBh dGggSUQiKFJTUCBJRCkgc2VlbXMgcmVsZXZhbnQgYXMgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVu dCBzdGlwdWxhdGVzIHRoYXQgdGhlIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBwcm92aWRl cyBhbiBhYnN0cmFjdCBub3Rpb24gb2YgYSBzZXJ2aWNlIGNoYWluLCB3aGlsZSB0aGUgUlNQIGlz IGEgY29uc3RyYWluZWQgbGlzdCBvZiBsb2NhdGlvbnMuDQoNClNGQyBoZWFkZXIgIlNlcnZpY2Ug UGF0aCBJZGVudGlmaWVyIiAoU1BJKSAgaXMgdXNlZCBpbiBib3RoIE5TSCBhbmQgU0NIIHByb3Rv Y29sIGFuZCBpbiBib3RoIGNhc2Ugc2VlbSB0byBpZGVudGlmeSB0byBhIHBhcnRpY3VsYXIgU0ZQ Lg0KDQpOU0godjUpIGZvciBleGFtcGxlIHN0YXRlcyB0aGF0DQoiIEFzIGRlc2NyaWJlZCBhYm92 ZSwgTlNIIGNvbnRhaW5zIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgKFNQSSkgYW5kDQogICBh IHNlcnZpY2UgaW5kZXggKFNJKS4gIFRoZSBTUEkgaXMsIGFzIHBlciBpdHMgbmFtZSwgYW4gaWRl bnRpZmllci4NCiAgIFRoZSBTUEkgYWxvbmUgY2Fubm90IGJlIHVzZWQgdG8gZm9yd2FyZCBwYWNr ZXRzIGFsb25nIGEgc2VydmljZSBwYXRoLg0KICAgUmF0aGVyIHRoZSBTUEkgcHJvdmlkZSBhIGxl dmVsIG9mIGluZGlyZWN0aW9uIGJldHdlZW4gdGhlIHNlcnZpY2UNCiAgIHBhdGgvdG9wb2xvZ3kg YW5kIHRoZSB0aGUgbmV0d29yayB0cmFuc3BvcnQuICBGdXJ0aGVybW9yZSwgdGhlcmUgaXMNCiAg IG5vIHJlcXVpcmVtZW50LCBvciBleHBlY3RhdGlvbiBvZiBhbiBTUEkgYmVpbmcgYm91bmQgdG8g YSBwcmUtDQogICBkZXRlcm1pbmVkIG9yIHN0YXRpYyBuZXR3b3JrIHBhdGguIg0KDQpTdGlsbCBO U0godjUpICBzaG93cyB0aGF0IFNQSSAobm90IGEgUlNQIElEKSAgc2hvdWxkIGJlIHBhcnQgb2Yg dGhlIGtleSAgZWxlbWVudCBvZiBhbiBTRkYgdG8gbG9va3VwIG9uIGZvcndhcmRpbmcgdGFibGVz LiAgQnV0IEkgY291bGQgbm90IGZpbmQgaW4gTlNIICBob3cgdG8gdXNlIHRoZSBub3Rpb24gb2YN ClJlbmRlcmVkIHNlcnZpY2UgcGF0aCB3aGljaCB3YXMgZGVmaW5lZCBpbiB0aGUgYXJjaGl0ZWN0 dXJlIGRvY3VtZW50Lg0KDQpZb3UgcHJvcG9zYWwgc2VlbXMgdG8gbWUgdmVyeSB1c2VmdWwsDQoN CkFuIFJTUCBJRCAoaW5kZXBlbmRlbnQgb2YgdGhlIFNQSSBidXQgcGFydCBvZiB0aGUgc2FtZSBu YW1lIHNwYWNlKSBjb3VsZCBiZSB1c2VkIHRoZSBzYW1lIHdheSBhcyBTUEkgYnkgU0ZGIGZvciBl eGFtcGxlLCBhbGxvd2luZyBhIFNlcnZpY2UgQ2xhc3NpZmllciB0byBjb250cm9sIHJlbW90ZSBs b2FkIGJhbGFuY2luZyBmb3IgZXhhbXBsZS4NCg0KVGhpcyBzYWlkIHRoZSBSU1AgSUQgdmFsdWVz IGNvdWxkIGJlIHJlbGF0aXZlIHRvIGEgcGFydGljdWxhciBTZXJ2aWNlIFBhdGgsIHdoaWNoIHdv dWxkIHByZXZlbnQgdXNpbmcgdGhlbSBhcyB3ZSBkbyBmb3IgU1BJIGluIFNGRiBmb3J3YXJkaW5n IHRhYmxlcy4NCg0KV2UgbWF5IHdhbnQgdG8gcHJlY2lzZSBpZiB0aGUgUlNQIElEIGlzIHRvIGJl IHJlbGF0aXZlIG9mIGFic29sdXRlLCBhcyBpdCBzaG91bGQgaGF2ZSBhbiBpbXBhY3Qgb24gZm9y d2FyZGluZyB0YWJsZSBzdHJ1Y3R1cmUgaWYgd2UgZGVjaWRlIHRvIHVzZSB0aGlzIGNvbmNlcHQu DQoNClBlcnNvbmFsbHkgSSBsaWtlIHRoZSBub3Rpb24gb2YgYSByZWxhdGl2ZSBSU1AgSUQsIGFz IHdlIGNvdWxkIHRoZW4gdXNlIHNvbWUgY29udmVudGlvbnMsIHN0cnVjdHVyZSBpdCwgcG9zc2li bHkgZXh0ZW5kaW5nIGl0cyB1c2UuDQoNCk5pY29sYXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IENhdGh5IFpoYW5nIFttYWlsdG86Q2F0aHkuSC5aaGFuZ0BodWF3ZWkuY29t XQ0KU2VudDogamV1ZGkgMjkgamFudmllciAyMDE1IDIwOjQ0DQpUbzogQ2F0aHkgWmhhbmc7IFNy aW5pIEFkZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uIEhhbHBlcm47 ICdzZmNAaWV0Zi5vcmcnDQpDYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0KU3ViamVjdDogUmU6 IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQoNCkhpIGV2ZXJ5b25lLA0KDQpXZSBoYXZlIHVwbG9h ZGVkIGEgbmV3IFNDSCB2ZXJzaW9uICgzKSB3aGljaCBhZGRzIGRlZmluaXRpb24gb2YgYSBuZXcg bWV0YWRhdGEgdHlwZSBmb3IgdGhlIGZsb3cgSUQgdG8gc3VwcG9ydCBsb2FkIGJhbGFuY2luZyBh bW9uZyBTRiBpbnN0YW5jZXMgYW5kIG1pdGlnYXRlIHRoZSBwb3RlbnRpYWwgaXNzdWUgb2YgIm5v dCBlbm91Z2ggcGF0aCBJRCIuIFRoZSBmbG93IElEIGlzIG5hbWVkICJyZW5kZXJlZCBzZXJ2aWNl IHBhdGggSUQiIGluIHRoZSBkcmFmdC4gUGxlYXNlIHJlZmVyIHRvIHNlY3Rpb24gNC4zLjIgb2Yg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctc2ZjLXNjaC8gZm9y IGRldGFpbCBkZXNjcmlwdGlvbi4NCg0KSW4gaXRzIHByZXZpb3VzIHZlcnNpb24sIFNDSCBkZWZp bmVzIGEgIkJ5cGFzcyBiaXQiIGluIHRoZSBiYXNlIGhlYWRlci4gVGhpcyBiaXQgZW5hYmxlcyB0 aGUgU0YgdG8gcHJvdmlkZSBmZWVkYmFjay9ub3RpZmljYXRpb24gdmlhIHRoZSBkYXRhIHBhdGgg dG8gaXRzIGNvbm5lY3RpbmcgU0ZGIGFib3V0IHdoZXRoZXIgdGhlIHJlbWFpbmluZyBwYWNrZXRz IG9mIHRoZSBTRkMgc2hvdWxkIGJ5cGFzcyB0aGF0IFNGLiBUaGlzIGlzIHVzZWZ1bCBpbiB0aGUg Y2FzZSB0aGF0IG9ubHkgdGhlIGZpcnN0IGZldyBwYWNrZXRzIG9mIGEgZmxvdyBuZWVkIHRvIGdv IHRvIGEgU0YgKHN1Y2ggYXMgYSBEUEkgb3IgRlcgb3IgSURTKSBhbmQgcmVtYWluaW5nIHBhY2tl dHMgY2FuIGJ5cGFzcyB0aGF0IFNGLCB0aHVzIHNhdmluZyB0aGUgZXhwZW5zaXZlIFNGIHJlc291 cmNlIGFuZCByZWR1Y2luZyBkYXRhIHBhdGggbGF0ZW5jeS4NCg0KQiBiaXQ6IFRoZSBCIChCeXBh c3MpIGJpdCwgd2hlbiBzZXQgdG8gMSwgaXQgaXMgdXNlZCBieSBhIFNlcnZpY2UNCiAgICAgICBG dW5jdGlvbiB0byBzaWduYWwgdG8gaXRzIFNlcnZpY2UgRnVuY3Rpb24gRm9yd2FyZGVyIHRoYXQg bm8NCiAgICAgICBmdXJ0aGVyIHBhY2tldHMgYXJlIHRvIGJlIHNlbnQgdG8gaXQgZm9yIHRoZSBm bG93IHNwZWNpZmllZCBpbiBlbmNhcHN1bGF0ZWQgcGFja2V0Lg0KDQpJbiBhZGRpdGlvbiwgU0NI IGRlZmluZXMgYSBtZXRhZGF0YSB0eXBlIGZvciBHZW5lcmljIENvbnRleHQgQmxvY2ssIHdoaWNo IGlzIG9wdGlvbmFsIGFuZCBjYW4gYmUgdXNlZCBpZiBuZWVkZWQgdG8gY2FycnkgYW55IHZlbmRv cidzIHNwZWNpZmljICJDb250ZXh0IEhlYWRlciIuDQoNCkFueSBjb21tZW50cyBvbiB0aGVzZSBu ZXcgYWRkaXRpb25zPw0KDQpUaGFua3MsDQpDYXRoeQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBDYXRoeSBaaGFuZw0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCAxMTo0NyBBTQ0K VG86IFNyaW5pIEFkZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uIEhh bHBlcm47ICdzZmNAaWV0Zi5vcmcnDQpDYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0KU3ViamVj dDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCAoaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQoNClJvbiwgTG91aXMsIE15byBhbmQgSSBo YXZlIGJlZW4gZGlzY3Vzc2luZyBvZmYgbGluZSBsYXN0IGZldyB3ZWVrcyBhYm91dCBkZWZpbmlu ZyBhIG1ldGFkYXRhIHR5cGUgZm9yIGZsb3cgSUQgaW4gYWRkaXRpb24gdG8gdGhlIHBhdGggSUQg b2YgdGhlIG1haW4gaGVhZGVyIHRvIHN1cHBvcnQgbG9hZCBiYWxhbmNpbmcgYW1vbmcgU0YgaW5z dGFuY2VzLiBXZSB3aWxsIGRlZmluZSBhIFRMViB0eXBlIGZvciB0aGUgZmxvdyBJRC4gVGhlIGNv bWJpbmF0aW9uIG9mICJwYXRoIElEICsgZmxvdyBJRCIgc3BlY2lmaWVzIGEgcmVhbGl6ZWQgc2Vy dmljZSBjaGFpbiBpbnN0YW5jZSBwYXRoLiBJdCBpcyBsZWZ0IHRvIHRoZSBkZXNpZ24vaW1wbGVt ZW50YXRpb24gd2hldGhlciB0byB1c2UgYSBjZW50cmFsaXplZCBtZXRob2Qgb3IgYSBkaXN0cmli dXRlZCBtZXRob2QgdG8gYmluZCB0aGUgZmxvdyBJRCB0byBhIHJlYWxpemVkIHNlcnZpY2UgaW5z dGFuY2UgcGF0aCBhbHRob3VnaCBvdXIgb3JpZ2luYWwgdGhvdWdodCBpcyBmb3IgZGlzdHJpYnV0 ZWQgTEIgdXNhZ2UuIEkgYW0gbm90IHN1cmUgaWYgd2UgbmVlZCBhIGJpdCBpbiB0aGUgaGVhZGVy IHRvIGRlbm90ZSB3aGV0aGVyIHRoZXJlIGFyZSBtb3JlIHBhdGggSUQgYml0cyAod2UgY2FsbCBp dCBmbG93IElEKSBpbiB0aGUgbWV0YWRhdGEgZmllbGRzIHNpbmNlIHdoZW4geW91IHBhcnNlIHRo ZSBUTFYgbWV0YWRhdGEsIHlvdSB3aWxsIGtub3cgd2hldGhlciB0aGVyZSBhcmUgZmxvdyBJRCBi aXRzIG9yIG5vdC4gTm90ZSB0aGF0IGlmIG11bHRpcGxlIHNlc3Npb25zIHNoYXJlIHRoZSBzYW1l IHJlYWxpemVkIHNlcnZpY2UgaW5zdGFuY2UgcGF0aCwgdGhleSB3aWxsIHNoYXJlIHRoZSBzYW1l ICJwYXRoIElEKyBmbG93IElEIi4gIFdlIGNhbiBhbHNvIGNvbnNpZGVyIGV4dGVuZGluZyB0aGUg bnVtYmVyIG9mIGJpdHMgdG8gMzIgaWYgdGhhdCBpcyB0aGUgY29uc2Vuc3VzLiBXZSB3aWxsIHBv c3QgYW4gdXBkYXRlZCBkcmFmdCBkZXNjcmliaW5nIHRoZXNlIHNvb24uDQoNClRoYW5rcywNCkNh dGh5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNyaW5pIEFkZGVwYWxsaQ0KU2VudDogRnJp ZGF5LCBEZWNlbWJlciAwNSwgMjAxNCA3OjE3IEFNDQpUbzogUmVpbmFsZG8gUGVubm8gKHJlcGVu bm8pOyBKb2VsIE0uIEhhbHBlcm47ICdzZmNAaWV0Zi5vcmcnDQpDYzogbnNtdXJ0aHlAZnJlZXNj YWxlLmNvbQ0KU3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCAoaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQoNCg0KW1JQXSBE YXRhIHBsYW5lIGVmZmljaWVuY3kuDQoNClNSSU5JPiBJIGFtIG5vdCBzbyBzdXJlIGFib3V0IGRh dGEgcGxhbmUgZWZmaWNpZW5jeS4gIE1vc3Qgb2YgdGhlIHByb2Nlc3NvcnMgd29yayBnb29kIGlm IHRoZSBudW1iZXIgb2YgYml0cyBhcmUgZWl0aGVyIDMyIG9yIDY0LiAgSWYgaXQgaXMgMjQgYml0 cywgdGhlbiBvbmUgbmVlZHMgdG8gZG8gbWFza2luZyBhbmQgc2hpZnRpbmcgYmVmb3JlIHRoZSB2 YWx1ZSBpcyB1c2VkIHRvIGRvIGFueSBsb29rdXAuICAgQnV0LCB0aGlzIGRpc2N1c3Npb24gY2Fu IGdvIGludG8gZGlmZmVyZW50IGRpcmVjdGlvbiA6LSksIGl0IG1heSBub3QgYmUgZ29vZCB0byBn byBpbiB0aGF0IGRpcmVjdGlvbi4NCg0KV2hlcmUgZG8gd2UgZHJhdyB0aGUgbGluZT8gMzItYml0 cywgNjQtYml0cywNCjEyOCBiaXRzPyBJIHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgc2Vuc2libGUg dmFsdWUgaW4gdGhlIFNlcnZpY2UgUGF0aCBoZWFkZXIgYW5kIGlmIHlvdSBuZWVkIHRvIGNvbnZl eSBtb3JlIGJpdHMgeW91IG5lZWQgdG8gdXNlIHRoZSBjb250ZXh0IGhlYWRlcnMuDQoNClNSSU5J PiBUaGlzIGlzIGEgZ29vZCBwb2ludC4gIFRoaXMgc2hvdWxkIHdvcmsgZmluZSBhcyBsb25nIGFz IHRoZXJlIGlzIHdheSB0byBjb252ZXkgaW4gdGhlIG1haW4gaGVhZGVyIHRoYXQgdGhlIGV4dGVu c2lvbiB0byBwYXRoIElEIGlzIGF2YWlsYWJsZSBpbiBzbyBhbmQgc28gVExWIGZpZWxkLiAgVGhh dCBzaG91bGQgd29yayB0b28uDQoNClRoYW5rcw0KU3JpbmkNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIDxy ZXBlbm5vQGNpc2NvLmNvbT4NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgNSwgMjAxNCA3OjA4IEFN DQpUbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgSm9lbCBNLiBIYWxwZXJuOyAnc2ZjQGlldGYu b3JnJw0KQ2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQpTdWJqZWN0OiBSZTogW3NmY10g Q29tbWVudHMgb24gU0NIIERyYWZ0IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt emhhbmctc2ZjLXNjaC0wMikNCg0KT24gMTIvNS8xNCwgNjo1NCBBTSwgIlNyaW5pIEFkZGVwYWxs aSIgPHNhZGRlcGFsbGlAZnJlZXNjYWxlLmNvbT4gd3JvdGU6DQoNCj4NCj5JbiByZWFsIGRlcGxv eW1lbnRzLCBudW1iZXIgb2YgYWN0aXZlIHBhdGggSURzIGFyZSB2ZXJ5IGxlc3NlciB0aGFuDQo+ Ml42NCwgYnV0IHRoZXJlIGlzIGEgZ29vZCBwb3NzaWJpbGl0eSBvZiB0aGUgbnVtYmVyIGJlaW5n IG1vcmUgdGhhbiAyXjI0ICgxNk0pLg0KPiBJIHRoaW5rIGJpZ2dlciBwb2ludCBpcyB0aGF0IHdo eSByZXN0cmljdCB0aGlzIGluIHRoZSBzdGFuZGFyZHM/IFdoYXQNCj5hZHZhbnRhZ2UgZG8gd2Ug aGF2ZSByZXN0cmljdGluZyB0aGlzIHNpemUgdG8gMjQgYml0cz8NCg0KW1JQXSBEYXRhIHBsYW5l IGVmZmljaWVuY3kuIFdoZXJlIGRvIHdlIGRyYXcgdGhlIGxpbmU/IDMyLWJpdHMsIDY0LWJpdHMs DQoxMjggYml0cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRo ZSBTZXJ2aWNlIFBhdGggaGVhZGVyIGFuZCBpZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRz IHlvdSBuZWVkIHRvIHVzZSB0aGUgY29udGV4dCBoZWFkZXJzLg0KDQoNCj4NCj5UaGVyZSBjYW4g YmUgZGVwbG95bWVudHMsIHdoZXJlIFNGQyBjb250cm9sbGVyIChMb2dpY2FsbHkgY2VudHJhbCwg YnV0DQo+ZGlzdHJpYnV0ZWQpICBpdHNlbGYgY2FuIGRvIHRoZSBTRiBpbnN0YW5jZSBzZWxlY3Rp b24gb24gcGVyDQo+Y29ubmVjdGlvbi9zZXNzaW9uIGJhc2lzLCB0aGVyZWJ5IGF2b2lkaW5nIHRo ZSBMQnMgZm9yIHNlcnZpY2VzLiAgIEluIG15DQo+dmlldywgYXNzdW1wdGlvbiB0aGF0IHRoZXJl IHdpbGwgYmUgTEIgU0YgZm9yIGVhY2ggc2NhbGUtb3V0IHNlcnZpY2UgaW4NCj50aGUgY2hhaW4g aXMgbm90IHZhbGlkIGluIGFsbCBjYXNlcy4NCj4NCj5UaGFua3MNCj5TcmluaQ0KPg0KPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Gcm9tOiBSZWluYWxkbyBQZW5u byAocmVwZW5ubykgPHJlcGVubm9AY2lzY28uY29tPg0KPlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJl ciA0LCAyMDE0IDE6MTcgUE0NCj5UbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgSm9lbCBNLiBI YWxwZXJuOyBzZmNAaWV0Zi5vcmcNCj5DYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj5T dWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPklmIEkgdW5kZXJzdG9v ZCB5b3UsIEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgcmVhbGlzdGljLiBBcmUgeW91IHNheWluZw0K PnlvdSBuZWVkIDY0LWJpdHMgb2YgcGF0aHMgYW5kIHRoZW4gd2lsbCBtb25pdG9yIHRoZW0gYWxs PyBEbyBmYXVsdA0KPnRvbGVyYW5jZSBhbmQgT0FNIGZvciAyXjY0LWJpdHMgd29ydGggb2YgcGF0 aHM/IEp1c3QgZm9yIGNvbXBhcmlzb24sDQo+aXTCuXMgbGlrZSBtYW5hZ2luZyBhbmQgbW9uaXRv cmluZyB0aGUgZW50aXJlIElQdjYgaG9zdCByYW5nZSwgb25lLWJ5LW9uZS4NCj4NCj5Bbnl3YXks IEkgZG8gbm90IGV4cGVjdCBldmVyeSBzaW5nbGUgcGVybXV0YXRpb25zIHRvIGJlIGEgZGlmZmVy ZW50IHBhdGguDQo+DQo+SWYgZWFjaCBzZXJ2aWNlIGhhcyAyNTYgZGV2aWNlcyBwcm92aWRpbmcg c2ltaWxhciBzZXJ2aWNlLCB5b3Ugc2hvdWxkDQo+bW9zdCBsaWtlbHkgdXNlIGxvYWQtYmFsYW5j aW5nIGFuZCB0aGVuIHlvdSB3b3VsZCBoYXZlIGEgc2luZ2xlIChvciBhDQo+ZmV3KSBwYXRocy4g VGhlcmUgaXMgc29tZSBkaXNjdXNzaW9uIGdvaW5nIG9uIExCLg0KPg0KPkZyb20gYSBkYXRhIHBs YW5lIHBlcnNwZWN0aXZlLCB0aGUgcGF0aCBpcyB1bHRpbWF0ZWx5IGRlZmluZWQgYnkgdGhlDQo+ U0ZGcyB0cmF2ZXJzZWQgYW5kIHNlcnZpY2VzIHByb3ZpZGVkLCBub3QgYnkgYSBzcGVjaWZpYyBJ UDpwb3J0IHRoYXQNCj50aGUgZGV2aWNlIHByb3ZpZGluZyB0aGUgc2VydmljZSBzaXRzIG9uLiBX ZWxsLCBhdCBsZWFzdCBmcm9tIGEgR1BFK05TSCBwZXJzcGVjdGl2ZS4NCj4NCj4NCj5PbiAxMi80 LzE0LCAxMjo1NyBQTSwgIlNyaW5pIEFkZGVwYWxsaSIgPHNhZGRlcGFsbGlAZnJlZXNjYWxlLmNv bT4gd3JvdGU6DQo+DQo+PklmIEkgdGFrZSBhIGNoYWluIHdpdGggNSBzZXJ2aWNlcyB3aXRoIGVh Y2ggc2VydmljZSAgc2F5IGhhdmluZyAyNTYNCj4+aW5zdGFuY2VzIGZvciBzY2FsZS1vdXQsIHBv c3NpYmxlIG51bWJlciBvZiBwYXRocyBhcmUNCj4+MjU2KjI1NioyNTYqMjU2KjI1NiA9IDB4RkYg RkYgRkYgRkYgRkYuIE9uZSByZXF1aXJlcyAzMyBiaXRzIGluIHRoaXMNCj4+Y2FzZS4gIElmIHRo ZXJlIGFyZSBtb3JlIHNlcnZpY2VzIGluIHRoZSBjaGFpbiBvciBtb3JlIGNoYWlucyBvciBtb3Jl DQo+Pmluc3RhbmNlcyBmb3Igc2NhbGUtb3V0LCB0aGVuIGl0IGNvdWxkIGdvIHRvIGJpZyBudW1i ZXIgdmVyeSBmYXN0Lg0KPj4NCj4+QXMgSSBtZW50aW9uZWQgbXkgcHJlZmVyZW5jZSBpcyB0byBt YWtlIHRoZSBwYXRoIElEIHNpemUgZmxleGlibGUgZm9yDQo+PmZ1dHVyZSBncm93dGguIElmIHRo YXQgaXMgcGVyY2VpdmVkIGFzIGNvbXBsZXgsIHRoZW4gZ29pbmcgZm9yIDY0Yml0DQo+PmlzIHNh ZmVyIGJldC4NCj4+DQo+PlRoYW5rcw0KPj5TcmluaQ0KPj4NCj4+DQo+Pi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PkZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb21dDQo+PlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwNCwgMjAxNCAxMjowNSBQTQ0K Pj5UbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgSm9lbCBNLiBIYWxwZXJuOyBzZmNAaWV0Zi5v cmcNCj4+Q2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+PlN1YmplY3Q6IFJlOiBbc2Zj XSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4NCj4+QSBjb250cm9sbGVyIChvciBvdGhlciBkZWNp c2lvbiBsb2dpYykgY2FuIGNlcnRhaW5seSBiZSBhd2FyZSBvZiBzdWNoDQo+PmNvbmNlcm5zLg0K Pj5CdXQgdGhlIG51bWJlciBvZiBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIGlzIG5vdCByZWxhdGVk IHRvIHRoZSBudW1iZXINCj4+b2YgZmxvd3Mgb3IgdGhlIG51bWJlciBvZiB0ZW5hbnRzLiAgSXQg aXMgcmVsYXRlZCB0byB0aGUgbnVtYmVyIG9mDQo+PmNvbWJpbmF0aW9ucyBvZiBzZXJ2aWNlcyBh bmQgdGhlIHBvbGljaWVzIGZvciBzZXJ2aWNlIGZ1bmN0aW9uIHNlbGVjdGlvbi4NCj4+IFdoaWxl IHRoYXQgY2FuIGJlIGEgbGFyZ2UgbnVtYmVyLCBJIHN1cmUgaG9wZSBpdCBkb2VzIG5vdCBjb21l IGNsb3NlDQo+PnRvIHNhdHVyYXRpbmcgMjQgYml0cy4NCj4+DQo+PkhhdmluZyBzYWlkIHRoYXQs IGlmIHdlIHRoaW5rIHRoYXQgMjQgYml0cyBpcyBvbmx5IGp1c3QgZW5vdWdoLCB0aGVuDQo+Pndl IG91Z2h0IHRvIHVzZSAzMi4gIEZyb20gd2hlcmUgSSBzaXQsIEkgd291bGQgbm9ybWFsbHkgZXhw ZWN0IDE2IGJpdHMNCj4+dG8gYmUgbW9yZSB0aGFuIHN1ZmZpY2llbnQsIHdoaWNoIGlzIHdoeSBJ IGFtIGNvbWZvcnRhYmxlIHdpdGggMjQuDQo+PkhhdmluZyBzYWlkIHRoYXQsIHRoZSBmaWVsZCBz aXplIGlzIG5vdCBhIGJpZyBkZWFsIHRvIG1lLg0KPj4NCj4+WW91cnMsDQo+PkpvZWwNCj4+DQo+ Pk9uIDEyLzQvMTQsIDI6MDEgUE0sIFNyaW5pIEFkZGVwYWxsaSB3cm90ZToNCj4+Pg0KPj4+IEkg d2FzIG5vdCBpbXBseWluZyB0aGF0IHBhdGggSUQgc2hvdWxkIGhhdmUgaW5mb3JtYXRpb24gaW4g cmVnYXJkcw0KPj4+dG8gdGVuYW50L2NvbnRyb2xsZXIvZmxvdy9zY2FsZS1vdXQuICBCdXQgU0ZD IGNvbnRyb2xsZXJzIHNob3VsZCBrZWVwIHRoZXNlDQo+Pj5pbiBtaW5kIHRvIGFzc2lnbiB0aGUg cGF0aCBJRC4gICAgQSBkZXBsb3ltZW50IGNhbiBoYXZlIG11bHRpcGxlDQo+Pj50ZW5hbnRzLCBl YWNoIHRlbmFudCBjYW4gaGF2ZSBtdWx0aXBsZSBuZXR3b3JrcywgIHRoZXJlIGNvdWxkIGJlDQo+ Pj5taWxsaW9ucyBvZiBmbG93cyBpbiBlYWNoIG9mIHRob3NlIG5ldHdvcmtzLiAgQW5kIGNvbnNp ZGVyaW5nIGFsbA0KPj4+dGhlc2UsDQo+Pj4gMjQgYml0IHBhdGggSUQgbWF5IG5vdCBiZSBhYmxl IHRvIHJlcHJlc2VudCBwYXRocyBmb3IgdGhlc2UgZmxvd3MuDQo+Pj5IZW5jZSwgSSB3YXMgd29u ZGVyaW5nIHdoZXRoZXIgcGF0aCBJRCBjYW4gYmUgZXh0ZW5kZWQgdG8gNjQgYml0cyBvcg0KPj4+ bWFrZSBpdCBmbGV4aWJsZS4NCj4+Pg0KPj4+IFRoYW5rcw0KPj4+IFNyaW5pDQo+Pj4NCj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gRnJvbTogSm9lbCBN LiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4+IFNlbnQ6IFRodXJzZGF5LCBEZWNl bWJlciA0LCAyMDE0IDc6NDIgQU0NCj4+PiBUbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgc2Zj QGlldGYub3JnDQo+Pj4gQ2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj4gU3ViamVj dDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4+IChodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+Pg0KPj4+IFRoZSBJbmRleCBp cyBub3QganVzdCBmb3IgbG9vcCBwcmV2ZW50aW9uLiAgSW4gdGhlIGNhc2Ugb2YNCj4+PiBhbWJp Z3VpdHksIHRoZSBpbmRleCB0ZWxscyB0aGUgU0ZGIHdoZXJlIGluIHRoZSBwYXRoIHRoZSBwYWNr ZXQgY3VycmVudGx5IHJlc2lkZXMuDQo+Pj4gICAgVGhlcmUgYXJlIG11bHRpcGxlIHdheXMgc3Vj aCBhbWJpZ3VpdHkgY2FuIG9jY3VyLg0KPj4+DQo+Pj4gVGhlIFBhdGggSWRlbnRpZmllciBpcyBz cGVjaWZpY2FsbHkgbm90IGV4cGVjdGVkIHRvIGluY2x1ZGUNCj4+PiBjb250cm9sbGVyIElEIG9y IFRlbmFudCBJRC4gIFdoaWxlIGEgZGVwbG95ZXIgY2FuIGhhdmUgYSBwYXRoIHBlcg0KPj4+IHRl bmFudCwgdGhlIGFyY2hpdGVjdHVyZSBzdGlsbCBkb2VzIG5vdCB0cmVhdCB0aGUgcGF0aCBJRCBh cyBhDQo+Pj4gdGVuYW50IElELiAgVGVuYW50IElELCBjb250cm9sbGVyIElELCBhbmQgb3RoZXIg bm9uLXBhdGgtc3BlY2lmeWluZw0KPj4+IGluZm9ybWF0aW9uIGlzIHRvIGJlIGNhcnJpZWQgaW4g bWV0YWRhdGEuDQo+Pj4NCj4+PiBZb3VycywNCj4+PiBKb2VsDQo+Pj4NCj4+PiBPbiAxMi80LzE0 LCAxMDowMiBBTSwgU3JpbmkgQWRkZXBhbGxpIHdyb3RlOg0KPj4+PiBUd28gY29tbWVudHMgOg0K Pj4+Pg0KPj4+Pg0KPj4+PiAxLiAgU0YgSW5kZXggOiAgU2luY2UgaXQgaXMgbWVhbnQgZm9yIGxv b3AgZGV0ZWN0aW9uLCAgd291bGRuJ3QNCj4+Pj4gYmV0dGVyIHRvIHJlbmFtZSB0aGlzIGFzICJU VEwiPw0KPj4+Pg0KPj4+PiAyLiAgUGF0aCBJZGVudGlmaWVyIDogICAgMjQgYml0IHBhdGggaWRl bnRpZmllciBzZWVtcyB0byBiZSB0b28gbGVzcy4NCj4+Pj4gQmFzZWQgb24gb3VyIGV4cGVyaWVu Y2UgaW4gdHJhZmZpYyBzdGVlcmluZywgIHRoaXMgcGF0aCBpZGVudGlmaWVyDQo+Pj4+bmVlZHMg dG8gZW5jb2RlIGdvb2QgYW1vdW50IG9mIGluZm9ybWF0aW9uIHRvIG1ha2UgaXQgdW5pcXVlLiAg Rm9yDQo+Pj4+ZXhhbXBsZSwNCj4+Pj4gICAgdGhpcyBpZGVudGlmaWVyIG5lZWRzIHRvIGVuY29k ZSAoaW4gb3VyIGNhc2UpIHNvbWUgaW5mb3JtYXRpb24NCj4+Pj5yZXByZXNlbnRpbmcgdGhlIGRp c3RyaWJ1dGVkIGNvbnRyb2xsZXIgSUQsICB0ZW5hbnQgSUQsICBmbG93IElELA0KPj4+PiAgICBT ZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlIChpbiBjYXNlIG9mIHNjYWxlLW91dCkgYW5kIGZldyBt b3JlLi4NCj4+Pj4gT25lIHN1Z2dlc3Rpb24gaXMgdG8gbWFrZSBpdCA2NCBiaXRzIHZhbHVlICBv ciB0byBtYWtlIGl0IGV2ZW4NCj4+Pj5leHRlbmRhYmxlLA0KPj4+PiAgICBpdCBpcyBnb29kIGlm IHBhdGggaWRlbnRpZmllciBpcyBhbHNvIHJlcHJlc2VudGVkIGluIFRMViBmb3JtLg0KPj4+Pg0K Pj4+Pg0KPj4+PiBUaGFua3MNCj4+Pj4NCj4+Pj4gU3JpbmkNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+ Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4NCj4+DQo+Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PnNmYyBtYWlsaW5nIGxpc3QN Cj4+c2ZjQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGFu eSBhdHRhY2htZW50cyAodGhlICJtZXNzYWdlIikgYXJlIGNvbmZpZGVudGlhbCwgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgYWRkcmVzc2Vlcy4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBmcm9tIHlvdXIgc3lzdGVtLiBJbiB0aGlzIGNhc2UsIHlv dSBhcmUgbm90IGF1dGhvcml6ZWQgdG8gdXNlLCBjb3B5IHRoaXMgbWVzc2FnZSBhbmQvb3IgZGlz Y2xvc2UgdGhlIGNvbnRlbnQgdG8gYW55IG90aGVyIHBlcnNvbi4gRS1tYWlscyBhcmUgc3VzY2Vw dGlibGUgdG8gYWx0ZXJhdGlvbi4gTmVpdGhlciBRb3Ntb3Mgbm9yIGFueSBvZiBpdHMgc3Vic2lk aWFyaWVzIG9yIGFmZmlsaWF0ZXMgc2hhbGwgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBpZiBh bHRlcmVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KQ2UgbWVzc2FnZSBldCB0b3V0ZXMgc2Vz IHBpw6hjZXMgam9pbnRlcyAoY2ktYXByw6hzIGxlICJtZXNzYWdlIilzb250IGNvbmZpZGVudGll bHMgZXQgw6l0YWJsaXMgw6AgbCdpbnRlbnRpb24gZXhjbHVzaXZlIGRlIHNlcyBkZXN0aW5hdGFp cmVzLiBTaSB2b3VzIGF2ZXogcmXDp3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCBtZXJjaSBk4oCZ ZW4gaW5mb3JtZXIgaW1tw6lkaWF0ZW1lbnQgc29uIMOpbWV0dGV1ciBwYXIgY291cnJpZXIgw6ls ZWN0cm9uaXF1ZSBldCBk4oCZZWZmYWNlciBjZSBtZXNzYWdlIGRlIHZvdHJlIHN5c3TDqG1lLiBE YW5zIGNldHRlIGh5cG90aMOoc2UsIHZvdXMgbuKAmcOqdGVzIHBhcyBhdXRvcmlzw6kgw6AgdXRp bGlzZXIsIGNvcGllciBjZSBtZXNzYWdlIGV0L291IGVuIGRpdnVsZ3VlciBsZSBjb250ZW51IMOg IHVuIHRpZXJzLiBUb3V0IG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBlc3Qgc3VzY2VwdGlibGUgZCdh bHTDqXJhdGlvbi4gUW9zbW9zIGV0IHNlcyBmaWxpYWxlcyBkw6ljbGluZW50IHRvdXRlIHJlc3Bv bnNhYmlsaXTDqSBhdSB0aXRyZSBkZSBjZSBtZXNzYWdlIHMnaWwgYSDDqXTDqSBhbHTDqXLDqSwg ZMOpZm9ybcOpIG91IGZhbHNpZmnDqS4NCg== From nobody Fri Jan 30 14:05:25 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D4E1A7D84; Fri, 30 Jan 2015 14:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id II7ftFdbqCP5; Fri, 30 Jan 2015 14:04:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0AD1A0371; Fri, 30 Jan 2015 14:04:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: iesg-secretary@ietf.org, iesg@ietf.org, sfc@ietf.org, sfc-chairs@tools.ietf.org, jmh@joelhalpern.com, draft-ietf-sfc-problem-statement@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150130220413.19728.19101.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 14:04:13 -0800 From: IETF Secretariat Archived-At: Subject: [sfc] Telechat update notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 22:04:48 -0000 Placed on agenda for telechat - 2015-02-19 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Fri Jan 30 14:53:30 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C37F1A8715 for ; Fri, 30 Jan 2015 14:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBjV-rRf5_ht for ; Fri, 30 Jan 2015 14:53:25 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D531A871A for ; Fri, 30 Jan 2015 14:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1422658406; x=1454194406; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SRy0s/NBjK0Xg3z3EjvrsXF2rL2jOhgLqiDnyQG2SKU=; b=JG8lpA4D+9Zz64p7iIKmDRenOc9sHkf/R8o4x0JyIrhZlgvtkMrFrDhI DYEYl8LK2HrTvp6qHCm8gsOyIgyZLhdsR3rybo1Jgs86pIOzBvMUdH9GC T5OJdhqb6tAex9c40WPN+yVpKQ1flR+qGRR2D+sZLSTutjcb2FXWo+hVT Q=; X-IronPort-AV: E=Sophos;i="5.09,494,1418083200"; d="scan'208";a="147373652" X-IPAS-Result: AhoIABgLzFTAqArr/2dsb2JhbABQCoNYWQSCNkfBQiEKhXECHIFCAQEBAQEBfIQMAQEBAQMBAQEJFxEgEQIHCwwEAgEGAhEBAwEBAQICIwMCAgIlCxQBAgYIAgQBDQWIOaNInGyVWAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGIbYUHBykIEBYFBwICAoJigUEFjR6FMWKGDIMDiwKDPYIkHBSBPG8BgUN+AQEB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 30 Jan 2015 22:53:19 +0000 Received: from SEAEXCHMBX01.olympus.F5Net.com (192.168.15.223) by seaexchmbx02.olympus.F5Net.com (192.168.15.224) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 30 Jan 2015 14:53:17 -0800 Received: from SEAEXCHMBX01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75]) by seaexchmbx01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75%13]) with mapi id 15.00.0995.028; Fri, 30 Jan 2015 14:53:18 -0800 From: Sumandra Majee To: Nicolas BOUTHORS , Cathy Zhang , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4ggALqPwCAADaLgA== Date: Fri, 30 Jan 2015 22:53:17 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Jerome TOLLET Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 22:53:29 -0000 SGVsbG8sDQoNClRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiBhbmQgSSB3b3VsZCBs aWtlIHRvIHVuZGVyc3RhbmQgdGhlDQptb3RpdmF0aW9uIG9mIGJldHRlci4gVGhlIHRyb3VibGUg d2l0aCBhIHByb3RvY29sIGRvY3VtZW50IGlzIHRoYXQgaXQgaXMNCnR5cGljYWxseSBoYXMgaW5h ZGVxdWF0ZSBkZXRhaWwgYWJvdXQgdGhlIGxvZ2ljLiBTbyB0byBjYXN0IHRoaXMgaW50bw0Kc29t ZXdoYXQgb2YgYSBjb25jcmV0ZSB0ZXJtcywgY29uc2lkZXIgdGhlIGZvbGxvd2luZy4NCg0KDQog ICAgDQogICAgICAgU0ZGKHgpICB7IFNmeCgxKSBTZngoMinigKZTZngobikgfSAgIOKAlOKAlOKA lOKAlD4gICBTRkYoeSkgeyBTZnkoMSkgU2Z5KDIpDQrigKYuIFNmeShtKSB9ICAgOjogTG9naWNh bCBDaGFpbiBpbiBPTkUgZGlyZWN0aW9uIG9ubHkuDQogICAgICAgDQogICAgICAgUEhZU0lDQUwg V09STEQ6DQogICAgICAgICAgQSkgdGhlIFNGRiBjb3VsZCBiZSBhDQogICAgICAgICAgICAtIGNv bXBvbmVudCBvZiBWU1dJVENIIChwaWNrIHlvdXIgZmF2IHByb3RvY29sIGZvciBjb25maWd1cmlu Zw0KdGhvc2UgZW50aXRpZXMgfQ0KICAgICAgICAgICAgLSBBIGxvYWQgYmFsYW5jZXINCiAgICAg ICAgICAgIC0gQSBIVyBzd2l0Y2gvcm91dGVyIHNvbWUgTDIvTDMgY29tYm8NCg0KICAgICAgICAg IEIpIFNmIGluc3RhbmNlIGNvdWxkIGJlLA0KICAgICAgICAgICAgICAgLSBWaXJ0dWFsIG1hY2hp bmUsICNOIG9mIHRob3NlDQogICAgICAgICAgICAgICAtIHBoeXNpY2FsDQogICAgICAgICAgICAg ICAtIENvbnRhaW5lciAjTSB3aGljaCBpcyBvZnRlbiA1IG9yIG1vcmUgeCAjTg0KICAgICAgICAg ICAgICAgLSBDbHVzdGVyIHRoYXQgd2UgZG9u4oCZdCBrbm93DQoNCkl0IGlzIHBvc3NpYmxlIHRv IGhhdmUgbXVsdGlwbGUgcGh5c2ljYWwgU0ZGKHgpIGFsc28uDQoNCkEgc2VsZWN0aW9uIG9mIGEg Z2l2ZW4gU0YgKHNlcnZpY2UpKGluc3RhbmNlKSBpcyBhIGNhbiBiZSBzaW1wbGUgb3INCmNvbXBs ZXguIEZvciBleGFtcGxlIFNGRih4KSBtYXkgaGF2ZSB0aGUgYmVzdCBrbm93bGVkZ2UgdG8gc2Vs ZWN0IFNmeCgxKQ0KYmFlZCBvbiBhIGdpdmVuIGNyaXRlcmlvbiAod2hpY2ggY291bGQgYmUgcGFy dCBvZiB0aGUgcG9saWN5KS4gIFRoZW4gSQ0KZG9u4oCZdCBzZWUgYSByZWFzb24gdG8gaGF2ZSBS U1AuDQoNCkl0IGlzIHBvc3NpYmxlIHRoYXQgbG9va3VwIChwYXRoKSBAIFNGRih4KSBwcm9kdWNl cyBhIHNwZWNpZmljIGluc3RhbmNlIG9mDQpTZnkgYW5kIHllcyB0aGVuIHNvbWV0aGluZyBsaWtl IFJTUCB3b3VsZCBiZSByZXF1aXJlZC4gQnV0IEkgd291bGQgYXJndWUNCnRoYXQgam9iIFNGRih5 KSBjYW4gYWxzbyBiZSBzdWJzdW1lZCBieSBTRkYoeCkuDQoNCklzIGl0IHBvc3NpYmxlIGZvciBh IGNlbnRyYWwgY29udHJvbGxlciB0byBwaWNrIGVhY2ggaW5zdGFuY2Ugb2Ygc2VydmljZSwNCmJ1 dCBzdWNoIGFuIGltcGxlbWVudGF0aW9uIHRlbmRzIHRvIHNjYWxlIHBvb3JseS4gVGhlIGFtb3Vu dCBvZiBzdGF0ZSwNCnByb2JhYmlsaXR5IG9mIGEgaW5zdGFuY2UgZ29pbmcgZG93biBiZXR3ZWVu IHNlbGVjdGlvbiBhbmQgZmxvdyBhcnJpdmFsDQpnb2VzIHVwLiANCg0KUmVnYXJkcy4NCg0KU3Vt YW5kcmENCg0KDQoNCk9uIDEvMzAvMTUsIDM6MzggQU0sICJOaWNvbGFzIEJPVVRIT1JTIiA8Tmlj b2xhcy5CT1VUSE9SU0Bxb3Ntb3MuY29tPg0Kd3JvdGU6DQoNCj5IZWxsbyBDYXRoeSwNCj4NCj5J bmRlZWQgdGhlIG5vdGlvbiBvZiAicmVuZGVyZWQgc2VydmljZSBwYXRoIElEIihSU1AgSUQpIHNl ZW1zIHJlbGV2YW50IGFzDQo+dGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBzdGlwdWxhdGVzIHRo YXQgdGhlIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKQ0KPnByb3ZpZGVzIGFuIGFic3RyYWN0 IG5vdGlvbiBvZiBhIHNlcnZpY2UgY2hhaW4sIHdoaWxlIHRoZSBSU1AgaXMgYQ0KPmNvbnN0cmFp bmVkIGxpc3Qgb2YgbG9jYXRpb25zLg0KPg0KPlNGQyBoZWFkZXIgIlNlcnZpY2UgUGF0aCBJZGVu dGlmaWVyIiAoU1BJKSAgaXMgdXNlZCBpbiBib3RoIE5TSCBhbmQgU0NIDQo+cHJvdG9jb2wgYW5k IGluIGJvdGggY2FzZSBzZWVtIHRvIGlkZW50aWZ5IHRvIGEgcGFydGljdWxhciBTRlAuDQo+DQo+ TlNIKHY1KSBmb3IgZXhhbXBsZSBzdGF0ZXMgdGhhdA0KPiIgQXMgZGVzY3JpYmVkIGFib3ZlLCBO U0ggY29udGFpbnMgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciAoU1BJKSBhbmQNCj4gICBhIHNl cnZpY2UgaW5kZXggKFNJKS4gIFRoZSBTUEkgaXMsIGFzIHBlciBpdHMgbmFtZSwgYW4gaWRlbnRp Zmllci4NCj4gICBUaGUgU1BJIGFsb25lIGNhbm5vdCBiZSB1c2VkIHRvIGZvcndhcmQgcGFja2V0 cyBhbG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4gICBSYXRoZXIgdGhlIFNQSSBwcm92aWRlIGEgbGV2 ZWwgb2YgaW5kaXJlY3Rpb24gYmV0d2VlbiB0aGUgc2VydmljZQ0KPiAgIHBhdGgvdG9wb2xvZ3kg YW5kIHRoZSB0aGUgbmV0d29yayB0cmFuc3BvcnQuICBGdXJ0aGVybW9yZSwgdGhlcmUgaXMNCj4g ICBubyByZXF1aXJlbWVudCwgb3IgZXhwZWN0YXRpb24gb2YgYW4gU1BJIGJlaW5nIGJvdW5kIHRv IGEgcHJlLQ0KPiAgIGRldGVybWluZWQgb3Igc3RhdGljIG5ldHdvcmsgcGF0aC4iDQo+DQo+U3Rp bGwgTlNIKHY1KSAgc2hvd3MgdGhhdCBTUEkgKG5vdCBhIFJTUCBJRCkgIHNob3VsZCBiZSBwYXJ0 IG9mIHRoZSBrZXkNCj5lbGVtZW50IG9mIGFuIFNGRiB0byBsb29rdXAgb24gZm9yd2FyZGluZyB0 YWJsZXMuICBCdXQgSSBjb3VsZCBub3QgZmluZA0KPmluIE5TSCAgaG93IHRvIHVzZSB0aGUgbm90 aW9uIG9mDQo+UmVuZGVyZWQgc2VydmljZSBwYXRoIHdoaWNoIHdhcyBkZWZpbmVkIGluIHRoZSBh cmNoaXRlY3R1cmUgZG9jdW1lbnQuDQo+DQo+WW91IHByb3Bvc2FsIHNlZW1zIHRvIG1lIHZlcnkg dXNlZnVsLA0KPg0KPkFuIFJTUCBJRCAoaW5kZXBlbmRlbnQgb2YgdGhlIFNQSSBidXQgcGFydCBv ZiB0aGUgc2FtZSBuYW1lIHNwYWNlKSBjb3VsZA0KPmJlIHVzZWQgdGhlIHNhbWUgd2F5IGFzIFNQ SSBieSBTRkYgZm9yIGV4YW1wbGUsIGFsbG93aW5nIGEgU2VydmljZQ0KPkNsYXNzaWZpZXIgdG8g Y29udHJvbCByZW1vdGUgbG9hZCBiYWxhbmNpbmcgZm9yIGV4YW1wbGUuDQo+DQo+VGhpcyBzYWlk IHRoZSBSU1AgSUQgdmFsdWVzIGNvdWxkIGJlIHJlbGF0aXZlIHRvIGEgcGFydGljdWxhciBTZXJ2 aWNlDQo+UGF0aCwgd2hpY2ggd291bGQgcHJldmVudCB1c2luZyB0aGVtIGFzIHdlIGRvIGZvciBT UEkgaW4gU0ZGIGZvcndhcmRpbmcNCj50YWJsZXMuDQo+DQo+V2UgbWF5IHdhbnQgdG8gcHJlY2lz ZSBpZiB0aGUgUlNQIElEIGlzIHRvIGJlIHJlbGF0aXZlIG9mIGFic29sdXRlLCBhcyBpdA0KPnNo b3VsZCBoYXZlIGFuIGltcGFjdCBvbiBmb3J3YXJkaW5nIHRhYmxlIHN0cnVjdHVyZSBpZiB3ZSBk ZWNpZGUgdG8gdXNlDQo+dGhpcyBjb25jZXB0Lg0KPg0KPlBlcnNvbmFsbHkgSSBsaWtlIHRoZSBu b3Rpb24gb2YgYSByZWxhdGl2ZSBSU1AgSUQsIGFzIHdlIGNvdWxkIHRoZW4gdXNlDQo+c29tZSBj b252ZW50aW9ucywgc3RydWN0dXJlIGl0LCBwb3NzaWJseSBleHRlbmRpbmcgaXRzIHVzZS4NCj4N Cj5OaWNvbGFzDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBDYXRoeSBa aGFuZyBbbWFpbHRvOkNhdGh5LkguWmhhbmdAaHVhd2VpLmNvbV0NCj5TZW50OiBqZXVkaSAyOSBq YW52aWVyIDIwMTUgMjA6NDQNCj5UbzogQ2F0aHkgWmhhbmc7IFNyaW5pIEFkZGVwYWxsaTsgUmVp bmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uDQo+SGFscGVybjsgJ3NmY0BpZXRmLm9yZycN Cj5DYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50 cyBvbiBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5n LXNmYy1zY2gtMDIpDQo+DQo+SGkgZXZlcnlvbmUsDQo+DQo+V2UgaGF2ZSB1cGxvYWRlZCBhIG5l dyBTQ0ggdmVyc2lvbiAoMykgd2hpY2ggYWRkcyBkZWZpbml0aW9uIG9mIGEgbmV3DQo+bWV0YWRh dGEgdHlwZSBmb3IgdGhlIGZsb3cgSUQgdG8gc3VwcG9ydCBsb2FkIGJhbGFuY2luZyBhbW9uZyBT Rg0KPmluc3RhbmNlcyBhbmQgbWl0aWdhdGUgdGhlIHBvdGVudGlhbCBpc3N1ZSBvZiAibm90IGVu b3VnaCBwYXRoIElEIi4gVGhlDQo+ZmxvdyBJRCBpcyBuYW1lZCAicmVuZGVyZWQgc2VydmljZSBw YXRoIElEIiBpbiB0aGUgZHJhZnQuIFBsZWFzZSByZWZlciB0bw0KPnNlY3Rpb24gNC4zLjIgb2Yg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctc2ZjLXNjaC8NCj5m b3IgZGV0YWlsIGRlc2NyaXB0aW9uLg0KPg0KPkluIGl0cyBwcmV2aW91cyB2ZXJzaW9uLCBTQ0gg ZGVmaW5lcyBhICJCeXBhc3MgYml0IiBpbiB0aGUgYmFzZSBoZWFkZXIuDQo+VGhpcyBiaXQgZW5h YmxlcyB0aGUgU0YgdG8gcHJvdmlkZSBmZWVkYmFjay9ub3RpZmljYXRpb24gdmlhIHRoZSBkYXRh DQo+cGF0aCB0byBpdHMgY29ubmVjdGluZyBTRkYgYWJvdXQgd2hldGhlciB0aGUgcmVtYWluaW5n IHBhY2tldHMgb2YgdGhlIFNGQw0KPnNob3VsZCBieXBhc3MgdGhhdCBTRi4gVGhpcyBpcyB1c2Vm dWwgaW4gdGhlIGNhc2UgdGhhdCBvbmx5IHRoZSBmaXJzdCBmZXcNCj5wYWNrZXRzIG9mIGEgZmxv dyBuZWVkIHRvIGdvIHRvIGEgU0YgKHN1Y2ggYXMgYSBEUEkgb3IgRlcgb3IgSURTKSBhbmQNCj5y ZW1haW5pbmcgcGFja2V0cyBjYW4gYnlwYXNzIHRoYXQgU0YsIHRodXMgc2F2aW5nIHRoZSBleHBl bnNpdmUgU0YNCj5yZXNvdXJjZSBhbmQgcmVkdWNpbmcgZGF0YSBwYXRoIGxhdGVuY3kuDQo+DQo+ QiBiaXQ6IFRoZSBCIChCeXBhc3MpIGJpdCwgd2hlbiBzZXQgdG8gMSwgaXQgaXMgdXNlZCBieSBh IFNlcnZpY2UNCj4gICAgICAgRnVuY3Rpb24gdG8gc2lnbmFsIHRvIGl0cyBTZXJ2aWNlIEZ1bmN0 aW9uIEZvcndhcmRlciB0aGF0IG5vDQo+ICAgICAgIGZ1cnRoZXIgcGFja2V0cyBhcmUgdG8gYmUg c2VudCB0byBpdCBmb3IgdGhlIGZsb3cgc3BlY2lmaWVkIGluDQo+ZW5jYXBzdWxhdGVkIHBhY2tl dC4NCj4NCj5JbiBhZGRpdGlvbiwgU0NIIGRlZmluZXMgYSBtZXRhZGF0YSB0eXBlIGZvciBHZW5l cmljIENvbnRleHQgQmxvY2ssIHdoaWNoDQo+aXMgb3B0aW9uYWwgYW5kIGNhbiBiZSB1c2VkIGlm IG5lZWRlZCB0byBjYXJyeSBhbnkgdmVuZG9yJ3Mgc3BlY2lmaWMNCj4iQ29udGV4dCBIZWFkZXIi Lg0KPg0KPkFueSBjb21tZW50cyBvbiB0aGVzZSBuZXcgYWRkaXRpb25zPw0KPg0KPlRoYW5rcywN Cj5DYXRoeQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXRoeSBaaGFuZw0KPlNlbnQ6 IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgMTE6NDcgQU0NCj5UbzogU3JpbmkgQWRkZXBhbGxp OyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4gSGFscGVybjsNCj4nc2ZjQGlldGYu b3JnJw0KPkNjOiBuc211cnRoeUBmcmVlc2NhbGUuY29tDQo+U3ViamVjdDogUmU6IFtzZmNdIENv bW1lbnRzIG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt emhhbmctc2ZjLXNjaC0wMikNCj4NCj5Sb24sIExvdWlzLCBNeW8gYW5kIEkgaGF2ZSBiZWVuIGRp c2N1c3Npbmcgb2ZmIGxpbmUgbGFzdCBmZXcgd2Vla3MgYWJvdXQNCj5kZWZpbmluZyBhIG1ldGFk YXRhIHR5cGUgZm9yIGZsb3cgSUQgaW4gYWRkaXRpb24gdG8gdGhlIHBhdGggSUQgb2YgdGhlDQo+ bWFpbiBoZWFkZXIgdG8gc3VwcG9ydCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRiBpbnN0YW5jZXMu IFdlIHdpbGwgZGVmaW5lDQo+YSBUTFYgdHlwZSBmb3IgdGhlIGZsb3cgSUQuIFRoZSBjb21iaW5h dGlvbiBvZiAicGF0aCBJRCArIGZsb3cgSUQiDQo+c3BlY2lmaWVzIGEgcmVhbGl6ZWQgc2Vydmlj ZSBjaGFpbiBpbnN0YW5jZSBwYXRoLiBJdCBpcyBsZWZ0IHRvIHRoZQ0KPmRlc2lnbi9pbXBsZW1l bnRhdGlvbiB3aGV0aGVyIHRvIHVzZSBhIGNlbnRyYWxpemVkIG1ldGhvZCBvciBhDQo+ZGlzdHJp YnV0ZWQgbWV0aG9kIHRvIGJpbmQgdGhlIGZsb3cgSUQgdG8gYSByZWFsaXplZCBzZXJ2aWNlIGlu c3RhbmNlDQo+cGF0aCBhbHRob3VnaCBvdXIgb3JpZ2luYWwgdGhvdWdodCBpcyBmb3IgZGlzdHJp YnV0ZWQgTEIgdXNhZ2UuIEkgYW0gbm90DQo+c3VyZSBpZiB3ZSBuZWVkIGEgYml0IGluIHRoZSBo ZWFkZXIgdG8gZGVub3RlIHdoZXRoZXIgdGhlcmUgYXJlIG1vcmUgcGF0aA0KPklEIGJpdHMgKHdl IGNhbGwgaXQgZmxvdyBJRCkgaW4gdGhlIG1ldGFkYXRhIGZpZWxkcyBzaW5jZSB3aGVuIHlvdSBw YXJzZQ0KPnRoZSBUTFYgbWV0YWRhdGEsIHlvdSB3aWxsIGtub3cgd2hldGhlciB0aGVyZSBhcmUg ZmxvdyBJRCBiaXRzIG9yIG5vdC4NCj5Ob3RlIHRoYXQgaWYgbXVsdGlwbGUgc2Vzc2lvbnMgc2hh cmUgdGhlIHNhbWUgcmVhbGl6ZWQgc2VydmljZSBpbnN0YW5jZQ0KPnBhdGgsIHRoZXkgd2lsbCBz aGFyZSB0aGUgc2FtZSAicGF0aCBJRCsgZmxvdyBJRCIuICBXZSBjYW4gYWxzbyBjb25zaWRlcg0K PmV4dGVuZGluZyB0aGUgbnVtYmVyIG9mIGJpdHMgdG8gMzIgaWYgdGhhdCBpcyB0aGUgY29uc2Vu c3VzLiBXZSB3aWxsIHBvc3QNCj5hbiB1cGRhdGVkIGRyYWZ0IGRlc2NyaWJpbmcgdGhlc2Ugc29v bi4NCj4NCj5UaGFua3MsDQo+Q2F0aHkNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3Jp bmkgQWRkZXBhbGxpDQo+U2VudDogRnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCA3OjE3IEFNDQo+ VG86IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgSm9lbCBNLiBIYWxwZXJuOyAnc2ZjQGlldGYu b3JnJw0KPkNjOiBuc211cnRoeUBmcmVlc2NhbGUuY29tDQo+U3ViamVjdDogUmU6IFtzZmNdIENv bW1lbnRzIG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt emhhbmctc2ZjLXNjaC0wMikNCj4NCj4NCj5bUlBdIERhdGEgcGxhbmUgZWZmaWNpZW5jeS4NCj4N Cj5TUklOST4gSSBhbSBub3Qgc28gc3VyZSBhYm91dCBkYXRhIHBsYW5lIGVmZmljaWVuY3kuICBN b3N0IG9mIHRoZQ0KPnByb2Nlc3NvcnMgd29yayBnb29kIGlmIHRoZSBudW1iZXIgb2YgYml0cyBh cmUgZWl0aGVyIDMyIG9yIDY0LiAgSWYgaXQgaXMNCj4yNCBiaXRzLCB0aGVuIG9uZSBuZWVkcyB0 byBkbyBtYXNraW5nIGFuZCBzaGlmdGluZyBiZWZvcmUgdGhlIHZhbHVlIGlzDQo+dXNlZCB0byBk byBhbnkgbG9va3VwLiAgIEJ1dCwgdGhpcyBkaXNjdXNzaW9uIGNhbiBnbyBpbnRvIGRpZmZlcmVu dA0KPmRpcmVjdGlvbiA6LSksIGl0IG1heSBub3QgYmUgZ29vZCB0byBnbyBpbiB0aGF0IGRpcmVj dGlvbi4NCj4NCj5XaGVyZSBkbyB3ZSBkcmF3IHRoZSBsaW5lPyAzMi1iaXRzLCA2NC1iaXRzLA0K PjEyOCBiaXRzPyBJIHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgc2Vuc2libGUgdmFsdWUgaW4gdGhl IFNlcnZpY2UgUGF0aA0KPmhlYWRlciBhbmQgaWYgeW91IG5lZWQgdG8gY29udmV5IG1vcmUgYml0 cyB5b3UgbmVlZCB0byB1c2UgdGhlIGNvbnRleHQNCj5oZWFkZXJzLg0KPg0KPlNSSU5JPiBUaGlz IGlzIGEgZ29vZCBwb2ludC4gIFRoaXMgc2hvdWxkIHdvcmsgZmluZSBhcyBsb25nIGFzIHRoZXJl IGlzDQo+d2F5IHRvIGNvbnZleSBpbiB0aGUgbWFpbiBoZWFkZXIgdGhhdCB0aGUgZXh0ZW5zaW9u IHRvIHBhdGggSUQgaXMNCj5hdmFpbGFibGUgaW4gc28gYW5kIHNvIFRMViBmaWVsZC4gIFRoYXQg c2hvdWxkIHdvcmsgdG9vLg0KPg0KPlRoYW5rcw0KPlNyaW5pDQo+DQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPkZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5v KSA8cmVwZW5ub0BjaXNjby5jb20+DQo+U2VudDogRnJpZGF5LCBEZWNlbWJlciA1LCAyMDE0IDc6 MDggQU0NCj5UbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgSm9lbCBNLiBIYWxwZXJuOyAnc2Zj QGlldGYub3JnJw0KPkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPlN1YmplY3Q6IFJl OiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+DQo+T24gMTIvNS8xNCwgNjo1NCBBTSwgIlNy aW5pIEFkZGVwYWxsaSIgPHNhZGRlcGFsbGlAZnJlZXNjYWxlLmNvbT4gd3JvdGU6DQo+DQo+Pg0K Pj5JbiByZWFsIGRlcGxveW1lbnRzLCBudW1iZXIgb2YgYWN0aXZlIHBhdGggSURzIGFyZSB2ZXJ5 IGxlc3NlciB0aGFuDQo+PjJeNjQsIGJ1dCB0aGVyZSBpcyBhIGdvb2QgcG9zc2liaWxpdHkgb2Yg dGhlIG51bWJlciBiZWluZyBtb3JlIHRoYW4gMl4yNA0KPj4oMTZNKS4NCj4+IEkgdGhpbmsgYmln Z2VyIHBvaW50IGlzIHRoYXQgd2h5IHJlc3RyaWN0IHRoaXMgaW4gdGhlIHN0YW5kYXJkcz8gV2hh dA0KPj5hZHZhbnRhZ2UgZG8gd2UgaGF2ZSByZXN0cmljdGluZyB0aGlzIHNpemUgdG8gMjQgYml0 cz8NCj4NCj5bUlBdIERhdGEgcGxhbmUgZWZmaWNpZW5jeS4gV2hlcmUgZG8gd2UgZHJhdyB0aGUg bGluZT8gMzItYml0cywgNjQtYml0cywNCj4xMjggYml0cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2 ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGgNCj5oZWFkZXIgYW5kIGlmIHlv dSBuZWVkIHRvIGNvbnZleSBtb3JlIGJpdHMgeW91IG5lZWQgdG8gdXNlIHRoZSBjb250ZXh0DQo+ aGVhZGVycy4NCj4NCj4NCj4+DQo+PlRoZXJlIGNhbiBiZSBkZXBsb3ltZW50cywgd2hlcmUgU0ZD IGNvbnRyb2xsZXIgKExvZ2ljYWxseSBjZW50cmFsLCBidXQNCj4+ZGlzdHJpYnV0ZWQpICBpdHNl bGYgY2FuIGRvIHRoZSBTRiBpbnN0YW5jZSBzZWxlY3Rpb24gb24gcGVyDQo+PmNvbm5lY3Rpb24v c2Vzc2lvbiBiYXNpcywgdGhlcmVieSBhdm9pZGluZyB0aGUgTEJzIGZvciBzZXJ2aWNlcy4gICBJ biBteQ0KPj52aWV3LCBhc3N1bXB0aW9uIHRoYXQgdGhlcmUgd2lsbCBiZSBMQiBTRiBmb3IgZWFj aCBzY2FsZS1vdXQgc2VydmljZSBpbg0KPj50aGUgY2hhaW4gaXMgbm90IHZhbGlkIGluIGFsbCBj YXNlcy4NCj4+DQo+PlRoYW5rcw0KPj5TcmluaQ0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj5Gcm9tOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykgPHJl cGVubm9AY2lzY28uY29tPg0KPj5TZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNCwgMjAxNCAxOjE3 IFBNDQo+PlRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47IHNmY0Bp ZXRmLm9yZw0KPj5DYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj4+U3ViamVjdDogUmU6 IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pg0KPj5JZiBJIHVuZGVyc3Rvb2QgeW91LCBJ IGRvIG5vdCB0aGluayB0aGlzIGlzIHJlYWxpc3RpYy4gQXJlIHlvdSBzYXlpbmcNCj4+eW91IG5l ZWQgNjQtYml0cyBvZiBwYXRocyBhbmQgdGhlbiB3aWxsIG1vbml0b3IgdGhlbSBhbGw/IERvIGZh dWx0DQo+PnRvbGVyYW5jZSBhbmQgT0FNIGZvciAyXjY0LWJpdHMgd29ydGggb2YgcGF0aHM/IEp1 c3QgZm9yIGNvbXBhcmlzb24sDQo+Pml0wrlzIGxpa2UgbWFuYWdpbmcgYW5kIG1vbml0b3Jpbmcg dGhlIGVudGlyZSBJUHY2IGhvc3QgcmFuZ2UsIG9uZS1ieS1vbmUuDQo+Pg0KPj5Bbnl3YXksIEkg ZG8gbm90IGV4cGVjdCBldmVyeSBzaW5nbGUgcGVybXV0YXRpb25zIHRvIGJlIGEgZGlmZmVyZW50 IHBhdGguDQo+Pg0KPj5JZiBlYWNoIHNlcnZpY2UgaGFzIDI1NiBkZXZpY2VzIHByb3ZpZGluZyBz aW1pbGFyIHNlcnZpY2UsIHlvdSBzaG91bGQNCj4+bW9zdCBsaWtlbHkgdXNlIGxvYWQtYmFsYW5j aW5nIGFuZCB0aGVuIHlvdSB3b3VsZCBoYXZlIGEgc2luZ2xlIChvciBhDQo+PmZldykgcGF0aHMu IFRoZXJlIGlzIHNvbWUgZGlzY3Vzc2lvbiBnb2luZyBvbiBMQi4NCj4+DQo+PkZyb20gYSBkYXRh IHBsYW5lIHBlcnNwZWN0aXZlLCB0aGUgcGF0aCBpcyB1bHRpbWF0ZWx5IGRlZmluZWQgYnkgdGhl DQo+PlNGRnMgdHJhdmVyc2VkIGFuZCBzZXJ2aWNlcyBwcm92aWRlZCwgbm90IGJ5IGEgc3BlY2lm aWMgSVA6cG9ydCB0aGF0DQo+PnRoZSBkZXZpY2UgcHJvdmlkaW5nIHRoZSBzZXJ2aWNlIHNpdHMg b24uIFdlbGwsIGF0IGxlYXN0IGZyb20gYSBHUEUrTlNIDQo+PnBlcnNwZWN0aXZlLg0KPj4NCj4+ DQo+Pk9uIDEyLzQvMTQsIDEyOjU3IFBNLCAiU3JpbmkgQWRkZXBhbGxpIiA8c2FkZGVwYWxsaUBm cmVlc2NhbGUuY29tPiB3cm90ZToNCj4+DQo+Pj5JZiBJIHRha2UgYSBjaGFpbiB3aXRoIDUgc2Vy dmljZXMgd2l0aCBlYWNoIHNlcnZpY2UgIHNheSBoYXZpbmcgMjU2DQo+Pj5pbnN0YW5jZXMgZm9y IHNjYWxlLW91dCwgcG9zc2libGUgbnVtYmVyIG9mIHBhdGhzIGFyZQ0KPj4+MjU2KjI1NioyNTYq MjU2KjI1NiA9IDB4RkYgRkYgRkYgRkYgRkYuIE9uZSByZXF1aXJlcyAzMyBiaXRzIGluIHRoaXMN Cj4+PmNhc2UuICBJZiB0aGVyZSBhcmUgbW9yZSBzZXJ2aWNlcyBpbiB0aGUgY2hhaW4gb3IgbW9y ZSBjaGFpbnMgb3IgbW9yZQ0KPj4+aW5zdGFuY2VzIGZvciBzY2FsZS1vdXQsIHRoZW4gaXQgY291 bGQgZ28gdG8gYmlnIG51bWJlciB2ZXJ5IGZhc3QuDQo+Pj4NCj4+PkFzIEkgbWVudGlvbmVkIG15 IHByZWZlcmVuY2UgaXMgdG8gbWFrZSB0aGUgcGF0aCBJRCBzaXplIGZsZXhpYmxlIGZvcg0KPj4+ ZnV0dXJlIGdyb3d0aC4gSWYgdGhhdCBpcyBwZXJjZWl2ZWQgYXMgY29tcGxleCwgdGhlbiBnb2lu ZyBmb3IgNjRiaXQNCj4+PmlzIHNhZmVyIGJldC4NCj4+Pg0KPj4+VGhhbmtzDQo+Pj5TcmluaQ0K Pj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBKb2VsIE0u IEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPj4+U2VudDogVGh1cnNkYXks IERlY2VtYmVyIDA0LCAyMDE0IDEyOjA1IFBNDQo+Pj5UbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2 MDsgSm9lbCBNLiBIYWxwZXJuOyBzZmNAaWV0Zi5vcmcNCj4+PkNjOiBOUyBTcmluaXZhc2EgTXVy dGh5LUIzNzg0MA0KPj4+U3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0K Pj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0K Pj4+DQo+Pj5BIGNvbnRyb2xsZXIgKG9yIG90aGVyIGRlY2lzaW9uIGxvZ2ljKSBjYW4gY2VydGFp bmx5IGJlIGF3YXJlIG9mIHN1Y2gNCj4+PmNvbmNlcm5zLg0KPj4+QnV0IHRoZSBudW1iZXIgb2Yg c2VydmljZSBmdW5jdGlvbiBwYXRocyBpcyBub3QgcmVsYXRlZCB0byB0aGUgbnVtYmVyDQo+Pj5v ZiBmbG93cyBvciB0aGUgbnVtYmVyIG9mIHRlbmFudHMuICBJdCBpcyByZWxhdGVkIHRvIHRoZSBu dW1iZXIgb2YNCj4+PmNvbWJpbmF0aW9ucyBvZiBzZXJ2aWNlcyBhbmQgdGhlIHBvbGljaWVzIGZv ciBzZXJ2aWNlIGZ1bmN0aW9uDQo+Pj5zZWxlY3Rpb24uDQo+Pj4gV2hpbGUgdGhhdCBjYW4gYmUg YSBsYXJnZSBudW1iZXIsIEkgc3VyZSBob3BlIGl0IGRvZXMgbm90IGNvbWUgY2xvc2UNCj4+PnRv IHNhdHVyYXRpbmcgMjQgYml0cy4NCj4+Pg0KPj4+SGF2aW5nIHNhaWQgdGhhdCwgaWYgd2UgdGhp bmsgdGhhdCAyNCBiaXRzIGlzIG9ubHkganVzdCBlbm91Z2gsIHRoZW4NCj4+PndlIG91Z2h0IHRv IHVzZSAzMi4gIEZyb20gd2hlcmUgSSBzaXQsIEkgd291bGQgbm9ybWFsbHkgZXhwZWN0IDE2IGJp dHMNCj4+PnRvIGJlIG1vcmUgdGhhbiBzdWZmaWNpZW50LCB3aGljaCBpcyB3aHkgSSBhbSBjb21m b3J0YWJsZSB3aXRoIDI0Lg0KPj4+SGF2aW5nIHNhaWQgdGhhdCwgdGhlIGZpZWxkIHNpemUgaXMg bm90IGEgYmlnIGRlYWwgdG8gbWUuDQo+Pj4NCj4+PllvdXJzLA0KPj4+Sm9lbA0KPj4+DQo+Pj5P biAxMi80LzE0LCAyOjAxIFBNLCBTcmluaSBBZGRlcGFsbGkgd3JvdGU6DQo+Pj4+DQo+Pj4+IEkg d2FzIG5vdCBpbXBseWluZyB0aGF0IHBhdGggSUQgc2hvdWxkIGhhdmUgaW5mb3JtYXRpb24gaW4g cmVnYXJkcw0KPj4+PnRvIHRlbmFudC9jb250cm9sbGVyL2Zsb3cvc2NhbGUtb3V0LiAgQnV0IFNG QyBjb250cm9sbGVycyBzaG91bGQga2VlcA0KPj4+PnRoZXNlDQo+Pj4+aW4gbWluZCB0byBhc3Np Z24gdGhlIHBhdGggSUQuICAgIEEgZGVwbG95bWVudCBjYW4gaGF2ZSBtdWx0aXBsZQ0KPj4+PnRl bmFudHMsIGVhY2ggdGVuYW50IGNhbiBoYXZlIG11bHRpcGxlIG5ldHdvcmtzLCAgdGhlcmUgY291 bGQgYmUNCj4+Pj5taWxsaW9ucyBvZiBmbG93cyBpbiBlYWNoIG9mIHRob3NlIG5ldHdvcmtzLiAg QW5kIGNvbnNpZGVyaW5nIGFsbA0KPj4+PnRoZXNlLA0KPj4+PiAyNCBiaXQgcGF0aCBJRCBtYXkg bm90IGJlIGFibGUgdG8gcmVwcmVzZW50IHBhdGhzIGZvciB0aGVzZSBmbG93cy4NCj4+Pj5IZW5j ZSwgSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIgcGF0aCBJRCBjYW4gYmUgZXh0ZW5kZWQgdG8gNjQg Yml0cyBvcg0KPj4+Pm1ha2UgaXQgZmxleGlibGUuDQo+Pj4+DQo+Pj4+IFRoYW5rcw0KPj4+PiBT cmluaQ0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+IEZyb206IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+Pj4g U2VudDogVGh1cnNkYXksIERlY2VtYmVyIDQsIDIwMTQgNzo0MiBBTQ0KPj4+PiBUbzogQWRkZXBh bGxpIFNyaW5pLUIyMjE2MDsgc2ZjQGlldGYub3JnDQo+Pj4+IENjOiBOUyBTcmluaXZhc2EgTXVy dGh5LUIzNzg0MA0KPj4+PiBTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0 DQo+Pj4+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0w MikNCj4+Pj4NCj4+Pj4gVGhlIEluZGV4IGlzIG5vdCBqdXN0IGZvciBsb29wIHByZXZlbnRpb24u ICBJbiB0aGUgY2FzZSBvZg0KPj4+PiBhbWJpZ3VpdHksIHRoZSBpbmRleCB0ZWxscyB0aGUgU0ZG IHdoZXJlIGluIHRoZSBwYXRoIHRoZSBwYWNrZXQNCj4+Pj5jdXJyZW50bHkgcmVzaWRlcy4NCj4+ Pj4gICAgVGhlcmUgYXJlIG11bHRpcGxlIHdheXMgc3VjaCBhbWJpZ3VpdHkgY2FuIG9jY3VyLg0K Pj4+Pg0KPj4+PiBUaGUgUGF0aCBJZGVudGlmaWVyIGlzIHNwZWNpZmljYWxseSBub3QgZXhwZWN0 ZWQgdG8gaW5jbHVkZQ0KPj4+PiBjb250cm9sbGVyIElEIG9yIFRlbmFudCBJRC4gIFdoaWxlIGEg ZGVwbG95ZXIgY2FuIGhhdmUgYSBwYXRoIHBlcg0KPj4+PiB0ZW5hbnQsIHRoZSBhcmNoaXRlY3R1 cmUgc3RpbGwgZG9lcyBub3QgdHJlYXQgdGhlIHBhdGggSUQgYXMgYQ0KPj4+PiB0ZW5hbnQgSUQu ICBUZW5hbnQgSUQsIGNvbnRyb2xsZXIgSUQsIGFuZCBvdGhlciBub24tcGF0aC1zcGVjaWZ5aW5n DQo+Pj4+IGluZm9ybWF0aW9uIGlzIHRvIGJlIGNhcnJpZWQgaW4gbWV0YWRhdGEuDQo+Pj4+DQo+ Pj4+IFlvdXJzLA0KPj4+PiBKb2VsDQo+Pj4+DQo+Pj4+IE9uIDEyLzQvMTQsIDEwOjAyIEFNLCBT cmluaSBBZGRlcGFsbGkgd3JvdGU6DQo+Pj4+PiBUd28gY29tbWVudHMgOg0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+PiAxLiAgU0YgSW5kZXggOiAgU2luY2UgaXQgaXMgbWVhbnQgZm9yIGxvb3AgZGV0ZWN0 aW9uLCAgd291bGRuJ3QNCj4+Pj4+IGJldHRlciB0byByZW5hbWUgdGhpcyBhcyAiVFRMIj8NCj4+ Pj4+DQo+Pj4+PiAyLiAgUGF0aCBJZGVudGlmaWVyIDogICAgMjQgYml0IHBhdGggaWRlbnRpZmll ciBzZWVtcyB0byBiZSB0b28gbGVzcy4NCj4+Pj4+IEJhc2VkIG9uIG91ciBleHBlcmllbmNlIGlu IHRyYWZmaWMgc3RlZXJpbmcsICB0aGlzIHBhdGggaWRlbnRpZmllcg0KPj4+Pj5uZWVkcyB0byBl bmNvZGUgZ29vZCBhbW91bnQgb2YgaW5mb3JtYXRpb24gdG8gbWFrZSBpdCB1bmlxdWUuICBGb3IN Cj4+Pj4+ZXhhbXBsZSwNCj4+Pj4+ICAgIHRoaXMgaWRlbnRpZmllciBuZWVkcyB0byBlbmNvZGUg KGluIG91ciBjYXNlKSBzb21lIGluZm9ybWF0aW9uDQo+Pj4+PnJlcHJlc2VudGluZyB0aGUgZGlz dHJpYnV0ZWQgY29udHJvbGxlciBJRCwgIHRlbmFudCBJRCwgIGZsb3cgSUQsDQo+Pj4+PiAgICBT ZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlIChpbiBjYXNlIG9mIHNjYWxlLW91dCkgYW5kIGZldyBt b3JlLi4NCj4+Pj4+IE9uZSBzdWdnZXN0aW9uIGlzIHRvIG1ha2UgaXQgNjQgYml0cyB2YWx1ZSAg b3IgdG8gbWFrZSBpdCBldmVuDQo+Pj4+PmV4dGVuZGFibGUsDQo+Pj4+PiAgICBpdCBpcyBnb29k IGlmIHBhdGggaWRlbnRpZmllciBpcyBhbHNvIHJlcHJlc2VudGVkIGluIFRMViBmb3JtLg0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MNCj4+Pj4+DQo+Pj4+PiBTcmluaQ0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+PiBzZmNAaWV0Zi5vcmcN Cj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pg0K Pj4+DQo+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+c2ZjIG1haWxpbmcgbGlzdA0KPj4+c2ZjQGlldGYub3JnDQo+Pj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNAaWV0 Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxp bmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+DQo+DQo+VGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgKHRoZSAi bWVzc2FnZSIpIGFyZSBjb25maWRlbnRpYWwsDQo+aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRk cmVzc2Vlcy4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQo+cmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhpcw0K Pm1lc3NhZ2UgZnJvbSB5b3VyIHN5c3RlbS4gSW4gdGhpcyBjYXNlLCB5b3UgYXJlIG5vdCBhdXRo b3JpemVkIHRvIHVzZSwNCj5jb3B5IHRoaXMgbWVzc2FnZSBhbmQvb3IgZGlzY2xvc2UgdGhlIGNv bnRlbnQgdG8gYW55IG90aGVyIHBlcnNvbi4NCj5FLW1haWxzIGFyZSBzdXNjZXB0aWJsZSB0byBh bHRlcmF0aW9uLiBOZWl0aGVyIFFvc21vcyBub3IgYW55IG9mIGl0cw0KPnN1YnNpZGlhcmllcyBv ciBhZmZpbGlhdGVzIHNoYWxsIGJlIGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2UgaWYgYWx0ZXJlZCwN Cj5jaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4NCj5DZSBtZXNzYWdlIGV0IHRvdXRlcyBzZXMgcGnD qGNlcyBqb2ludGVzIChjaS1hcHLDqHMgbGUgIm1lc3NhZ2UiKXNvbnQNCj5jb25maWRlbnRpZWxz IGV0IMOpdGFibGlzIMOgIGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJl cy4gU2kNCj52b3VzIGF2ZXogcmXDp3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCBtZXJjaSBk4oCZ ZW4gaW5mb3JtZXIgaW1tw6lkaWF0ZW1lbnQNCj5zb24gw6ltZXR0ZXVyIHBhciBjb3VycmllciDD qWxlY3Ryb25pcXVlIGV0IGTigJllZmZhY2VyIGNlIG1lc3NhZ2UgZGUgdm90cmUNCj5zeXN0w6ht ZS4gRGFucyBjZXR0ZSBoeXBvdGjDqHNlLCB2b3VzIG7igJnDqnRlcyBwYXMgYXV0b3Jpc8OpIMOg IHV0aWxpc2VyLA0KPmNvcGllciBjZSBtZXNzYWdlIGV0L291IGVuIGRpdnVsZ3VlciBsZSBjb250 ZW51IMOgIHVuIHRpZXJzLiBUb3V0IG1lc3NhZ2UNCj7DqWxlY3Ryb25pcXVlIGVzdCBzdXNjZXB0 aWJsZSBkJ2FsdMOpcmF0aW9uLiBRb3Ntb3MgZXQgc2VzIGZpbGlhbGVzDQo+ZMOpY2xpbmVudCB0 b3V0ZSByZXNwb25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2UgbWVzc2FnZSBzJ2lsIGEgw6l0w6kg YWx0w6lyw6ksDQo+ZMOpZm9ybcOpIG91IGZhbHNpZmnDqS4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNAaWV0 Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= From nobody Sat Jan 31 18:49:12 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D3C1A702D for ; Sat, 31 Jan 2015 18:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xn5DZFdmXdME for ; Sat, 31 Jan 2015 18:49:08 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4A01A702F for ; Sat, 31 Jan 2015 18:49:07 -0800 (PST) Received: from DM2PR0301MB0862.namprd03.prod.outlook.com (25.160.215.148) by DM2PR0301MB1277.namprd03.prod.outlook.com (25.160.221.146) with Microsoft SMTP Server (TLS) id 15.1.75.20; Sun, 1 Feb 2015 02:48:44 +0000 Received: from DM2PR0301MB0862.namprd03.prod.outlook.com ([25.160.215.148]) by DM2PR0301MB0862.namprd03.prod.outlook.com ([25.160.215.148]) with mapi id 15.01.0065.013; Sun, 1 Feb 2015 02:48:44 +0000 From: Srini Addepalli To: Cathy Zhang , "Reinaldo Penno (repenno)" , "Joel M. Halpern" , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/klKAgAA1pTGAABNtAIAADGxAgAAH7ICAASQ+x4AAByMAgAABINiAAEx9AIBWb4+AgANW+EA= Date: Sun, 1 Feb 2015 02:48:43 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com>, <1417792592229.41970@freescale.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.88.168.50] authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1277; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB1277; x-forefront-prvs: 04740D25F1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(479174004)(51704005)(377454003)(164054003)(53754006)(74316001)(92566002)(2900100001)(230783001)(2950100001)(93886004)(77156002)(62966003)(76576001)(54606007)(15975445007)(54356999)(102836002)(50986999)(76176999)(54206007)(19580405001)(33656002)(46102003)(87936001)(2656002)(106116001)(66066001)(86362001)(122556002)(99286002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1277; H:DM2PR0301MB0862.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2015 02:48:43.8445 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB1277 Archived-At: Cc: "nsmurthy@freescale.com" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 02:49:11 -0000 Hi Cathy, I went through RSP section of the document. RSP-ID can be used to represen= t the service function instance whereas "path identifier' can be used to re= present the chain. New RSP-ID avoids overloading path ID with the SFIs. Th= at is good. Was there any specific reason to call this as 'RSP-ID', instead of calling = it as SFI-ID? You have mentioned that RSP-ID as 2 bytes. Could we leave the size be flex= ible instead of limiting the size to 2 bytes? Thanks Srini -----Original Message----- From: Cathy Zhang [mailto:Cathy.H.Zhang@huawei.com]=20 Sent: Thursday, January 29, 2015 11:44 AM To: Cathy Zhang; Addepalli Srini-B22160; Reinaldo Penno (repenno); Joel M. = Halpern; 'sfc@ietf.org' Cc: NS Srinivasa Murthy-B37840 Subject: RE: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) Hi everyone, We have uploaded a new SCH version (3) which adds definition of a new metad= ata type for the flow ID to support load balancing among SF instances and m= itigate the potential issue of "not enough path ID". The flow ID is named "= rendered service path ID" in the draft. Please refer to section 4.3.2 of ht= tps://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ for detail description.= =20 In its previous version, SCH defines a "Bypass bit" in the base header. Thi= s bit enables the SF to provide feedback/notification via the data path to = its connecting SFF about whether the remaining packets of the SFC should by= pass that SF. This is useful in the case that only the first few packets of= a flow need to go to a SF (such as a DPI or FW or IDS) and remaining packe= ts can bypass that SF, thus saving the expensive SF resource and reducing d= ata path latency. =20 B bit: The B (Bypass) bit, when set to 1, it is used by a Service=20 Function to signal to its Service Function Forwarder that no further packets are to be sent to it for the flow specified in encap= sulated packet. In addition, SCH defines a metadata type for Generic Context Block, which i= s optional and can be used if needed to carry any vendor's specific "Contex= t Header".=20 Any comments on these new additions?=20 Thanks, Cathy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang Sent: Friday, December 05, 2014 11:47 AM To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.o= rg' Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) Ron, Louis, Myo and I have been discussing off line last few weeks about de= fining a metadata type for flow ID in addition to the path ID of the main h= eader to support load balancing among SF instances. We will define a TLV ty= pe for the flow ID. The combination of "path ID + flow ID" specifies a real= ized service chain instance path. It is left to the design/implementation w= hether to use a centralized method or a distributed method to bind the flow= ID to a realized service instance path although our original thought is fo= r distributed LB usage. I am not sure if we need a bit in the header to den= ote whether there are more path ID bits (we call it flow ID) in the metadat= a fields since when you parse the TLV metadata, you will know whether there= are flow ID bits or not. Note that if multiple sessions share the same rea= lized service instance path, they will share the same "path ID+ flow ID". = We can also consider extending the number of bits to 32 if that is the cons= ensus. We will post an updated draft describing these soon.=20 Thanks, Cathy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Srini Addepalli Sent: Friday, December 05, 2014 7:17 AM To: Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org' Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) [RP] Data plane efficiency.=20 SRINI> I am not so sure about data plane efficiency. Most of the processor= s work good if the number of bits are either 32 or 64. If it is 24 bits, t= hen one needs to do masking and shifting before the value is used to do any= lookup. But, this discussion can go into different direction :-), it may= not be good to go in that direction. Where do we draw the line? 32-bits, 64-bits, 128 bits? I think we should have a sensible value in the Service Path heade= r and if you need to convey more bits you need to use the context headers. SRINI> This is a good point. This should work fine as long as there is way= to convey in the main header that the extension to path ID is available in= so and so TLV field. That should work too. Thanks Srini ________________________________________ From: Reinaldo Penno (repenno) Sent: Friday, December 5, 2014 7:08 AM To: Addepalli Srini-B22160; Joel M. Halpern; 'sfc@ietf.org' Cc: NS Srinivasa Murthy-B37840 Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) On 12/5/14, 6:54 AM, "Srini Addepalli" wrote: > >In real deployments, number of active path IDs are very lesser than=20 >2^64, but there is a good possibility of the number being more than 2^24 (= 16M). > I think bigger point is that why restrict this in the standards? What=20 >advantage do we have restricting this size to 24 bits? [RP] Data plane efficiency. Where do we draw the line? 32-bits, 64-bits, 128 bits? I think we should have a sensible value in the Service Path heade= r and if you need to convey more bits you need to use the context headers. > >There can be deployments, where SFC controller (Logically central, but >distributed) itself can do the SF instance selection on per >connection/session basis, thereby avoiding the LBs for services. In my >view, assumption that there will be LB SF for each scale-out service in=20 >the chain is not valid in all cases. > >Thanks >Srini > >________________________________________ >From: Reinaldo Penno (repenno) >Sent: Thursday, December 4, 2014 1:17 PM >To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >Cc: NS Srinivasa Murthy-B37840 >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >If I understood you, I do not think this is realistic. Are you saying=20 >you need 64-bits of paths and then will monitor them all? Do fault=20 >tolerance and OAM for 2^64-bits worth of paths? Just for comparison,=20 >it=B9s like managing and monitoring the entire IPv6 host range, one-by-one= . > >Anyway, I do not expect every single permutations to be a different path. > >If each service has 256 devices providing similar service, you should=20 >most likely use load-balancing and then you would have a single (or a=20 >few) paths. There is some discussion going on LB. > >From a data plane perspective, the path is ultimately defined by the=20 >SFFs traversed and services provided, not by a specific IP:port that=20 >the device providing the service sits on. Well, at least from a GPE+NSH pe= rspective. > > >On 12/4/14, 12:57 PM, "Srini Addepalli" wrote: > >>If I take a chain with 5 services with each service say having 256=20 >>instances for scale-out, possible number of paths are=20 >>256*256*256*256*256 =3D 0xFF FF FF FF FF. One requires 33 bits in this=20 >>case. If there are more services in the chain or more chains or more=20 >>instances for scale-out, then it could go to big number very fast. >> >>As I mentioned my preference is to make the path ID size flexible for=20 >>future growth. If that is perceived as complex, then going for 64bit=20 >>is safer bet. >> >>Thanks >>Srini >> >> >>-----Original Message----- >>From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>Sent: Thursday, December 04, 2014 12:05 PM >>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >>Cc: NS Srinivasa Murthy-B37840 >>Subject: Re: [sfc] Comments on SCH Draft >>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >> >>A controller (or other decision logic) can certainly be aware of such=20 >>concerns. >>But the number of service function paths is not related to the number=20 >>of flows or the number of tenants. It is related to the number of=20 >>combinations of services and the policies for service function selection. >> While that can be a large number, I sure hope it does not come close=20 >>to saturating 24 bits. >> >>Having said that, if we think that 24 bits is only just enough, then=20 >>we ought to use 32. From where I sit, I would normally expect 16 bits=20 >>to be more than sufficient, which is why I am comfortable with 24. =20 >>Having said that, the field size is not a big deal to me. >> >>Yours, >>Joel >> >>On 12/4/14, 2:01 PM, Srini Addepalli wrote: >>> >>> I was not implying that path ID should have information in regards=20 >>>to tenant/controller/flow/scale-out. But SFC controllers should keep th= ese >>>in mind to assign the path ID. A deployment can have multiple >>>tenants, each tenant can have multiple networks, there could be=20 >>>millions of flows in each of those networks. And considering all=20 >>>these, >>> 24 bit path ID may not be able to represent paths for these flows. >>>Hence, I was wondering whether path ID can be extended to 64 bits or=20 >>>make it flexible. >>> >>> Thanks >>> Srini >>> >>> ________________________________________ >>> From: Joel M. Halpern >>> Sent: Thursday, December 4, 2014 7:42 AM >>> To: Addepalli Srini-B22160; sfc@ietf.org >>> Cc: NS Srinivasa Murthy-B37840 >>> Subject: Re: [sfc] Comments on SCH Draft >>> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>> >>> The Index is not just for loop prevention. In the case of=20 >>> ambiguity, the index tells the SFF where in the path the packet current= ly resides. >>> There are multiple ways such ambiguity can occur. >>> >>> The Path Identifier is specifically not expected to include=20 >>> controller ID or Tenant ID. While a deployer can have a path per=20 >>> tenant, the architecture still does not treat the path ID as a=20 >>> tenant ID. Tenant ID, controller ID, and other non-path-specifying=20 >>> information is to be carried in metadata. >>> >>> Yours, >>> Joel >>> >>> On 12/4/14, 10:02 AM, Srini Addepalli wrote: >>>> Two comments : >>>> >>>> >>>> 1. SF Index : Since it is meant for loop detection, wouldn't=20 >>>> better to rename this as "TTL"? >>>> >>>> 2. Path Identifier : 24 bit path identifier seems to be too less. >>>> Based on our experience in traffic steering, this path identifier =20 >>>>needs to encode good amount of information to make it unique. For=20 >>>>example, >>>> this identifier needs to encode (in our case) some information =20 >>>>representing the distributed controller ID, tenant ID, flow ID, >>>> Service function instance (in case of scale-out) and few more.. >>>> One suggestion is to make it 64 bits value or to make it even=20 >>>>extendable, >>>> it is good if path identifier is also represented in TLV form. >>>> >>>> >>>> Thanks >>>> >>>> Srini >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc